Migración de datos de MySQL a Azure Database for MySQL: instantánea coherente de MySQL

La instantánea coherente de MySQL es una nueva característica que permite a los usuarios realizar una instantánea coherente de un servidor MySQL sin perder integridad de datos en el origen debido a operaciones CRUD continuas (Crear, Leer, Actualizar y Eliminar). La coherencia transaccional se logra sin necesidad de establecer el servidor de origen en modo de solo lectura a través de esta característica. Además, hay varias opciones de coherencia de datos que se presentan al usuario: habilitar instantánea coherente con bloqueo de lectura (GA), habilitar instantánea coherente sin bloqueo (versión preliminar), hacer que el servidor de origen sea de solo lectura y ninguna. La selección de la opción "Ninguna" implica que no se ha tomado ninguna medida adicional para garantizar la coherencia de los datos. Se recomienda seleccionar la opción "Habilitar instantánea coherente sin bloqueos" para mantener la coherencia transaccional.

Habilitación de instantánea coherente sin bloqueos (versión preliminar)

Al habilitar esta opción, se producirá una fase de conciliación después de la carga inicial. Esto es para garantizar que los datos escritos en el destino sean transaccionalmente coherentes con el servidor de origen a partir de una posición específica en el registro binario.

Con esta característica, no se toma un bloqueo de lectura en el servidor. En su lugar, se leen tablas en un momento dado diferente, a la vez que se realiza un seguimiento de las distintas posiciones de binlog de cada tabla. Esto ayuda a conciliar las tablas hacia el final de la carga inicial realizando la replicación en modo de captura para obtener una instantánea coherente.

Características clave de la instantánea coherente sin bloqueos: *Capacidad para admitir servidores de carga de trabajo pesada o servidores con transacciones de larga duración sin necesidad de bloqueos de lectura. *Resistencia para completar migraciones incluso en caso de errores causados por cortes transitorios de red o servidor que provocan la pérdida de todas las conexiones creadas previamente.

Habilitación de la instantánea coherente con bloqueo de lectura (GA)

Al habilitar esta opción, el servicio vacía todas las tablas del servidor de origen con un bloqueo de lectura para obtener la instantánea de un momento dado. Este vaciado se hace porque un bloqueo global es más confiable que intentar bloquear tablas o bases de datos individuales. Como resultado, incluso si no va a migrar todas las bases de datos de un servidor, se bloquean como parte de la configuración del proceso de migración. El servicio de migración inicia una lectura repetible y combina el estado de la tabla actual con el contenido del registro de deshacer para la instantánea. La instantánea se genera después de obtener el bloqueo de todo el servidor y generar varias conexiones para la migración. Después de crear todas las conexiones para la migración, se liberan los bloqueos de la tabla.

Las lecturas repetibles están habilitadas para mantener los registros de fase de reversión accesibles durante la migración, lo que aumenta el almacenamiento necesario en el origen debido a conexiones de larga duración. Una migración de larga duración con varios cambios de tabla conduce a un extenso historial de fase de reversión que se debe reproducir y también podría aumentar los requisitos de proceso y la carga en el servidor de origen.

Hacer que el servidor de origen sea de solo lectura

Esto mantiene la integridad de los datos de la base de datos de destino mientras se migra el origen evitando las operaciones de escritura y eliminación en el servidor de origen durante la migración. Al hacer que el servidor de origen sea de solo lectura como parte del proceso de migración, la selección se aplica a todas las bases de datos del servidor de origen, independientemente de si están seleccionadas para la migración.

Al definir que el servidor de origen sea de solo lectura, los no pueden modificar los datos y la base de datos no está disponible para las operaciones de actualización. Sin embargo, si esta opción no está habilitada, existe la posibilidad de que se produzcan actualizaciones de datos durante la migración. Como resultado, los datos migrados podrían ser incoherentes porque las instantáneas de la base de datos se leerían en distintos momentos en el tiempo.

Requisitos previos para habilitar instantánea coherente con bloqueo de lectura

Para completar correctamente la migración con instantánea coherente con bloqueo de lectura habilitado:

• Asegúrese de que el usuario que intenta vaciar las tablas con un bloqueo de lectura tiene el permiso RELOAD o FLUSH.

