Usar una importación personalizada para configurar la replicación a partir de bases de datos externas de gran tamaño

En esta página se describe el proceso para configurar la replicación de servidores externos mediante una importación personalizada. Estos pasos son la mejor opción cuando necesitas replicar datos de una base de datos externa de gran tamaño.

Debes completar todos los pasos de esta página. Cuando termine, podrá administrar y monitorizar la réplica del mismo modo que lo haría con cualquier otra instancia de Cloud SQL.

Este proceso solo se admite en servidores externos configurados para usar la replicación basada en identificadores de transacciones globales (GTIDs). Antes de poder iniciar la replicación, debes cargar datos del servidor externo en la réplica de Cloud SQL. Si no usas la replicación basada en GTID, Cloud SQL no podrá identificar la posición exacta del registro binario desde la que empezar la replicación. Si no puedes usar la replicación basada en GITD, debes configurar tu herramienta de volcado para que establezca un bloqueo global de solo lectura durante el proceso de volcado.

Antes de empezar

Antes de empezar, debes configurar el servidor externo, crear la instancia de representación de origen y configurar la réplica de Cloud SQL.

Actualizar los permisos del usuario de replicación

El usuario de replicación del servidor externo está configurado para aceptar conexiones de cualquier host (%). Debes actualizar esta cuenta de usuario para que solo se pueda usar con la réplica de Cloud SQL. Abre un terminal en el servidor de la base de datos de origen e introduce estos comandos:

Cliente mysql 

    UPDATE mysql.user
    SET Host='NEW_HOST' WHERE Host='OLD_HOST' AND User='USERNAME';
    GRANT REPLICATION SLAVE, EXECUTE ON *.*
    TO 'GCP_USERNAME'@'HOST';
    FLUSH PRIVILEGES;

Ejemplo 

UPDATE mysql.user
SET Host='192.0.2.0' WHERE Host='%' AND User='replicationUser';
GRANT REPLICATION SLAVE, EXECUTE ON *.*
TO 'gcp_user'@'gmail.com';
FLUSH PRIVILEGES;
Propiedad Descripción
NEW_HOST Especifica la IP de salida de la réplica de Cloud SQL.
OLD_HOST El valor actual asignado a Host que quieras cambiar.
USERNAME La cuenta de usuario de replicación del servidor externo.
GCP_USERNAME Nombre de usuario de la cuenta de usuario de GCP.
HOST Nombre de host de la cuenta de usuario de GCP.

Configurar la réplica de Cloud SQL como instancia principal

Como las instancias de réplica de Cloud SQL son de solo lectura, para realizar una importación personalizada, debes promocionar la réplica de Cloud SQL a una instancia independiente. Una vez que se haya completado la importación inicial de datos, vuelve a convertir la instancia en una réplica.

Realizar un volcado e importación personalizados

En esta sección, te mostramos cómo crear el archivo de volcado e importarlo a la réplica de Cloud SQL final mediante mydumper o las utilidades de cliente mysqldump.

Cuando vuelques los datos, es posible que tengas que excluir las bases de datos genéricas de MySQL, incluidas mysql y sys, si existen en la instancia de origen. De lo contrario, no se podrán importar los datos. Consulta ¿Cómo puedo excluir (o incluir) bases de datos?

Usa mydumper y myloader

Para crear un archivo de volcado e importarlo a Cloud SQL, sigue estos pasos:

  1. Crea un archivo de volcado de la base de datos del servidor externo con mydumper.

       $ mydumper -u USERNAME -p PASSWORD \
              --threads=16 -o ./backup \
              -h HOST \
              --no-locks \
              --regex '^(?!(mysql\.|sys\.))'
    Propiedad Descripción
    USERNAME Nombre de la cuenta de usuario de replicación o de la cuenta de usuario del servidor externo que tiene permisos de lectura de la base de datos.
    PASSWORD Contraseña del usuario de replicación.
    HOST Dirección IPv4 o DNS del servidor externo.

  2. Importa los datos en la instancia de Cloud SQL mediante myloader.

     $ myloader -u REPLICA_USERNAME -p REPLICA_PASSWORD \
            --threads=16 \
            -d ./backup -h HOST -o
    Propiedad Descripción
    REPLICA_USERNAME La cuenta de usuario de la instancia de Cloud SQL.
    REPLICA_PASSWORD Contraseña de usuario de la instancia de Cloud SQL.
    HOST La IPv4 de la instancia de Cloud SQL.

  3. Anota el GTID o la información del archivo de registro binario de la volcado de datos. Necesitará esta información al configurar la replicación con los procedimientos almacenados.

    Para obtener el GTID o la información del archivo de registro binario de la volcado de datos, ejecuta el siguiente comando:

      sudo cat ./backup/metadata

