Descripción general
Database Migration Service admite migraciones continuas y únicas desde bases de datos de origen a bases de datos de destino de Cloud SQL.
Entre las bases de datos de origen admitidas para MySQL, se incluyen las siguientes:
- Amazon RDS 5.6, 5.7, 8.0 y 8.4
- MySQL autoadministrado (local o en cualquier VM en la nube que controlas por completo) 5.5, 5.6, 5.7, 8.0 y 8.4
- Cloud SQL para MySQL 5.6, 5.7, 8.0 y 8.4
- Amazon Aurora 5.6, 5.7, 8.0 y 8.4
- Microsoft Azure Database for MySQL 5.7, 8.0 y 8.4
Para las fuentes de MySQL 8.0, Database Migration Service también admite las siguientes versiones secundarias: 8.0.18, 8.0.26, 8.0.27, 8.0.28, 8.0.30, 8.0.31, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36, 8.0.37, 8.0.39, 8.0.40, 8.0.41, 8.0.42 y 8.0.43.
Para configurar una base de datos de origen, completa los siguientes pasos:
- Para fuentes de Cloud SQL: Si migras desde una instancia de Cloud SQL que usa una conexión de IP privada a una instancia de Cloud SQL que usa un rango de IP de dirección que no es RFC 1918, agrega el rango que no es RFC 1918 a la configuración de red de tu instancia de Cloud SQL fuente. Consulta Configura redes autorizadas en la documentación de Cloud SQL.
- Antes de migrar datos de la base de datos de origen a la de destino, asegúrate de detener todas las operaciones de escritura del lenguaje de definición de datos (DDL) durante la fase de volcado completo. Puedes usar una secuencia de comandos para verificar que se detengan las operaciones de DDL. Una vez que la migración esté en la fase de CDC, puedes reanudar las operaciones de DDL.
- Asegúrate de que tu base de datos de origen no contenga metadatos definidos por usuarios con la cláusula DEFINER. Consulta Crea y ejecuta un trabajo de migración de MySQL que contenga metadatos con una cláusula DEFINER.
- Si tu base de datos de origen contiene objetos que hacen referencia a tablas en los esquemas del sistema
mysql,performance_schema,information_schema,ndbinfoosys, asegúrate de que las bases de datos de réplica también contengan estas tablas de esquema del sistema.Si las bases de datos de réplica no tienen estas tablas, es posible que tu trabajo de migración falle con el error
Unknown table in system schema. - Debes establecer la opción server-id en un valor de 1 o mayor. Para obtener más información, consulta Opciones y variables de replicación y registro binario.
- Configura el registro del ID de transacción global (GTID) estableciendo
GTID_MODEenONoOFF. No se admite el valorGTID_MODEdeON_PERMISSIVE.El valor que debes usar depende de los requisitos de migración:
- Si
migras a una instancia de destino existente que tiene habilitadas réplicas de lectura, establece
GTID_MODEenON. - Si usas una volcado manual para migrar tus datos, configura
GTID_MODEcomoON.
GTID_MODE, consulta Variable del sistema de ID de transacción global. - Si
migras a una instancia de destino existente que tiene habilitadas réplicas de lectura, establece
-
Debes configurar la cuenta de usuario que se usa para conectarte a la base de datos de origen para que acepte conexiones desde cualquier lugar (host =
%). Se puede restringir el acceso a este usuario en un paso posterior.Para limitar la posibilidad de poner en riesgo otros aspectos de la base de datos, te recomendamos que crees una cuenta aparte.
Existen cuatro tipos de combinaciones de migraciones y volcados:
- Tipo 1: Migración continua y volcado administrado
- Tipo 2: Migración continua y volcado manual
- Tipo 3: Migración única y volcado administrado
- Tipo 4: Migración única y volcado manual
En las siguientes pestañas, se enumeran los privilegios para cada tipo de combinación de migración y volcado.
Tipo 1
La cuenta de usuario que configures debe contar con los siguientes privilegios:
REPLICATION SLAVEEXECUTESELECTSHOW VIEWREPLICATION CLIENTRELOADTRIGGER- (Para migrar desde Amazon RDS y Amazon Aurora únicamente)
LOCK TABLES
MySQL 8.0 o versiones posteriores: Para obtener un rendimiento óptimo, asegúrate de no otorgar el privilegio
BACKUP_ADMINa esta cuenta.Tipo 2
La cuenta de usuario que configures debe contar con los siguientes privilegios:
REPLICATION SLAVEEXECUTE
Tipo 3
La cuenta de usuario que configures debe contar con los siguientes privilegios:
SELECTSHOW VIEWTRIGGER- (Para migrar desde Amazon RDS y Amazon Aurora únicamente)
LOCK TABLES - (Solo para migrar desde fuentes con el parámetro de configuración
GTID_MODE = ON)RELOAD
MySQL 8.0 o versiones posteriores: Para obtener un rendimiento óptimo, asegúrate de no otorgar el privilegio
BACKUP_ADMINa esta cuenta.Tipo 4
No se requieren privilegios.
- Antes de configurar los registros binarios, asegúrate de hacer lo siguiente:
- Habilita los registros binarios en tu base de datos de origen.
- Usar el registro binario basado en filas
- Conserva los registros binarios durante un período lo suficientemente extenso como para admitir la migración de la base de datos. Por lo general, una semana es suficiente.
Para configurar los registros binarios, expande la sección de tu fuente:
MySQL autoalojado
Según tu versión de MySQL, especifica un período con tiempo suficiente para que se produzca la replicación:
- MySQL 5.5 a 5.7:
expire_logs_days - MySQL 8.0:
expire_logs_days,binlog_expire_logs_seconds
Microsoft Azure Database for MySQL
El registro binario está habilitado de forma predeterminada en Microsoft Azure Database for MySQL. No es necesario que lo habilites. Para obtener más información, consulta la documentación de Microsoft.
Configura los siguientes parámetros obligatorios:
Establece
binlog_expire_logs_secondsen un período lo suficientemente largo como para admitir la migración de la base de datos.Para obtener más información, consulta Configura los parámetros del servidor en Azure Database for PostgreSQL y el parámetro
binlog_expire_logs_secondsen la documentación de Microsoft.- Reinicia el servidor para que se apliquen los cambios.
Amazon RDS
En el caso de Amazon RDS, debes establecer la configuración basada en filas en el grupo de parámetros configurando el parámetro
binlog retention hours. Este parámetro se usa para especificar cuántas horas debe conservar Amazon RDS los archivos de registro binario.Para establecer el período de retención de los registros binarios en Amazon RDS, usa el procedimiento almacenado
mysql.rds_set_configurationy especifica un período con tiempo suficiente para que se produzca la replicación. Por ejemplo:call mysql.rds_set_configuration('binlog retention hours',168);Amazon Aurora
Para Amazon Aurora, sigue estos pasos:
- Habilita el registro binario para tu base de datos de MySQL.
- Configura el período de retención de registros binarios:
mysql> call mysql.rds_set_configuration('binlog retention hours', 168); - Reinicia el servidor para que se apliquen los cambios.
- Todas las tablas (excepto las de las bases de datos del sistema) deben usar el motor de almacenamiento InnoDB.
- La contraseña de la cuenta de usuario que se usa para conectarse a la base de datos de origen no debe superar los 32 caracteres de longitud. Este es un problema específico de la replicación de MySQL.
Solo para fuentes de Microsoft Azure Database for MySQL: Verifica el valor de tu parámetro de configuración
require_secure_transport.De forma predeterminada, las bases de datos de Microsoft Azure requieren la encriptación SSL/TLS para todas las conexiones entrantes. Según el valor de
require_secure_transport, usa uno de los siguientes parámetros de configuración de encriptación cuando crees el perfil de conexión de origen:- Si
require_secure_transportestá establecido enon, selecciona Básico, TLS o mTLS. - Si
require_secure_transportse establece enoff, selecciona None.
- Si