Diagnostica problemas de MySQL

MySQL   |  PostgreSQL   |  PostgreSQL a AlloyDB

Cómo solucionar un error

Es posible que el proceso de trabajo de migración genere 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 que el trabajo de migración se reanuda automáticamente.
• Algunos son irrecuperables, como una posición de registro binario perdida, lo que significa que el trabajo 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 estado secundario refleja el último estado antes de la falla.

Para solucionar un error, navega al trabajo de migración que falló para verlo y sigue los pasos que se indican en el mensaje de error.

Para ver más detalles sobre el error, navega a Cloud Monitoring con el vínculo del trabajo de migración. Los registros se filtran según la tarea de migración específica.

En la siguiente tabla, encontrarás algunos ejemplos de problemas y cómo resolverlos:

Situación	Posible problema	Solución
La configuración de la base de datos de destino es diferente de la configuración de Terraform que se usa para aprovisionar la base de datos. (Este problema también se conoce como desvío de configuración).	Cuando migras a una base de datos de destino existente, Database Migration Service modifica ciertos parámetros de configuración de la base de datos de destino para ejecutar el trabajo de migración.	Debes volver a aplicar la configuración que usas en tu configuración de Terraform después de promocionar el trabajo de migración. Consulta Desfase de configuración de Terraform.
Mensaje de error: Error processing table {table_name}: MySQL Error 1118 (42000): Row size too large (>8126).	Es posible que las tablas que usan columnas VARCHAR tengan filas que superen el tamaño máximo permitido por InnoDB (el motor de almacenamiento predeterminado que se usa en MySQL).	Para desbloquear tu trabajo de migración, convierte las columnas a BLOB o TEXT, o establece temporalmente la marca innodb_strict_mode en off. Consulta Error 1118: El tamaño de la fila es demasiado grande.
La tarea de migración falló durante la fase de volcado completo con 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 cuando se migra entre versiones de MySQL. Es posible que las entidades de tu versión de MySQL de origen usen palabras que no están permitidas en la versión de MySQL a la que deseas migrar. Por ejemplo, en MySQL 5.7, puedes usar la palabra function en los nombres de las columnas. Sin embargo, en MySQL 8.0, function es una palabra reservada, por lo que la base de datos de destino no puede analizar tus fuentes.	Cambia el nombre de los objetos de la base de datos de origen a los que se hace referencia en el mensaje de error o colócalos entre acentos graves (``) para escapar 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 del sistema mysql, performance_schema, information_schema, ndbinfo ni sys. Es posible que tu trabajo de migración falle si la base de datos de origen contiene objetos que hacen referencia a tablas de cualquiera de estos esquemas.	Busca objetos en tu base de datos de origen que hagan referencia a tablas contenidas en cualquiera de los esquemas del sistema que no se hayan migrado. Consulta ERROR 1109 (42S02): Tabla desconocida en <schema name here>.
Mensaje de error: Unknown table 'COLUMN_STATISTICS' in information_schema (1109)	Es relevante para situaciones de volcado manual de bases de datos solo con mysqldump. Las bases de datos de MySQL en versiones anteriores a la 8 no tienen la tabla COLUMN_STATISTICS. La utilidad mysqldump en las versiones 8 y posteriores intenta exportar esta tabla de forma predeterminada. La exportación falla porque la columna no existe.	Usa la marca --column-statistics=0 cuando uses mysqldump.
Mensaje de error: Specified key was too long; max key length is 767 bytes.	La instancia de la base de datos de origen puede tener la variable innodb_large_prefix configurada.	Establece la marca innodb_large_prefix en ON cuando crees la instancia de destino o actualiza la instancia de destino existente con la marca.
Mensaje de error: Table definition has changed.	Hubo cambios en el lenguaje de definición de datos (DDL) durante el proceso de volcado.	Evita los cambios de DDL durante el proceso de volcado.
Mensaje de error: Access denied; you need (at least one of) the SUPER privilege(s) for this operation.	Podría haber un evento, una vista, una función o un procedimiento en la base de datos fuente mediante superuser@localhost (como root@localhost). Esto no es compatible con Cloud SQL.	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 la base de datos de origen no esté disponible 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 fue más grande de lo que permitía la configuración.	Usa el volcado manual con la opción max_allowed_packet.
La migración inicial de los datos se realizó de forma correcta, pero no se están replicando los datos.	Es posible que haya marcas de replicación en conflicto.	Consulta estas opciones de configuración de marcas.
La migración inicial de los datos se realizó de forma correcta, pero la replicación de datos dejó de funcionar después de un tiempo.	Puede haber muchas causas.	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 de forma manual o habilitar el aumento de almacenamiento automático.
No se pudo establecer una conexión con la instancia de la base de datos de origen.	Se produjo 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 Cómo depurar la conectividad.
No se inicia la migración desde una base de datos administrada (Amazon RDS/Aurora).	La migración desde una base de datos de origen administrada sin privilegios de SUPERUSUARIO requiere un breve tiempo de inactividad al comienzo de la migración.	Sigue los pasos que se indican en este artículo.
El registro binario está configurado de forma incorrecta en la base de datos de origen.	Las definiciones de Binlog son incorrectas.	Para los trabajos de migración de MySQL continuos, asegúrate de seguir las definiciones de binlog requeridas.
No se encontró el archivo de volcado.	DMS no puede encontrar el archivo de volcado proporcionado.	Esto puede suceder si el trabajo de migración no puede encontrar el archivo de volcado en la ubicación especificada. Verifica la ruta de volcado para asegurarte de que haya un archivo adecuado o cambia la ruta. Si cambias la ruta, usa una solicitud PATCH para asegurarte de que la tarea la use. Reinicia el trabajo de migración.
No se pudo reanudar la replicación porque se perdió la posición del registro binario.	Se perdió la posición del registro binario y no se pudo reanudar el trabajo de migración.	Este error puede ocurrir cuando el proceso de replicación se detiene durante mucho tiempo, lo que hace que se pierda la posición del registro binario. Los trabajos de migración no deben detenerse durante períodos que se acerquen al período de retención de binlog. Reinicia el trabajo de migración.
Cuando migras a una instancia de destino existente, 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 existentes que estén vacías. Consulta las limitaciones conocidas.	Asciende tu instancia de destino para que sea una instancia de lectura y escritura, quita los datos adicionales y vuelve a intentar el trabajo de migración. Consulta Cómo borrar datos adicionales de tu instancia de destino existente.
Falla en la ejecución del trabajo de migración debido a versiones incompatibles de las bases de datos de origen y destino.	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 versión de destino de origen y, luego, crea un trabajo de migración nuevo.
Mensaje de error: Unable to connect to source database server.	Database Migration Service no puede establecer una conexión con el servidor de la base de datos de origen.	Asegúrate de que las instancias de base de datos de origen y destino puedan comunicarse entre sí y de que hayas completado todos los requisitos previos necesarios que aparecieron cuando definiste la configuración del trabajo de migración.
Mensaje de error: Timeout waiting for no write traffic on source.	La migración desde una base de datos de origen administrada sin privilegios de SUPERUSER genera un breve tiempo de inactividad durante el inicio de la migración.	Sigue los pasos que se indican en Cómo migrar desde MySQL en RDS sin privilegios de SUPERUSER.
Mensaje de error: ERROR 1146 (42S02) at line {line_number}: Table '{table_name}' doesn't exist.	Puede haber una inconsistencia 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.	Establece el valor de la marca para la instancia de Cloud SQL para que coincida con el valor de 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 fuente, como vistas, funciones, procedimientos almacenados o activadores, hacen referencia a una tabla que ya no existe en la base de datos.	Verifica si estos objetos existen. Si es así, quita los objetos de la base de datos de origen o agrega 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.	Proporcionaste una contraseña incorrecta para la instancia de origen. O bien, la instancia de origen fuerza una conexión SSL. Sin embargo, el trabajo de migración no está configurado para usar certificaciones SSL.	Usa el cliente mysql para confirmar si el nombre de usuario, la contraseña y la configuración de SSL son correctos para la instancia de origen. Si la instancia de origen es de Cloud SQL, consulta Requisito de SSL/TLS para verificar si se requiere SSL/TLS para las conexiones TCP.
El retraso de replicación se mantiene alto.	La carga de escritura es demasiado alta para que la réplica la maneje. El retraso de la replicación se produce cuando el subproceso de Cloud SQL para MySQL en una réplica no puede mantener el ritmo del subproceso de E/S. Algunos tipos de consultas o cargas de trabajo pueden causar un gran retraso de la replicación de forma temporal o permanente en un esquema determinado. Estas son algunas de las causas típicas del retraso de replicación: Las consultas lentas se realizan en la réplica. Encuéntralas y corrígelas. Todas las tablas deben tener una clave primaria única. Cada actualización en una tabla que no tenga esta clave genera análisis completos de la tabla en la réplica. Las consultas como DELETE ... WHERE field < 50000000 provocan un retraso de la replicación basada en filas, ya que se acumula una gran cantidad de actualizaciones en la réplica.	Estas son algunas de las soluciones posibles: Configura la replicación paralela si la réplica es MySQL 5.7 (o una versión posterior). Establece la marca innodb_flush_log_at_trx_commit en la réplica como 2. Consulta Sugerencias para trabajar con marcas si deseas obtener más información sobre esta marca. Edita la instancia de Cloud SQL para MySQL para aumentar el tamaño de la réplica. Reduce la carga en la base de datos de origen. Indexa las tablas en la réplica para las tablas que no tengan claves primarias únicas. Indexa las tablas en la base de datos de origen. Esto requiere reiniciar el trabajo de migración. Identifica y corrige las consultas lentas en la base de datos de origen.
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 comparaciones que no sean compatibles con la réplica de Cloud SQL seleccionada. Un ejemplo es la versión 2.x de AWS Aurora, que es compatible con MySQL 5.7. Sin embargo, esta versión admite la ordenación utf8mb4_0900_as_ci, que no es compatible con Cloud SQL para MySQL 5.7.	Si la migración falla durante la fase de volcado completo, verifica la definición de la tabla de origen para ver si se usan conjuntos de caracteres o intercalaciones no admitidos. Si es posible, actualiza a los grupos de caracteres o intercalaciones admitidos. Si la migración falla durante la fase de CDC, verifica el estado de la réplica, busca el registro binario que causa el error de migración y examina la base de datos y la aplicación de origen para ubicar las instrucciones de SQL que usan los conjuntos de caracteres o las collationes. Si es posible, actualiza a los grupos de caracteres o intercalaciones admitidos.