Usar mysqldump

  1. Crea un volcado con mysqldump:

    mysqldump 

    mysqldump \
    --host=EXTERNAL_HOST \
    --port=EXTERNAL_PORT \
    --user=USERNAME\
    --password=PASSWORD \
    --databases=DATABASE_LIST  \
    --hex-blob \
    --master-data=EXTERNAL_DATA  \
    --no-autocommit \
    --default-character-set=utf8mb4 \
    --single-transaction \
    GTID_PURGED \
    ADD_DROP_TABLE \
    ROUTINES \
    COMPRESS \
    GZIP
    Propiedad Descripción
    EXTERNAL_HOST Dirección IPv4 o DNS del servidor externo.
    EXTERNAL_PORT El puerto del servidor externo. Si el servidor externo está alojado en Cloud SQL, esta opción es 3306.
    USERNAME Nombre de la cuenta de usuario de replicación o de la cuenta de usuario del servidor externo que tiene permisos de lectura de la base de datos.
    USER_PASSWORD Contraseña del usuario de replicación.
    DATABASE_LIST Lista separada por espacios de todas las bases de datos del servidor externo, excepto las bases de datos del sistema (sys, mysql, performance_schema y information_schema). Usa el comando SHOW DATABASES de MySQL para enumerar tus bases de datos.
    EXTERNAL_DATA Si tu servidor externo no admite GTID y tienes permiso para acceder al bloqueo de lectura global en él, usa --master-data=1. De lo contrario, no uses esta propiedad.
    GTID_PURGED Si tu servidor externo admite GTID, usa --set-gtid-purged=on. De lo contrario, no uses esta propiedad.
    ADD_DROP_TABLE Si quieres añadir una instrucción DROP TABLE antes de cada instrucción CREATE TABLE, incluye --add-drop-table.
    ROUTINES Si quieres mostrar las rutinas almacenadas, como los procedimientos y las funciones, en la salida de las bases de datos volcadas, incluye --routines.
    COMPRESS Si quieres comprimir toda la información que se envía entre la réplica de Cloud SQL y el servidor externo, usa --compress.
    GZIP Si quieres comprimir aún más el archivo de volcado, usa | gzip. Si tu base de datos contiene datos que no se comprimen bien, como datos binarios no comprimibles o imágenes JPG, no uses esta opción.

    Ejemplo 

    mysqldump \
    --host=192.0.2.1 \
    --port=3306 \
    --user=replicationUser \
    --password \
    --databases guestbook journal \
    --hex-blob \
    --master-data=1 \
    --no-autocommit \
    --default-character-set=utf8mb4 \
    --single-transaction \
    --compress \
    | gzip

  2. Anota el GTID o la información del archivo de registro binario de la volcado de datos. Necesitas esta información para configurar la replicación con los procedimientos almacenados de Cloud SQL.

    En el caso del GTID, busca una línea similar a la siguiente:

       SET @@GLOBAL.GTID_PURGED='32eb1e6a-17b6-11ea-a39e-06d94ac3ec98:1-33496';

    En el archivo binlog, busca una línea similar a la siguiente:

       CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.033877', MASTER_LOG_POS=360;

  3. Elimina las siguientes líneas del archivo de volcado que requieren privilegios de superusuario. Como los usuarios de Cloud SQL no tienen privilegios de superusuario, estas líneas provocan que la importación falle.

    Para la replicación basada en GTID: elimina la instrucción SET GTID_PURGED junto con la instrucción de configuración de la variable de sesión en el volcado. Por ejemplo:

       ...
   SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
   SET @@SESSION.SQL_LOG_BIN= 0;
   ...
   SET @@GLOBAL.GTID_PURGED='32eb1e6a-17b6-11ea-a39e-06d94ac3ec98:1-33496';
   ...
   SET @@SESSION.SQL_LOG_BIN=@MYSQLDUMP_TEMP_LOG_BIN;

    En el caso de la replicación basada en binlogs, elimina la instrucción CHANGE MASTER. Por ejemplo:

       ...
   CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.033877', MASTER_LOG_POS=360;
    ...

  4. Importa los datos en la réplica de Cloud SQL mediante la CLI de mysql:

    mysql 

    mysql -h REPLICA_HOST -u REPLICA_USER \