• Use la herramienta de cliente mysql para determinar si log_bin está habilitado en el servidor de origen. El registro binario no siempre está activado de forma predeterminada y debe comprobarse para ver si está habilitado antes de iniciar la migración. La herramienta cliente mysql se usa para determinar si log_bin está habilitado en el origen ejecutando el comando: SHOW VARIABLES LIKE 'log_bin';

Nota:

En Azure Database for MySQL con servidor único, que admite hasta 4 TB, esta opción no está habilitada de forma predeterminada. Sin embargo, si promueve una réplica de lectura para el servidor de origen y, luego, elimina la réplica de lectura, el parámetro se establece en ACTIVADO.

• Configure el parámetro binlog_expire_logs_seconds en el servidor de origen para asegurarse de que los archivos binlog no se purguen antes de que la réplica confirme los cambios. Después de la migración correcta, se puede restablecer el valor.

Problemas conocidos y limitaciones para la habilitación de instantánea coherente sin bloqueos

• No se admiten tablas con claves externas que tengan Cascade o Set Null en la cláusula delete/on update.
• No debe producirse ningún cambio de DDL durante la carga inicial.

Problemas conocidos y limitaciones para la habilitación de instantánea coherente con bloqueo de lectura

Los problemas conocidos y las limitaciones asociadas a la copia de seguridad coherente se dividen en dos categorías: bloqueos y reintentos.

Nota:

El servicio de migración ejecuta la consulta START TRANSACTION WITH CONSISTENT SNAPSHOT para que todos los subprocesos de trabajo obtengan la instantánea del servidor. Pero solo es compatible con InnoDB. Consulte más información aquí.

Bloqueos

Normalmente, obtener un bloqueo es un proceso sencillo, que debe tardar entre unos segundos y un par de minutos en completarse. Sin embargo, en algunos escenarios, se puede producir un error en los intentos de obtener un bloqueo en el servidor de origen.

• La presencia de consultas de larga duración podría dar lugar a un tiempo de inactividad innecesario, ya que DMS podría bloquear un subconjunto de las tablas y, a continuación, agotar el tiempo de espera para que los últimos estén disponibles. Antes de iniciar la migración, compruebe si hay operaciones de larga duración ejecutando el comando SHOW PROCESSLIST.

• Si el servidor de origen está experimentando muchas actualizaciones de escritura en el momento en que se solicita un bloqueo, este no se puede obtener fácilmente y podría producir un error después del tiempo de espera de bloqueo. Esto sucede en el caso de las tareas de procesamiento por lotes en las tablas, lo que puede dar lugar a la denegación de la solicitud de un bloqueo. Como se mencionó anteriormente, el bloqueo solicitado es un bloqueo de nivel global único para todo el servidor, por lo que incluso si una sola tabla o base de datos está en proceso, la solicitud de bloqueo tendría que esperar a que finalice la tarea en curso.

• Otra limitación se refiere a la migración desde un servidor de origen de AWS RDS. RDS no admite tablas de vaciado con bloqueo de lectura y la consulta LOCK TABLE se ejecuta en las tablas seleccionadas en segundo plano. A medida que las tablas se bloquean individualmente, el proceso de bloqueo puede ser menos confiable y los bloqueos pueden tardar más tiempo en adquirirse.

Reintentos

La migración controla los problemas de conexión transitorios y las conexiones adicionales normalmente se aprovisionan por adelantado para este propósito. Examinamos la configuración de migración, especialmente el número de operaciones de lectura paralelas en el origen y aplicamos un factor (normalmente ~1,5) y creamos esas conexiones por adelantado. De este modo, el servicio se asegura de que podemos mantener las operaciones en ejecución en paralelo. En cualquier momento, si hay una pérdida de conexión o el servicio no puede obtener un bloqueo, el servicio usa las conexiones sobrantes aprovisionadas para reintentar la migración. Si se agotan todas las conexiones aprovisionadas, lo que da lugar a la pérdida de la sincronización en un momento dado, la migración debe reiniciarse desde el principio. En los casos de éxito y error, este servicio de migración sin conexión realiza todas las acciones de limpieza y el usuario no tiene que realizar ninguna acción de limpieza explícita.

Pasos siguientes

• Más información acerca de la replicación de datos de entrada

• Tutorial: Migración de MySQL a Azure Database for MySQL sin conexión mediante DMS