Solucionar un error
El proceso de la tarea de migración puede generar errores durante el tiempo de ejecución.
- Algunos errores, como una contraseña incorrecta en la base de datos de origen, se pueden recuperar, lo que significa que se pueden corregir y la tarea de migración se reanuda automáticamente.
- Algunos son irrecuperables, como la pérdida de la posición del registro binario, lo que significa que la tarea de migración debe reiniciarse desde el principio.
Cuando se produce un error, el estado del trabajo de migración cambia a Failed
y el subestado refleja el último estado antes del fallo.
Para solucionar un error, vaya al trabajo de migración fallido para ver el error y siga los pasos que se indican en el mensaje de error.
Para ver más detalles sobre el error, vaya a Cloud Monitoring mediante el enlace del trabajo de migración. Los registros se filtran para mostrar solo los de la tarea de migración específica.
En la siguiente tabla, puedes ver algunos ejemplos de problemas y cómo se pueden resolver:
Para este problema... | El problema puede deberse a lo siguiente: | Prueba esto... |
---|---|---|
Los ajustes de la base de datos de destino son diferentes de la configuración de Terraform que se ha usado para aprovisionar la base de datos. A veces, este problema también se denomina desfase de configuración. | Cuando migras a una base de datos de destino que ya existe, el servicio de migración de bases de datos modifica determinados ajustes de la base de datos de destino para ejecutar la tarea de migración. | Debe volver a aplicar los ajustes que utilice en su configuración de Terraform después de promover el trabajo de migración. Consulta Desviación de la configuración de Terraform. |
Mensaje de error: Error processing table {table_name}: MySQL Error 1118
(42000): Row size too large (>8126). |
Las tablas que usan columnas VARCHAR pueden tener filas que superen el tamaño máximo permitido por InnoDB (el motor de almacenamiento predeterminado que se usa en MySQL). |
Puedes desbloquear tu tarea de migración convirtiendo las columnas a BLOB o TEXT,
o bien asignando temporalmente el valor off a la marca
innodb_strict_mode .
Consulta Error 1118: el tamaño de la fila es demasiado grande. |
La tarea de migración ha fallado durante la fase de volcado completo y ha devuelto el siguiente mensaje de error:ERROR 1064 (42000) at {line_number}: You have an error in your
SQL syntax; check the manual that corresponds to your MySQL server version for
the right syntax to use near {reserved_word} at {line_number}.
|
Este problema se produce al migrar entre versiones de MySQL.
Es posible que las entidades de tu versión de origen de MySQL usen palabras que no estén permitidas en la versión de MySQL a la que quieras migrar.
Por ejemplo, en MySQL 5.7 puedes usar la palabra |
Cambie el nombre de los objetos de la base de datos de origen a los que se hace referencia en el mensaje de error o póngalos entre comillas inversas (`` ) para evitar la sintaxis. Cuando se complete, vuelve a intentar la tarea de migración.
|
Mensaje de error: ERROR 1109 (42S02): Unknown table in <schema name here> |
Database Migration Service no migra los esquemas de sistema mysql ,
performance_schema , information_schema ,
ndbinfo ni sys .
Es posible que la tarea de migración falle si la base de datos de origen contiene objetos que hacen referencia a tablas de alguno de estos esquemas. |
Compruebe en la base de datos de origen si hay objetos que hagan referencia a tablas incluidas en alguno de los esquemas del sistema que no se hayan migrado. Consulta ERROR 1109 (42S02): Unknown table in <schema name here>. |
Mensaje de error: Unknown table 'COLUMN_STATISTICS' in information_schema (1109) |
Pertinente solo en los casos de volcado manual de bases de datos con mysqldump .Las bases de datos MySQL de versiones anteriores a la 8 no tienen la tabla COLUMN_STATISTICS. La utilidad |
Usa la marca --column-statistics=0 cuando utilices mysqldump . |
Mensaje de error: Specified key was too long; max key length is 767 bytes . |
Es posible que la instancia de la base de datos de origen tenga definida la variable innodb_large_prefix . |
Define la marca innodb_large_prefix como ON al crear la instancia de destino o actualiza la instancia de destino con la marca. |
Mensaje de error: Table definition has changed . |
Se han producido cambios en el lenguaje de definición de datos (DDL) durante el proceso de volcado. | Evita hacer cambios en el DDL durante el proceso de volcado. |
Mensaje de error: Access denied; you need (at least one of) the SUPER privilege(s) for this operation . |
Puede haber un evento, una vista, una función o un procedimiento en la base de datos de origen que use super user@localhost (como root@localhost). Cloud SQL no admite esta opción. | Consulta más información sobre el uso de DEFINER en Cloud SQL. |
Mensaje de error: Definer user 'x' does not exist. Please create the user on the replica.
|
El usuario no existe en la réplica. | Consulta más información sobre el uso de DEFINER en Cloud SQL. |
Mensaje de error: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost . |
Hay un DEFINER en la base de datos de origen que no existe en la réplica. |
Consulta más información sobre el uso de DEFINER en Cloud SQL. |
Mensaje de error: Lost connection to MySQL server during query when dumping table . |
Es posible que no se pueda acceder a la base de datos de origen o que el volcado contenga paquetes demasiado grandes. | Prueba estas sugerencias. |
Mensaje de error: Got packet bigger than 'max_allowed_packet' bytes when dumping table . |
El paquete era más grande de lo permitido por los ajustes. | Usa el volcado manual con la opción max_allowed_packet . |
La migración de datos inicial se ha realizado correctamente, pero no se están replicando datos. | Puede haber marcas de replicación conflictivas. | Consulta estos ajustes de las marcas. |
La migración de datos inicial se ha completado correctamente, pero la replicación de datos ha dejado de funcionar al cabo de un tiempo. | Puede haber muchos motivos. | Prueba estas sugerencias. |
Mensaje de error: mysqld check failed: data disk is full . |
El disco de datos de la instancia de destino está lleno. | Aumenta el tamaño del disco de la instancia de destino. Puedes aumentar el tamaño del disco manualmente o habilitar el aumento automático del almacenamiento. |
No se ha podido conectar a la instancia de base de datos de origen. | Ha habido un problema de conectividad entre la instancia de base de datos de origen y la de destino. | Sigue los pasos que se indican en el artículo sobre depuración de la conectividad. |
No se inicia la migración desde una base de datos gestionada (Amazon RDS o Aurora). | Para migrar desde una base de datos de origen gestionada sin privilegios de superusuario, se requiere un breve periodo de inactividad al principio de la migración. | Sigue los pasos que se indican en este artículo. |
Binlog está configurado incorrectamente en la base de datos de origen. | Las definiciones de Binlog son incorrectas. | En el caso de las tareas de migración continua de MySQL, asegúrate de seguir las definiciones de binlog obligatorias. |
No se ha encontrado el archivo de volcado. | DMS no puede encontrar el archivo de volcado proporcionado. | Esto puede ocurrir si la tarea de migración no encuentra el archivo de volcado en la ubicación indicada.
|
No se puede reanudar la replicación porque se ha perdido la posición del registro binario. | Se ha perdido la posición del registro binario y no se ha podido reanudar la tarea de migración. | Este error puede producirse cuando el proceso de replicación se pausa durante mucho tiempo, lo que provoca que se pierda la posición del registro binario. Las tareas de migración no deben pausarse durante periodos que se acerquen al periodo de retención del registro binario. Reinicia la tarea de migración. |
Cuando migras a
una instancia de destino que ya existe, recibes el siguiente mensaje de error:
The destination instance contains existing data or user defined
entities (for example databases, tables, or functions). You can only
migrate to empty instances. Clear your destination instance and retry
the migration job.
|
Tu instancia de Cloud SQL de destino contiene datos adicionales. Solo puedes migrar a instancias vacías. Consulta las limitaciones conocidas. | Promueve tu instancia de destino para convertirla en una instancia de lectura y escritura, elimina los datos adicionales y vuelve a intentar la tarea de migración. Consulta Borrar datos adicionales de una instancia de destino. |
No se ha podido ejecutar la tarea de migración porque las versiones de las bases de datos de origen y destino no son compatibles. | La versión de la base de datos de origen proporcionada no es compatible con la versión de la base de datos de destino. | Asegúrate de que la versión de la base de datos de destino sea la misma o una versión principal superior a la de la base de datos de origen y, a continuación, crea una tarea de migración. |
Mensaje de error: Unable to connect to source database server.
|
El servicio de migración de bases de datos no puede establecer una conexión con el servidor de bases de datos de origen. | Asegúrate de que las instancias de la base de datos de origen y de destino puedan comunicarse entre sí y de que hayas completado todos los requisitos previos que aparecieron cuando definiste los ajustes de la tarea de migración. |
Mensaje de error: Timeout waiting for no write traffic on source.
|
Si migras desde una base de datos de origen gestionada sin privilegios SUPERUSER , se producirá un breve periodo de inactividad al principio de la migración. |
Sigue los pasos que se indican en Migrar desde MySQL de RDS sin privilegios de SUPERUSER. |
Mensaje de error: ERROR 1146 (42S02) at line {line_number}: Table '{table_name}' doesn't exist.
|
Puede haber una incoherencia entre el valor de la marca lower_case_table_names de la base de datos de origen y el valor de la marca de la instancia de Cloud SQL de destino. |
Asigna a la marca de la instancia de Cloud SQL el mismo valor que la marca de la base de datos de origen. |
Mensaje de error: ERROR 1109 (42S02) at line {line_number}: Unknown table '{table}' in {database}.
|
Algunos objetos de la base de datos de origen, como vistas, funciones, procedimientos almacenados o activadores, hacen referencia a una tabla que ya no existe en la base de datos. | Comprueba si existen estos objetos. Si es así, elimina los objetos de la base de datos de origen o añade a la base de datos de origen la tabla a la que hacen referencia los objetos. |
Mensaje de error: ERROR 1045: Access denied for user '{user_name}'@'{replica_IP}' (using password: YES)". Check if MySQL replication user and password are correct. Not attempting further retries. |
Has proporcionado una contraseña incorrecta para la instancia de origen. O bien, la instancia de origen fuerza una conexión SSL, pero la tarea de migración no está configurada para usar certificaciones SSL. | Comprueba si el nombre de usuario, la contraseña y los ajustes de SSL de la instancia de origen son correctos con el cliente Si la instancia de origen es Cloud SQL, consulta Requerir SSL/TLS para verificar si se requiere SSL/TLS para las conexiones TCP. |
La latencia de replicación es constantemente alta. | La carga de escritura es demasiado alta para que la réplica pueda gestionarla. El retraso de la replicación se produce cuando el subproceso de Cloud SQL para MySQL de una réplica no puede seguir el ritmo del subproceso de E/S. Algunos tipos de consultas o cargas de trabajo pueden provocar un retraso de replicación alto, ya sea temporal o permanente, en un esquema determinado. Algunas de las causas habituales del retraso de la réplica son las siguientes:
|
Estas son algunas posibles soluciones:
|
Mensaje de error: 'Character set '#255' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index.xml' file' on query. |
Es posible que la base de datos de origen use conjuntos de caracteres o intercalaciones que no sean compatibles con la réplica de Cloud SQL seleccionada. Un ejemplo es AWS Aurora versión 2.x, que es compatible con MySQL 5.7. Sin embargo, esta versión admite la utf8mb4_0900_as_ci , que no es compatible con Cloud SQL para MySQL 5.7. |
|
Error 1108: tamaño de fila demasiado grande
Las tablas con columnas que almacenan cadenas de longitud variable pueden tener filas que superen el tamaño máximo de fila predeterminado de InnoDB.Cosas que puedes probar
Ajustar el esquema de la tabla de origen
Este problema puede volver a producirse cada vez que ejecutes instrucciones INSERT en las tablas que superen el límite de tamaño máximo de las filas. Para evitar problemas en el futuro, te recomendamos que ajustes tus tablas antes de volver a intentar la migración:
- Cambia la tabla
ROW_FORMAT
aDYNAMIC
oCOMPRESSED
ejecutando la siguiente consulta: Dónde:ALTER TABLE TABLE_NAME ROW_FORMAT=FORMAT_NAME;
- TABLE_NAME es el nombre de la tabla cuyas filas superan el límite de tamaño máximo de las filas
- FORMAT_NAME es
DYNAMIC
oCOMPRESSED
ALTER TABLE mytable ROW_FORMAT=DYNAMIC;
- Convierte los datos de las filas en BLOB o TEXT. Una forma de conseguirlo es con la función
CONVERT()
.
Inhabilitar el modo estricto de InnoDB
Si no puedes ajustar el esquema de la tabla de origen, puedes inhabilitar temporalmente la validación de InnoDB para completar la tarea de migración. Ten en cuenta que el problema puede volver a producirse en futuros intentos de escritura en la base de datos, por lo que es mejor que ajustes el esquema de la tabla cuando sea posible.
Para inhabilitar temporalmente la validación de InnoDB con el fin de completar el trabajo de migración, siga estos pasos:
Si... | Después... |
---|---|
Si migras a una nueva instancia de destino |
|
Si migras a una instancia de destino |
|
Borrar datos adicionales de tu instancia de destino
Cuando migras a
una instancia de destino que ya existe, recibes el siguiente mensaje de error:
The destination instance contains existing data or user defined
entities (for example databases, tables, or functions). You can only
migrate to empty instances. Clear your destination instance and retry
the migration job.
Este problema puede producirse si su instancia de destino contiene datos adicionales. Solo puedes migrar a instancias vacías. Consulta las limitaciones conocidas.
Cosas que puedes probar
Borra los datos adicionales de la instancia de destino y vuelve a iniciar la tarea de migración siguiendo estos pasos:
- Detener la tarea de migración.
- En este punto, la instancia de Cloud SQL de destino está en modo
read-only
. Promueve la instancia de destino para obtener acceso de escritura. - Conéctate a tu instancia de Cloud SQL de destino.
- Elimina los datos adicionales de las bases de datos de la instancia de destino. El destino solo puede contener datos de configuración del sistema. Las bases de datos de destino
no pueden contener datos de usuario (como tablas). Hay diferentes instrucciones SQL que puedes ejecutar en tus bases de datos para encontrar datos que no sean del sistema. Por ejemplo:
SELECT schema_name FROM information_schema.SCHEMATA WHERE schema_name NOT IN ('information_schema', 'sys', 'performance_schema', 'mysql');
- Inicia la tarea de migración.
Desviación de la configuración de Terraform
Cuando migras a una base de datos de destino que ya existe, el servicio de migración de bases de datos modifica determinados ajustes de la base de datos de destino para ejecutar la tarea de migración. En el caso de las bases de datos aprovisionadas con Terraform, esta interacción puede provocar una desviación de la configuración, en la que la configuración real de la base de datos de destino es diferente de la configuración definida en los archivos de Terraform.Cosas que puedes probar
No intentes volver a aplicar la configuración de Terraform mientras se esté ejecutando la tarea de migración. Puedes ajustar de forma segura la configuración necesaria después de que se haya promovido la base de datos de destino. Database Migration Service realiza las siguientes modificaciones en la instancia de Cloud SQL de destino:- La configuración de copia de seguridad se ha definido con los valores predeterminados.
- La recuperación a un momento dado se restablece a los valores predeterminados.
ERROR 1109 (42S02): Unknown table in <schema name here>
Las tareas de migración fallan y muestran el siguiente mensaje:
ERROR 1109 (42S02): Unknown table in <schema name here>
, por ejemplo: ERROR 1109 (42S02) at line X: Unknown table 'GLOBAL_STATUS' in information_schema
.
El problema puede deberse a lo siguiente:
Database Migration Service no migra los esquemas de sistema mysql
,
performance_schema
, information_schema
,
ndbinfo
ni sys
(consulta las
limitaciones conocidas).
Es posible que la tarea de migración falle si la base de datos de origen contiene objetos que hacen referencia a tablas de alguno de estos esquemas.
Cosas que puedes probar
Comprueba si en tu base de datos de origen hay objetos que hagan referencia a tablas de los esquemas del sistema. En la base de datos de origen, ejecuta las siguientes consultas:# Query to check routines or functions definitions. SELECT ROUTINE_SCHEMA, ROUTINE_NAME FROM information_schema.routines WHERE ROUTINE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys') AND ROUTINE_DEFINITION like '%OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE%' # Query to check view definitions. SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.views WHERE TABLE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys') AND view_definition like '%OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE%' # Query to check trigger definitions. SELECT TRIGGER_SCHEMA, TRIGGER_NAME FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys') AND event_object_table = 'OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE' # Query to check constraint definitions. SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys') AND REFERENCED_TABLE_NAME = 'OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE'
Tabla 'COLUMN_STATISTICS' desconocida en information_schema
Al ejecutar la utilidad mysqldump
versión 8 o posterior para exportar una base de datos MySQL con una versión anterior a la 8, se produce este error: Unknown table 'COLUMN_STATISTICS' in information_schema (1109)
.
El problema puede deberse a lo siguiente:
Las bases de datos MySQL de versiones anteriores a la 8 no tienen la tabla COLUMN_STATISTICS. La utilidad mysqldump
de las versiones 8 y posteriores intenta exportar esta tabla de forma predeterminada. La exportación falla porque la columna no existe.
Cosas que puedes probar
Añade la marca --column-statistics=0
al comando mysqldump
para quitar la tabla COLUMN_STATISTICS
de la exportación. Para obtener más información, consulta Exportar una base de datos de MySQL con mysqldump.
La clave especificada era demasiado larga. La longitud máxima de la clave es de 767 bytes.
Aparece el error Specified key was too long; max key length is 767 bytes.
El problema puede deberse a lo siguiente:
Es posible que la base de datos de origen tenga definida la variable innodb_large_prefix. Esto permite que los prefijos de clave de índice tengan más de 767 bytes. El valor predeterminado es OFF
para MySQL 5.6.
Cosas que puedes probar
Define la marca innodb_large_prefix
como ON
al crear la base de datos de destino o actualiza la base de datos de destino con la marca.
La definición de la tabla ha cambiado
Aparece el error Table definition has changed
.
El problema puede deberse a lo siguiente:
Se han producido cambios en el DDL durante el proceso de volcado.
Cosas que puedes probar
No modifiques las tablas ni realices ningún otro cambio de DDL durante el proceso de volcado.Puedes usar un script para verificar que las operaciones de DDL se han detenido.
Acceso denegado. Necesitas (al menos uno de) los privilegios SUPER para esta operación
Aparece el error Access denied; you need (at least one of) the SUPER privilege(s) for this operation
.
El problema puede deberse a lo siguiente:
Puede haber un evento, una vista, una función o un procedimiento en la base de datos de origen que use super user@localhost (como root@localhost). Cloud SQL no admite esta opción.
Cosas que puedes probar
Consulta este
documento sobre cómo migrar una base de datos con cláusulas DEFINER
.
Mensaje de error: Definer user 'x' does not exist. Please create the user on the replica.
Aparece el error Definer user 'x' does not exist. Please create the user on the replica.
El problema puede deberse a lo siguiente:
La causa principal es que un usuario de la base de datos de origen con la cláusula DEFINER
no existe en la base de datos de réplica.
Cosas que puedes probar
Consulta este
documento sobre cómo migrar una base de datos con cláusulas DEFINER
. Puede que tengas que crear el usuario en la base de datos de réplica.
Mensaje de error: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost
Aparece el error ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost
.
El problema puede deberse a lo siguiente:
La causa principal es que un usuario de la base de datos de origen con la cláusula DEFINER
no existe en la base de datos de réplica y se hace referencia a ese usuario en las definiciones de objeto de la base de datos de origen.
Cosas que puedes probar
Consulta este
documento sobre cómo migrar una base de datos con cláusulas DEFINER
. Es posible que tengas que crear uno o varios usuarios en la base de datos de réplica.
Se ha perdido la conexión con el servidor MySQL durante la consulta al volcar la tabla
Aparece el error Lost connection to MySQL server during query when dumping table
.
El problema puede deberse a lo siguiente:
- Es posible que no se pueda acceder a la instancia de base de datos de origen desde la de destino.
- Es posible que la base de datos de origen tenga tablas con blobs grandes o cadenas largas, por lo que es necesario asignar un número mayor a
max_allowed_packet
en la base de datos de origen.
Cosas que puedes probar
- Verifica que la instancia de la base de datos de origen esté activa y se pueda acceder a ella.
- Configura la marca
max-allowed-packet
en la tarea de migración y, a continuación, reiníciala. También puedes generar un volcado manual con la opciónmax_allowed_packet
para volcar los datos y migrar con el archivo de volcado. - Para aumentar
max_allowed_packet
, lo más probable es que tengas que modificar los ajustes denet_read_timeout
ynet_write_timeout
en la base de datos de origen (por lo general, se debe aumentar hasta que deje de producirse el error de conexión).
Se ha recibido un paquete de más de "max_allowed_packet" bytes al volcar la tabla
Aparece el error Got packet bigger than 'max_allowed_packet' bytes when dumping table
.
El problema puede deberse a lo siguiente:
El paquete era más grande de lo permitido por los ajustes.
Cosas que puedes probar
Crea una tarea de migración mediante un volcado manual con la opción max_allowed_packet
para volcar los datos y migrar con el archivo de volcado.
No se están replicando datos
La migración de datos inicial se ha realizado correctamente, pero no se están replicando datos.
El problema puede deberse a lo siguiente:
Una posible causa principal es que tu base de datos de origen tenga marcas de replicación que impidan que se repliquen algunos o todos los cambios de la base de datos.
Cosas que puedes probar
Asegúrate de que las marcas de replicación, como binlog-do-db
, binlog-ignore-db
, replicate-do-db
o replicate-ignore-db
, no estén configuradas de forma que entren en conflicto.
Ejecuta el comando show master status
en la base de datos de origen para ver la configuración actual.
La migración de datos inicial se ha completado correctamente, pero la replicación de datos ha dejado de funcionar al cabo de un tiempo
La migración de datos inicial se ha completado correctamente, pero la replicación de datos ha dejado de funcionar al cabo de un tiempo.
El problema puede deberse a lo siguiente:
Este problema puede deberse a muchos motivos.
Cosas que puedes probar
- Consulta las métricas de replicación de tu instancia de destino en la interfaz de usuario de Cloud Monitoring.
- Los errores del hilo de E/S o del hilo SQL de MySQL se pueden encontrar en Cloud Logging en los archivos de registro mysql.err.
- El error también se puede encontrar al conectarse a la instancia de destino. Ejecuta el comando
SHOW REPLICA STATUS
y comprueba si en el resultado aparecen estos campos:- Replica_IO_Running
- Replica_SQL_Running
- Last_IO_Error
- Last_SQL_Error
Nota:
SHOW REPLICA STATUS
es un alias introducido en MySQL 8.0.22. En versiones anteriores (MySQL 5.7 y MySQL 8.0), usa el alias antiguo del comando de estado. Para obtener más información, consulta Status statement (Instrucción de estado) en la documentación de MySQL.Si has recibido el error
fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file' in Last_IO_Error
, puede deberse a que la configuración de conservación de binlogs de la instancia de origen es insuficiente.Si has recibido el error
error connecting to master 'USER_NAME@SOURCE_HOST:SOURCE_PORT' - retry-time: RETRY_TIME retries: RETRIES
, puede deberse a que la instancia de destino no se haya podido volver a conectar con la de origen debido a un problema de conectividad o de autenticación.
No se ha podido comprobar mysqld: el disco de datos está lleno
Aparece el error mysqld check failed: data disk is full
.
El problema puede deberse a lo siguiente:
Es probable que el disco de datos de la instancia de destino esté lleno.
Cosas que puedes probar
Aumenta el tamaño del disco de la instancia de destino.
No se ha podido conectar con la base de datos de origen
No se ha podido conectar a la base de datos de origen.
El problema puede deberse a lo siguiente:
Ha habido un problema de conectividad entre la instancia de base de datos de origen y la de destino.
Cosas que puedes probar
Sigue los pasos que se indican en el artículo sobre depuración de la conectividad.
No se inicia la migración desde una base de datos gestionada (Amazon RDS o Aurora)
No se puede iniciar la tarea de migración.
El problema puede deberse a lo siguiente:
Para migrar desde una base de datos de origen gestionada sin privilegios de SUPERUSER
, se requiere un breve periodo de inactividad al principio de la migración.
Cosas que puedes probar
- En el caso de Amazon RDS, sigue los pasos que se indican en este artículo.
- En el caso de Amazon Aurora, sigue los pasos que se indican en este artículo.
Binlog está configurado incorrectamente en la base de datos de origen
Aparece un error que indica que hay un problema con los registros binarios.
El problema puede deberse a lo siguiente:
Esto puede ocurrir en las tareas de migración continua de MySQL si la configuración de binlog es incorrecta en la base de datos de origen.
Cosas que puedes probar
Asegúrate de seguir las definiciones que se indican aquí.
Error al leer el archivo de volcado proporcionado
Aparece un error que indica que hay un problema con el archivo de volcado.
El problema puede deberse a lo siguiente:
DMS no puede encontrar el archivo de volcado proporcionado.
Cosas que puedes probar
- Comprueba la ruta de volcado para asegurarte de que hay un archivo adecuado o cambia la ruta.
- Si cambias la ruta, usa una solicitud
PATCH
para asegurarte de que el trabajo la usa. - Reinicia la tarea de migración.
No se puede reanudar la replicación porque se ha perdido la posición del archivo de registro binario
Se ha perdido la posición del archivo de registro binario.
El problema puede deberse a lo siguiente:
Este error puede producirse cuando el proceso de replicación se pausa durante mucho tiempo, lo que provoca que se pierda la posición del registro binario. Las tareas de migración no deben pausarse durante periodos de tiempo que se acerquen al periodo de retención del registro binario.
Cosas que puedes probar
Reinicia la tarea de migración.
No se puede ejecutar la tarea de migración porque las versiones de las bases de datos de origen y destino no son compatibles
Las versiones de las bases de datos de origen y destino no forman una combinación admitida.
El problema puede deberse a lo siguiente:
La versión de la base de datos de origen proporcionada no es compatible con la versión de la base de datos de destino.
Cosas que puedes probar
Asegúrate de que la versión de la base de datos de destino sea la misma o una versión principal superior a la de la base de datos de origen y, a continuación, crea una tarea de migración.
No se puede conectar al servidor de la base de datos de origen
Aparece el error Unable to connect to source database server
.
El problema puede deberse a lo siguiente:
El servicio de migración de bases de datos no puede establecer una conexión con el servidor de bases de datos de origen.
Cosas que puedes probar
Verifica que las instancias de la base de datos de origen y de destino puedan comunicarse entre sí. A continuación, asegúrese de que ha completado todos los requisitos previos que aparecieron cuando definió los ajustes de su trabajo de migración.
El uso del disco de la instancia de Cloud SQL de destino se reduce a cero
El uso del disco se reduce de repente a cero durante la migración.
El problema puede deberse a lo siguiente:
Puede que se produzca un error al importar los datos completos del volcado. Cuando esto ocurre, el proceso de migración intenta realizar otra carga de los datos. En este proceso, primero se borran los datos de la instancia de destino (por eso el uso del disco se reduce a cero) y, a continuación, se intenta volver a cargar los datos.
Cosas que puedes probar
Ve a Explorador de registros y selecciona tu instancia de destino en la lista de recursos.
Busca un mensaje de registro similar:
DUMP_STAGE(RETRY): Attempt .../...: import failed: error..."; Clearing database and trying again."
Busca el mensaje después del texto import failed:
e intenta resolver el problema subyacente.