-p REPLICA_DATABASE_NAME RESULT_FILE
    Propiedad Descripción
    REPLICA_HOST Host en el que se encuentra el servidor MySQL.
    REPLICA_USER Nombre de usuario de MySQL que se usará al conectarse al servidor.
    REPLICA_DATABASE_NAME Nombre de la base de datos en la que se encuentran los datos.
    RESULT_FILE Nombre del archivo de volcado que se va a importar.

    Ejemplo 

      mysql -h 255.255.255.255 -u replica_username -p replica_db < result.sql

También puedes importar el archivo de volcado mediante un Google Cloud contenedor. Consulta Importar datos de un archivo de volcado de SQL en Cloud SQL.

Rebajar la instancia de Cloud SQL

Para degradar la instancia de Cloud SQL a una réplica de Cloud SQL, usa el método demoteMaster en la instancia.

  1. Prepara un archivo JSON de solicitud con el nombre de la instancia que quieras degradar.

    JSON de origen 

     {
    "demoteMasterContext": {
      "masterInstanceName": SOURCE_REPRESENTATION_INSTANCE_NAME,
      "skipReplicationSetup": true
      }
 }
    Propiedad Descripción
    SOURCE_REPRESENTATION_INSTANCE_NAME Nombre de la instancia de representación de origen.

    Ejemplo 

       {
     "demoteMasterContext": {
       "masterInstanceName": "cloudsql-source-instance",
       "skipReplicationSetup": true
     }
   }

  2. Abre un terminal y usa los siguientes comandos para invocar demoteMaster:

    curl 

      gcloud auth login
  ACCESS_TOKEN="$(gcloud auth print-access-token)"
  curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
    --header 'Content-Type: application/json' \
    --data @JSON_PATH \
    -X POST \
  https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT-ID/instances/INSTANCE-NAME/demoteMaster
    Propiedad Descripción
    JSON_PATH La ruta al archivo JSON.
    PROJECT_ID El ID de tu proyecto en Google Cloud.
    INSTANCE-NAME Nombre de la instancia que se va a degradar.

    Ejemplo 

       gcloud auth login
   ACCESS_TOKEN="$(gcloud auth print-access-token)"
   curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data @./source.json \
     -X POST \
   https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/cloudsql-replica-instance/demoteMaster

Qué deberías ver cuando termines

Para comprobar que las instancias se han configurado correctamente, vaya a la página Instancias de Cloud SQL.

Deberías ver tu instancia de representación de origen y la réplica de Cloud SQL. Tienen un aspecto similar al siguiente:

ID de instancia Tipo IP pública
(-) source-representation-instance Primaria externa de MySQL 10.68.48.3:3306
     replica-instance Réplica de lectura de MySQL 34.66.48.59

Iniciar la replicación en la instancia de Cloud SQL