Error 1108: El tamaño de la fila es 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.

Solución

Ajusta el esquema de la tabla de origen

Este problema puede volver a ocurrir cada vez que realices instrucciones INSERT en las tablas que superen el límite de tamaño máximo de fila. Para evitar problemas en el futuro, es mejor que ajustes tus tablas antes de volver a intentar la migración:

• Ejecuta la siguiente consulta para cambiar la tabla ROW_FORMAT a DYNAMIC o COMPRESSED:

  ALTER TABLE TABLE_NAME ROW_FORMAT=FORMAT_NAME;
    

  Donde:
  • TABLE_NAME es el nombre de la tabla cuyas filas superan el límite de tamaño máximo de la fila.
  • FORMAT_NAME es DYNAMIC o COMPRESSED.
  Por ejemplo:

  ALTER TABLE mytable ROW_FORMAT=DYNAMIC;
    

• Convierte los datos de las filas en BLOB o TEXT. Una forma de lograr esta operación es con la función CONVERT().

Cómo 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 el trabajo de migración. Ten en cuenta que el problema puede volver a ocurrir durante futuros intentos de escritura en la base de datos, por lo que es mejor ajustar el esquema de la tabla cuando sea posible.

Para inhabilitar temporalmente la validación de InnoDB con el fin de completar tu trabajo de migración, sigue estos pasos:

