Configurar una base de datos de origen

MySQL   |  PostgreSQL   |  PostgreSQL a AlloyDB

Información general

Database Migration Service admite migraciones únicas y continuas desde bases de datos de origen a bases de datos de destino de Cloud SQL.

Entre las bases de datos de origen compatibles con MySQL se incluyen las siguientes:

• Amazon RDS 5.6, 5.7 y 8.0
• MySQL autogestionado (en las instalaciones o en cualquier VM en la nube que controles por completo) 5.5, 5.6, 5.7 y 8.0
• Cloud SQL para MySQL 5.6, 5.7, 8.0 y 8.4
• Amazon Aurora 5.6, 5.7 y 8.0
• Microsoft Azure Database for MySQL 5.7 y 8.0

En el caso de 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 y 8.0.42.

Para configurar una base de datos de origen, sigue estos pasos:

1. Fuentes de Cloud SQL: si vas a migrar de una instancia de Cloud SQL que usa una conexión de IP privada a una instancia de Cloud SQL que usa un intervalo de direcciones que no es RFC 1918, añade el intervalo que no es RFC 1918 a la configuración de red de tu instancia de Cloud SQL de origen. Consulta Configurar redes autorizadas en la documentación de Cloud SQL.
2. 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 las operaciones de DDL se han detenido. Una vez que la migración esté en la fase de CDC, podrá reanudar las operaciones del DDL.
3. Asegúrate de que tu base de datos de origen no contenga metadatos definidos por usuarios con la cláusula DEFINER. Consulta Crear y ejecutar una tarea de migración de MySQL que contenga metadatos con una cláusula DEFINER.
4. Si tu base de datos de origen contiene objetos que hacen referencia a tablas de los esquemas de sistema mysql, performance_schema, information_schema, ndbinfo o sys, asegúrate de que las bases de datos de réplica también contengan estas tablas de esquemas de sistema.

   Si las bases de datos de réplica no tienen estas tablas, es posible que el trabajo de migración falle y se muestre el error Unknown table in system schema .

5. Debes asignar a la opción server-id un valor igual o superior a 1. Para obtener más información, consulta Opciones y variables de replicación y almacenamiento de registros binarios.
6. Configura el registro del identificador de transacción global (GTID) asignando el valor ON o OFF a GTID_MODE. No se admite el valor GTID_MODE de ON_PERMISSIVE.

   El valor que debes usar depende de los requisitos de la migración:

   • Si migras a una instancia de destino que ya existe y que tiene réplicas de lectura habilitadas, define GTID_MODE como ON.
   • Si vas a usar un volcado manual para migrar tus datos, define GTID_MODE como ON.
   Para obtener más información sobre GTID_MODE, consulta Variable de sistema de ID de transacción global.

7. Debes configurar la cuenta de usuario utilizada para conectarte a la base de datos de origen para que acepte conexiones de cualquier origen (host = %). Se puede restringir el acceso a este usuario en un paso posterior.

   Para reducir la posibilidad de que otros aspectos de la base de datos se vean afectados, te recomendamos que crees una cuenta diferente para esto.

   Hay cuatro tipos de combinaciones de migraciones y volcados:

   • Tipo 1: migración continua y volcado gestionado
   • Tipo 2: migración continua y volcado manual
   • Tipo 3: Migración única y volcado gestionado
   • Tipo 4: Migración única y volcado manual

   En las pestañas de abajo se indican los privilegios de cada tipo de migración y combinación de volcado.

   TYPE.

   La cuenta de usuario que configures debe tener los siguientes privilegios:

   • REPLICATION SLAVE
   • EXECUTE
   • SELECT
   • SHOW VIEW
   • REPLICATION CLIENT
   • RELOAD
   • TRIGGER
   • (Solo para migrar desde Amazon RDS y Amazon Aurora) LOCK TABLES

   MySQL versión 8.0 o posterior: para conseguir un rendimiento óptimo, asegúrate de no conceder el privilegio BACKUP_ADMIN a esta cuenta.

   Para obtener más información sobre los privilegios, consulta Privilegios proporcionados por MySQL. Para obtener más información sobre las cuentas de usuario, consulta el artículo Formato de cuenta de usuario de MySQL.

   TYPE.

   La cuenta de usuario que configures debe tener los siguientes privilegios:

   • REPLICATION SLAVE
   • EXECUTE

   Para obtener más información sobre los privilegios, consulta Privilegios proporcionados por MySQL. Para obtener más información sobre las cuentas de usuario, consulta el artículo Formato de cuenta de usuario de MySQL.

   Tipo 3

   La cuenta de usuario que configures debe tener los siguientes privilegios:

   • SELECT
   • SHOW VIEW
   • TRIGGER
   • (Solo para migrar desde Amazon RDS y Amazon Aurora) LOCK TABLES
   • (Solo para migrar desde fuentes con el ajuste GTID_MODE = ON)RELOAD

   MySQL versión 8.0 o posterior: para conseguir un rendimiento óptimo, asegúrate de no conceder el privilegio BACKUP_ADMIN a esta cuenta.

   Para obtener más información sobre los privilegios, consulta Privilegios proporcionados por MySQL. Para obtener más información sobre las cuentas de usuario, consulta el artículo Formato de cuenta de usuario de MySQL.

   Tipo 4

   No se necesitan privilegios.

   Para obtener más información sobre los privilegios, consulta Privilegios proporcionados por MySQL. Para obtener más información sobre las cuentas de usuario, consulta el artículo Formato de cuenta de usuario de MySQL.