En este paso se usan procedimientos almacenados de Cloud SQL. Los procedimientos almacenados de Cloud SQL se instalan después de llamar a la solicitud demoteMaster. Se eliminan después de llamar a promoteReplica. Para obtener más información, consulta Procedimientos almacenados para la gestión de la replicación.

  1. Inicia sesión en la instancia de réplica. Para obtener más información, consulta Conectarse mediante un cliente de base de datos desde una máquina local.

  2. Usa el procedimiento almacenado mysql.resetMaster para restablecer la configuración de la replicación.

     mysql> call mysql.resetMaster();

  3. Configura la replicación. En este paso se requiere la información de GTID o binlog que has anotado anteriormente.

    GTID

    1. Configure el campo gtid_purged con el procedimiento almacenado mysql.skipTransactionWithGtid(GTID_TO_SKIP).
    Propiedad Descripción
    GTID_TO_SKIP El valor de GTID set que se va a configurar.

    Por ejemplo: 

        mysql> call mysql.skipTransactionWithGtid('32eb1e6a-17b6-11ea-a39e-06d94ac3ec98:1-33496');

    1. Ejecuta el procedimiento almacenado mysql.setupExternalSourceAutoPosition(HOST, PORT, USER_NAME, USER_PASSWORD, MASTER_AUTO_POSITION, USE_SSL, USE_SSL_CLIENT_AUTH).
    Propiedad Descripción
    HOST Punto final de origen.
    PORT Puerto de origen.
    USER_NAME Usuario de origen.
    USER_PASSWORD Contraseña del usuario de origen.
    MASTER_AUTO_POSITION Valor del parámetro master_auto_position. Los valores posibles son 0 y 1.
    USE_SSL Si se debe usar la replicación basada en SSL. Los valores posibles son true y false. Si el valor es true, debes definir el campo caCertificate en la solicitud DemoteMaster.
    USE_SSL_CLIENT_AUTH Indica si se debe usar la autenticación de cliente SSL. Los valores posibles son true y false. Si el valor es true, debes definir los campos clientKey y clientCertificates en la solicitud demoteMaster. 
        mysql> call mysql.setupExternalSourceAutoPosition('1.1.1.1', 3306, \
    'USERNAME', 'PASSWORD', \
    /* master_auto_position= */ 1,false, false); \

    binlog

    Ejecuta el procedimiento almacenado mysql.setupExternalSource(HOST, PORT, USER_NAME, USER_PASSWORD, SOURCE_LOG_NAME, SOURCE_LOG_POS, USE_SSL, USE_SSL_CLIENT_AUTH).

    Propiedad Descripción
    HOST Punto final de origen.
    PORT Puerto de origen.
    USER_NAME Usuario de origen.
    USER_PASSWORD Contraseña del usuario de origen.
    SOURCE_LOG_NAME El nombre del registro binario de la instancia de base de datos de origen que contiene la información de replicación.
    SOURCE_LOG_POS Ubicación del registro binario mysql_binary_log_file_name en la que la replicación empieza a leer la información de replicación.
    USE_SSL Si se debe usar la replicación basada en SSL. Los valores posibles son true y false. Si el valor es true, debes definir el campo caCertificate en la solicitud DemoteMaster.
    USE_SSL_CLIENT_AUTH Indica si se debe usar la autenticación de cliente SSL. Los valores posibles son true y false. Si el valor es true, debes definir los campos clientKey y clientCertificates en la solicitud demoteMaster. 
        mysql> call mysql.setupExternalSource('1.1.1.1', 3306, \
    'user_name', 'password', 'mysql-bin-changelog.033877', 360, \
    false, false);

  4. Usa el procedimiento almacenado mysql.startReplication() para iniciar la replicación desde la base de datos externa.

       mysql> call mysql.startReplication();

  5. Verifica el estado de la réplica. Asegúrate de que en los campos Slave_IO_Running y Slave_SQL_Running se indique YES.

       mysql> show slave status\G

    La salida de este comando es similar a la siguiente:

       *************************** 1. row ***************************
                   Slave_IO_State: Waiting for master to send event
                      Master_Host: 1.1.1.1
                      Master_User: user_name
                      Master_Port: 3306
                    Connect_Retry: 60
                  Master_Log_File: mysql-bin-changelog.000001
              Read_Master_Log_Pos: 1
                   Relay_Log_File: relay-log.000002
                    Relay_Log_Pos: 1
            Relay_Master_Log_File: mysql-bin-changelog.000001
                 Slave_IO_Running: Yes
                Slave_SQL_Running: Yes
                  Replicate_Do_DB:
              Replicate_Ignore_DB:
               Replicate_Do_Table:
           Replicate_Ignore_Table:
          Replicate_Wild_Do_Table:
      Replicate_Wild_Ignore_Table: mysql.%
                       Last_Errno: 0
                       Last_Error:
                     Skip_Counter: 0
              Exec_Master_Log_Pos: 412
                  Relay_Log_Space: 752
                  Until_Condition: None
                   Until_Log_File:
                    Until_Log_Pos: 0
               Master_SSL_Allowed: No
               Master_SSL_CA_File:
               Master_SSL_CA_Path:
                  Master_SSL_Cert:
                Master_SSL_Cipher:
                   Master_SSL_Key:
            Seconds_Behind_Master: 0
    Master_SSL_Verify_Server_Cert: No
                    Last_IO_Errno: 0
                    Last_IO_Error:
                   Last_SQL_Errno: 0
                   Last_SQL_Error:
      Replicate_Ignore_Server_Ids:
                 Master_Server_Id: 1509941531
                      Master_UUID: 1cb2c80e-90f0-11eb-9ea3-02389b1c2e6f
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all r
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set: 478af53c-bd24-11eb-be72-42010a80002a:1-226
                Auto_Position: 0
   1 row in set (0.00 sec)