Si…	Luego…
Si migras a una instancia de destino nueva	Vuelve a crear el trabajo de migración. Al final del paso Define un destino, haz clic en Mostrar configuraciones opcionales. En la sección Flags, selecciona la marca innodb_strict_mode y configúrala en Off. Una vez que se complete la migración, establece la marca innodb_strict_mode en On. Consulta Configura marcas de base de datos en la documentación de Cloud SQL para MySQL.
Si migras a una instancia de destino existente	En Cloud SQL, navega a tu instancia de destino y establece la marca innodb_strict_mode en Off. Consulta Configura marcas de base de datos en la documentación de Cloud SQL para MySQL. Vuelve a crear el trabajo de migración. Una vez que se complete la migración, establece la marca innodb_strict_mode en On. Consulta Configura marcas de base de datos en la documentación de Cloud SQL para MySQL.

---

Borra los datos adicionales de tu instancia de destino existente

Cuando migras a una instancia de destino existente, 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 ocurrir si tu instancia de destino contiene datos adicionales. Solo puedes migrar a instancias existentes que estén vacías. Consulta Limitaciones conocidas.

Solución

Para borrar los datos adicionales de tu instancia de destino y reiniciar el trabajo de migración, sigue estos pasos:

1. Detén el trabajo de migración.
2. En este punto, tu instancia de Cloud SQL de destino está en el modo read-only. Promociona la instancia de destino para obtener acceso de escritura.
3. Conéctate a tu instancia de Cloud SQL de destino.
4. Quita los datos adicionales de las bases de datos de tu instancia de destino. Tu destino solo puede contener datos de configuración del sistema. Las bases de datos de destino no pueden contener datos del usuario (como tablas). Existen 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');
     