8. Antes de configurar los registros binarios, asegúrate de que:
   • Habilita los registros binarios en tu base de datos de origen.
   • Usa el almacenamiento de registros binarios basado en filas.
   • Conserva los registros binarios durante un periodo lo suficientemente largo como para admitir la migración de la base de datos. Por lo general, una semana es suficiente.

   Para configurar los registros binarios, despliega la sección de tu fuente:

   MySQL autogestionado

   En función de tu versión de MySQL, especifica un periodo con tiempo suficiente para que se produzca la replicación:

   • MySQL 5.5 - 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 la habilites. Para obtener más información, consulta la documentación de Microsoft.

   Configure los siguientes parámetros obligatorios:

   1. Asigna a binlog_expire_logs_seconds un periodo lo suficientemente largo como para admitir la migración de la base de datos.

      Para obtener más información, consulta Configurar parámetros de servidor en Azure Database for PostgreSQL y el parámetro binlog_expire_logs_seconds en la documentación de Microsoft.

   2. Reinicia el servidor para que los cambios que has realizado surtan efecto.

   Amazon RDS

   En Amazon RDS, la configuración basada en filas se define 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 definir el periodo de conservación de los registros binarios en Amazon RDS, utiliza el procedimiento almacenado mysql.rds_set_configuration y especifica un periodo con tiempo suficiente para que se produzca la replicación. Por ejemplo:

   call mysql.rds_set_configuration('binlog retention hours',168);

   El valor máximo que puedes definir para este parámetro es de 168 horas (o 7 días).

   Amazon Aurora

   En Amazon Aurora, sigue estos pasos:

   1. Habilita el registro binario en tu base de datos MySQL.
   2. Define el periodo de conservación de los registros binarios:

      mysql> call mysql.rds_set_configuration('binlog retention hours', 168);

      Introduce este comando porque quieres asegurarte de que la replicación se realice correctamente configurando tu sistema para que conserve los registros binarios durante un mínimo de 7 días (o 168 horas).
   3. Reinicia el servidor para que los cambios que has realizado surtan efecto.
9. Todas las tablas (excepto las de las bases de datos del sistema) utilizan el motor de almacenamiento InnoDB.

   Para obtener más información sobre InnoDB, consulta El motor de almacenamiento InnoDB. Para obtener más información sobre cómo convertir a InnoDB, consulta el artículo Convertir tablas de MyISAM a InnoDB.

10. La contraseña de la cuenta de usuario utilizada para conectarse a la base de datos de origen no debe tener más de 32 caracteres. Este problema es específico de la replicación de MySQL.

    Para obtener más información sobre la limitación de la longitud de la contraseña de usuario de MySQL, consulta el error #43439 de MySQL.

11. Solo para fuentes de Microsoft Azure Database for MySQL: comprueba el valor de la configuración require_secure_transport.

    De forma predeterminada, las bases de datos de Microsoft Azure requieren el cifrado SSL/TLS para todas las conexiones entrantes. En función del valor de require_secure_transport, utiliza uno de los siguientes ajustes de cifrado cuando crees el perfil de conexión de origen:

    • Si require_secure_transport está configurado como on, selecciona Básico, TLS o mTLS.
    • Si require_secure_transport está configurado como off, selecciona Ninguno.