Continuar con la replicación

Una vez que inicies la replicación desde el servidor externo, tendrás que monitorizarla y, a continuación, completar la migración. Para obtener más información, consulta Monitorizar la replicación.

Solucionar problemas

Problema Solución de problemas
Lost connection to MySQL server during query when dumping table. Es posible que la fuente haya dejado de estar disponible o que el volcado contenga paquetes demasiado grandes.

Asegúrate de que el primario externo esté disponible para conectarse. También puedes modificar los valores de las marcas net_read_timeout y net_write_timeout en la instancia de origen para detener el error. Para obtener más información sobre los valores permitidos de estas marcas, consulta el artículo Configurar marcas de base de datos.

Para obtener más información sobre el uso de las marcas mysqldump para la migración de importaciones gestionadas, consulta Marcas de sincronización inicial permitidas y predeterminadas.
La migración de datos inicial se ha realizado correctamente, pero no se están replicando datos. Una posible causa principal podría ser que tu base de datos de origen haya definido marcas de replicación que provoquen que no se repliquen algunos o todos los cambios de la base de datos.

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 instancia principal para ver la configuración actual.
La migración de datos inicial se ha realizado correctamente, pero la replicación de datos deja de funcionar al cabo de un tiempo. Puedes probar a realizar lo siguiente:

  • Consulta las métricas de replicación de tu instancia réplica en la sección Cloud Monitoring de la consola de Google Cloud .
  • Los errores del subproceso de E/S o del subproceso SQL de MySQL se pueden encontrar en Cloud Logging en los archivos mysql.err log.
  • El error también se puede encontrar al conectarse a la instancia de réplica. Ejecuta el comando SHOW SLAVE STATUS y comprueba los siguientes campos en el resultado:
    • Slave_IO_Running
    • Slave_SQL_Running
    • Last_IO_Error
    • Last_SQL_Error
mysqld check failed: data disk is full. El disco de datos de la instancia réplica está lleno.

Aumenta el tamaño del disco de la instancia réplica. Puedes aumentar el tamaño del disco manualmente o habilitar el aumento automático del almacenamiento.

Revisar los registros de replicación

Cuando verifiques la configuración de la réplica, se generarán registros.

Para ver estos registros, sigue estos pasos:

  1. Ve al visualizador de registros de la Google Cloud consola.

    Ir al visualizador de registros

  2. Selecciona la réplica de Cloud SQL en el menú desplegable Instancia.
  3. Selecciona el archivo de registro replication-setup.log.

Si la réplica de Cloud SQL no puede conectarse al servidor externo, comprueba lo siguiente:

  • Cualquier cortafuegos del servidor externo está configurado para permitir conexiones desde la dirección IP de salida de la réplica de Cloud SQL.
  • La configuración de SSL/TLS es correcta.
  • El usuario, el host y la contraseña de la réplica son correctos.

Siguientes pasos