5. Inicia el trabajo de migración.

---

Desvío de configuración de Terraform

Cuando migras a una base de datos de destino existente, Database Migration Service modifica ciertos parámetros de configuración de la base de datos de destino para ejecutar el trabajo de migración. En el caso de las bases de datos aprovisionadas con Terraform, esta interacción podría causar una deriva de configuración en la que la configuración real de la base de datos de destino es diferente de la configuración establecida en tus archivos de Terraform.

Solución

No intentes volver a aplicar la configuración de Terraform cuando se esté ejecutando el trabajo de migración. Puedes ajustar de forma segura la configuración necesaria después de que se promocione la base de datos de destino. Database Migration Service realiza las siguientes modificaciones en tu instancia de Cloud SQL de destino:

• La configuración de la copia de seguridad se establece en valores predeterminados.
• La recuperación de un momento determinado se restablece a los valores predeterminados.

Es posible que se produzca una deriva de configuración si tu configuración de Terraform contiene parámetros de configuración para cualquiera de estas funciones. Si necesitas corregir la configuración de la base de datos de destino, espera a que se complete el trabajo de migración y se promocione la base de datos de destino. Luego, sigue estos pasos: 1. Ejecuta el comando "terraform plan" para ver la vista previa de tus modificaciones. 1. Ejecuta el comando "terraform apply" para volver a ajustar la configuración de la base de datos de destino.

---

ERROR 1109 (42S02): Tabla desconocida en <schema name here>

Los trabajos de migración fallan con 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.

Posible problema

Database Migration Service no migra los esquemas del sistema mysql, performance_schema, information_schema, ndbinfo ni sys (consulta Limitaciones conocidas). Es posible que tu trabajo de migración falle si la base de datos de origen contiene objetos que hacen referencia a tablas de cualquiera de estos esquemas.

Solución

Verifica tu base de datos de origen en busca de objetos que hagan referencia a tablas de los esquemas del sistema. En tu 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'

Si estas consultas muestran algún resultado, considera borrar los objetos de código relevantes y volver a realizar la migración.

---

Tabla desconocida "COLUMN_STATISTICS" en information_schema

Cuando ejecutas la utilidad mysqldump versión 8 o posterior para exportar una versión de base de datos de MySQL anterior a la 8, se produce este error: Unknown table 'COLUMN_STATISTICS' in information_schema (1109).

Posible problema

Las bases de datos de MySQL en versiones anteriores a la 8 no tienen la tabla COLUMN_STATISTICS. La utilidad mysqldump en las versiones 8 y posteriores intenta exportar esta tabla de forma predeterminada. La exportación falla porque la columna no existe.

Solución

Agrega la marca --column-statistics=0 a tu comando mysqldump para quitar la tabla COLUMN_STATISTICS de la exportación. Para obtener más información, consulta Cómo exportar una base de datos de MySQL con mysqldump.

---

La clave especificada era demasiado larga; la longitud máxima es de 767 bytes

Verás el error Specified key was too long; max key length is 767 bytes..

Posible problema

La base de datos de origen puede tener la variable innodb_large_prefix configurada. Esto permite que los prefijos de clave de índice sean más largos que 767 bytes. El valor predeterminado es OFF para MySQL 5.6.

Solución

Establece la marca innodb_large_prefix en ON cuando crees la base de datos de destino o actualiza la base de datos de destino existente con la marca.

---

La definición de la tabla cambió

Verás el error Table definition has changed.

Posible problema

Hubo cambios de DDL durante el proceso de volcado.

Solución

No modifiques las tablas ni realices ningún otro cambio de DDL durante el proceso de volcado.Puedes usar una secuencia de comandos para verificar que se detengan las operaciones de DDL.

---

Se denegó el acceso porque necesitas privilegios SUPER para esta operación (al menos uno)

Verás el error Access denied; you need (at least one of) the SUPER privilege(s) for this operation.

Posible problema

Podría haber un evento, una vista, una función o un procedimiento en la base de datos fuente mediante superuser@localhost (como root@localhost). Esto no es compatible con Cloud SQL.

Solución

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.

Verás el error Definer user 'x' does not exist. Please create the user on the replica..

Posible problema

La causa raíz es que un usuario en la base de datos de origen con la cláusula DEFINER no existe en la base de datos de la réplica.

Solución

Consulta este documento sobre cómo migrar una base de datos con cláusulas DEFINER. Es posible que debas 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

Verás el error ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost.

Posible problema

La causa raíz es que un usuario en la base de datos de origen con la cláusula DEFINER no existe en la base de datos de la réplica, y ese usuario hace referencia cruzada en las definiciones del objeto en la base de datos de origen.

Solución

Consulta este documento sobre cómo migrar una base de datos con cláusulas DEFINER. Es posible que debas crear uno o más usuarios en la base de datos de réplica.

---

Se perdió la conexión con el servidor MySQL durante la consulta mientras se realizaba el volcado de la tabla

Verás el error Lost connection to MySQL server during query when dumping table.

Posible problema

• Es posible que no se pueda acceder a la instancia de la base de datos de origen desde la instancia de destino.
• La base de datos de origen puede tener tablas con BLOB grandes o cadenas largas que requieren que se configure max_allowed_packet en un número mayor en la base de datos de origen.

Solución

• 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 el trabajo de migración y, luego, reinicia el trabajo de migración. También puedes generar un volcado manual con la opción max_allowed_packet para volcar los datos y migrar con el archivo de volcado.
• Si aumentas max_allowed_packet, es probable que debas ajustar la configuración de net_read_timeout y net_write_timeout en la base de datos de origen (por lo general, se debe aumentar hasta que se detenga el error de conexión).

---

Se obtuvo un paquete mayor que los bytes de “max_allowed_packet” durante el volcado de la tabla

Verás el error Got packet bigger than 'max_allowed_packet' bytes when dumping table.

Posible problema

El paquete fue más grande de lo que permitía la configuración.

Solución

Crea un trabajo de migración con 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 inicial de los datos se realizó de forma correcta, pero no se están replicando los datos.

Posible problema

Una posible causa raíz podría ser que la base de datos de origen tenga marcas de replicación que den como resultado que no se repliquen algunos o todos los cambios de la base de datos.

Solución

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 manera conflictiva.
Ejecuta el comando show master status en la base de datos de origen para ver la configuración actual.

---

La migración inicial de los datos se realizó de forma correcta, pero la replicación de datos dejó de funcionar después de un tiempo

La migración inicial de los datos se realizó de forma correcta, pero la replicación de datos dejó de funcionar después de un tiempo.

Posible problema

Este problema puede tener muchas causas raíz.

Solución

• Verifica las métricas de replicación de tu instancia de destino en la IU de Cloud Monitoring.
• Los errores del subproceso de IO de MySQL o el subproceso de SQL se pueden encontrar en los archivos de registro de mysql.err en Cloud Logging.
• El error también se puede encontrar cuando te conectas a la instancia de destino. Ejecuta el comando SHOW REPLICA STATUS y busca estos campos en el resultado:
  • Replica_IO_Running
  • Replica_SQL_Running
  • Last_IO_Error
  • Last_SQL_Error

  Nota: SHOW REPLICA STATUS es un alias que se introdujo en MySQL 8.0.22. Para versiones anteriores (MySQL 5.7 y MySQL 8.0), usa el alias anterior del comando status. Para obtener más información, consulta Declaración de estado en la documentación de MySQL.

  Si recibiste 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, es posible que se deba a que la configuración de retención de registros binarios en la instancia de origen no es suficiente.

  Si recibiste el error error connecting to master 'USER_NAME@SOURCE_HOST:SOURCE_PORT' - retry-time: RETRY_TIME retries: RETRIES, es posible que la instancia de destino no se haya podido volver a conectar a la fuente debido a un problema de conectividad o autenticación.

---

Error de comprobación de mysqld: el disco de datos está lleno

Verás el error mysqld check failed: data disk is full.

Posible problema

Es probable que el disco de datos de la instancia de destino esté lleno.

Solución

Aumenta el tamaño del disco de la instancia de destino.

---

Falla en la conexión a la base de datos de origen

Falla en la conexión a la base de datos de origen.

Posible problema

Se produjo un problema de conectividad entre la instancia de base de datos de origen y la de destino.

Solución

Sigue los pasos que se indican en el artículo de depuración de la conectividad.

---

No se inicia la migración desde una base de datos administrada (Amazon RDS/Aurora)

No se puede iniciar el trabajo de migración.

Posible problema

La migración desde una base de datos de origen administrada sin privilegios de SUPERUSER requiere un breve tiempo de inactividad al comienzo de la migración.

Solución

• Para Amazon RDS, sigue los pasos que se indican en este artículo.
• Para Amazon Aurora, sigue los pasos que se indican en este artículo.

---

El registro binario está configurado de forma incorrecta en la base de datos de origen.

Verás un error que indica un problema con los registros binarios.

Posible problema

Esto puede suceder en los trabajos de migración de MySQL continuos si la configuración del registro binario es incorrecta en la base de datos de origen.

Solución

Asegúrate de seguir las definiciones que se indican aquí.

---

No se pudo leer el archivo de volcado proporcionado

Verás un error que indica un problema con el archivo de volcado.

Posible problema

DMS no puede encontrar el archivo de volcado proporcionado.

Solución

1. Verifica la ruta de volcado para asegurarte de que haya un archivo adecuado o cambia la ruta.
2. Si cambias la ruta, usa una solicitud PATCH para asegurarte de que la tarea la use.
3. Reinicia el trabajo de migración.

---

No se pudo reanudar la replicación porque se perdió la posición del registro binario

Se pierde la posición del registro binario.

Posible problema

Este error puede ocurrir cuando el proceso de replicación se pausa durante mucho tiempo, lo que hace que se pierda la posición del registro binario. Los trabajos de migración no deben detenerse durante períodos que se acerquen al período de retención de binlog.

Solución

Reinicia el trabajo de migración.

---

Falla en la ejecución del trabajo de migración debido a versiones incompatibles de la base de datos de origen y de destino

Las versiones de la base de datos de origen y destino no son una combinación compatible.

Posible problema

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.

Solución

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 versión de destino de origen y, luego, crea un trabajo de migración nuevo.

---

No se puede conectar al servidor de la base de datos de origen

Verás el error Unable to connect to source database server.

Posible problema

Database Migration Service no puede establecer una conexión con el servidor de la base de datos de origen.

Solución

Verifica que las instancias de base de datos de origen y destino puedan comunicarse entre sí. Luego, asegúrate de haber completado todos los requisitos previos necesarios que aparecieron cuando definiste la configuración de tu trabajo de migración.

---

El uso del disco de la instancia de destino de Cloud SQL disminuye a cero

El uso del disco disminuye repentinamente a cero durante la migración.

Posible problema

Es posible que se produzca un error cuando se importen los datos completos del volcado. Cuando esto sucede, el proceso de migración intenta realizar otra carga de los datos. Este proceso primero borra los datos existentes en la instancia de destino (por eso ves que el uso del disco disminuye a cero) y, luego, intenta volver a cargar los datos.

Solución

Ve al Explorador de registros y selecciona tu instancia de destino de 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: y trata de resolver el problema subyacente.