Usar una importación gestionada para configurar la replicación desde bases de datos externas

En esta página se describe cómo configurar y usar una importación gestionada de datos al replicar desde un servidor externo a Cloud SQL.

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

Antes de empezar

Antes de empezar, sigue estos pasos:

  1. Configura el servidor externo.

  2. Crea la instancia de representación de la fuente.

  3. Configura la réplica de Cloud SQL.

Actualizar los privilegios del usuario de replicación

El usuario de replicación del servidor externo está configurado para aceptar conexiones de cualquier host (%). Actualiza esta cuenta de usuario para que solo se pueda usar con la réplica de Cloud SQL.

Privilegios necesarios

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

A continuación se indican los privilegios de cada tipo de migración y combinación de acceso.

TYPE.

La cuenta de usuario debe tener los siguientes privilegios:

En las versiones 8.0 y posteriores de MySQL, se recomienda omitir el privilegio BACKUP ADMIN para obtener un rendimiento óptimo.

TYPE.

La cuenta de usuario debe tener los siguientes privilegios:

Tipo 3

La cuenta de usuario debe tener los siguientes privilegios:

En las versiones 8.0 y posteriores de MySQL, se recomienda omitir el privilegio BACKUP ADMIN para obtener un rendimiento óptimo.

Tipo 4

No se necesitan privilegios.

Actualizar privilegios

Para actualizar los privilegios, abre un terminal en el servidor externo e introduce los siguientes comandos.

Cliente mysql

Para GTID:

    UPDATE mysql.user
      SET Host='NEW_HOST'
      WHERE Host='OLD_HOST'
      AND User='USERNAME';
    GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION_CLIENT,
    RELOAD ON . TO
    'USERNAME'@'HOST';
    FLUSH PRIVILEGES;

Para binlog:

    UPDATE mysql.user
    SET Host='NEW_HOST'
    WHERE Host='OLD_HOST'
    AND User='USERNAME';
    GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION CLIENT,
    RELOAD 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, SELECT, SHOW VIEW, REPLICATION CLIENT,
RELOAD ON *.* TO 'username'@'host.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.
HOST Nombre de host de la cuenta de usuario.

Verificar la configuración de la replicación

Una vez que hayas completado la configuración, asegúrate de que la réplica de Cloud SQL pueda replicar desde el servidor externo.

Los siguientes ajustes de sincronización externa deben ser correctos.

  • Conectividad entre la réplica de Cloud SQL y el servidor externo
  • Privilegios de usuario de replicación
  • Compatibilidad de versiones
  • La réplica de Cloud SQL aún no está replicando
  • Los registros binarios están habilitados en el servidor externo
  • GTID está habilitado si intentas hacer una sincronización externa desde un servidor externo de RDS y utilizas un Google Cloud contenedor.

Para verificar estos ajustes, abre un terminal de Cloud Shell e introduce los siguientes comandos:

curl

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "SYNC_MODE",
         "syncParallelLevel": "SYNC_PARALLEL_LEVEL",
         "mysqlSyncConfig": {
           "initialSyncFlags": "SYNC_FLAGS"
         }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_ID/verifyExternalSyncSettings

Ejemplo

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/myproject/instances/myreplica/verifyExternalSyncSettings

Ejemplo con marcas de sincronización

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
         "mysqlSyncConfig": {
             "initialSyncFlags": [{"name": "max-allowed-packet", "value": "1073741824"}, {"name": "hex-blob"}, {"name": "compress"}]
             }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/verifyExternalSyncSettings

Estas llamadas devuelven una lista de tipo sql#externalSyncSettingErrorList.

Si la lista está vacía, significa que no hay errores. Una respuesta sin errores tiene este aspecto:

  {
    "kind": "sql#externalSyncSettingErrorList"
  }
Propiedad Descripción
SYNC_MODE Asegúrate de que la réplica de Cloud SQL y el servidor externo estén sincronizados después de configurar la replicación. Los modos de sincronización son EXTERNAL_SYNC_MODE_UNSPECIFIED, ONLINE y OFFLINE.
SYNC_PARALLEL_LEVEL

Verifica el ajuste que controla la velocidad a la que se transfieren los datos de las tablas de una base de datos. Están disponibles los siguientes valores:

  • min: Consume la menor cantidad de recursos informáticos de la base de datos. Esta es la velocidad más lenta para transferir datos.
  • optimal: Ofrece un rendimiento equilibrado con una carga óptima en la base de datos.
  • max: Proporciona la mayor velocidad para transferir datos, pero puede aumentar la carga de la base de datos.

Nota: El valor predeterminado de este parámetro es optimal, ya que este ajuste proporciona una buena velocidad para transferir los datos y tiene un impacto razonable en la base de datos. Te recomendamos que uses este valor.

SYNC_FLAGS Lista de marcas de sincronización iniciales que se deben verificar. Solo se recomienda si tienes previsto usar marcas de sincronización personalizadas al replicar desde la fuente. Para ver una lista de las marcas permitidas, consulta Marcas de sincronización inicial.
PROJECT_ID El ID de tu Google Cloud proyecto.
REPLICA_INSTANCE_ID ID de tu réplica de Cloud SQL.

Permiso de bloqueo de lectura global

Si no tienes permiso para acceder al bloqueo de lectura global en el servidor externo (como puede ocurrir con Amazon RDS y Amazon Aurora), pausa las escrituras en tu servidor siguiendo los pasos que se indican a continuación:

  1. Ve al explorador de registros y selecciona tu réplica de Cloud SQL en la lista de recursos. Debería ver una lista de los registros más recientes de su réplica de Cloud SQL. Ignóralos por ahora.
  2. Abre un terminal e introduce los comandos de Iniciar la replicación en el servidor externo para replicar desde el servidor externo.
  3. Vuelve al Explorador de registros. Cuando veas el registro de la siguiente manera, deja de escribir en la base de datos de tu servidor externo. En la mayoría de los casos, solo se requiere durante unos segundos.

       DUMP_IMPORT(START): Start importing data, please pause any write to the
       external primary database.
    
  4. Cuando veas la siguiente entrada de registro en el Explorador de registros, vuelve a habilitar la escritura en la base de datos de tu servidor externo.

       DUMP_IMPORT(SYNC): Consistent state on primary and replica. Writes to the
       external primary may resume.
    
    

Iniciar la replicación en el servidor externo

Una vez que hayas verificado que puedes replicar desde el servidor externo, inicia la replicación. La velocidad de replicación del proceso de importación inicial es de hasta 500 GB por hora. Sin embargo, esta velocidad puede variar en función del nivel de la máquina, el tamaño del disco de datos, el rendimiento de la red y la naturaleza de la base de datos.

Durante el proceso de importación inicial, no realice ninguna operación de DDL en el servidor externo. Si lo hace, podría haber incoherencias durante la importación. Una vez que se completa el proceso de importación, la réplica usa los registros binarios del servidor externo para ponerse al día con el estado actual del servidor externo.

curl

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "SYNC_MODE",
         "skipVerification": "SKIP_VERIFICATION",
         "syncParallelLevel": "SYNC_PARALLEL_LEVEL",
         "mysqlSyncConfig": {
           "initialSyncFlags": "SYNC_FLAGS"
         }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_ID/startExternalSync

Ejemplo

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

Ejemplo con marcas de sincronización

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
         "skipVerification": false,
         "mysqlSyncConfig": {
             "initialSyncFlags": [{"name": "max-allowed-packet", "value": "1073741824"}, {"name": "hex-blob"}, {"name": "compress"}]
             }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/startExternalSync
Propiedad Descripción
SYNC_MODE Verifica que puedes mantener sincronizadas la réplica de Cloud SQL y el servidor externo después de configurar la replicación.
SKIP_VERIFICATION Indica si se debe omitir el paso de verificación integrado antes de sincronizar los datos. Este parámetro solo se recomienda si ya ha verificado su configuración de replicación.
SYNC_PARALLEL_LEVEL

Proporciona un ajuste que controla la velocidad a la que se transfieren los datos de las tablas de una base de datos. Están disponibles los siguientes valores:

  • min: Consume la menor cantidad de recursos informáticos de la base de datos. Esta es la velocidad más lenta para transferir datos.
  • optimal: Ofrece un rendimiento equilibrado con una carga óptima en la base de datos.
  • max: Proporciona la mayor velocidad para transferir datos, pero puede aumentar la carga de la base de datos.

Nota: El valor predeterminado de este parámetro es optimal, ya que este ajuste proporciona una buena velocidad para transferir los datos y tiene un impacto razonable en la base de datos. Te recomendamos que uses este valor.

SYNC_FLAGS Lista de marcas de sincronización iniciales que se deben verificar. Solo se recomienda si tienes previsto usar marcas de sincronización personalizadas al replicar desde la fuente. Para ver una lista de las marcas permitidas, consulta Marcas de sincronización inicial.
PROJECT_ID El ID de tu Google Cloud proyecto.
REPLICA_INSTANCE_ID ID de tu réplica de Cloud SQL.

Indicadores de sincronización inicial

Para migrar con marcas de base de datos personalizadas, puede usar las siguientes marcas permitidas:

  • --add-drop-database
  • --add-drop-table
  • --add-drop-trigger
  • --add-locks
  • --allow-keywords
  • --all-tablespaces
  • --apply-slave-statements
  • --column-statistics
  • --comments
  • --compact
  • --compatible
  • --complete-insert
  • --compress
  • --compression-algorithms
  • --create-options
  • --default-character-set
  • --delayed-insert
  • --disable-keys
  • --dump-date
  • --events
  • --extended-insert
  • --fields-enclosed-by
  • --fields-escaped-by
  • --fields-optionally-enclosed-by
  • --fields-terminated-by
  • --flush-logs
  • --flush-privileges
  • --force
  • --get-server-public-key
  • --hex-blob
  • --ignore-error
  • --ignore-read-lock-error
  • --ignore-table
  • --insert-ignore
  • --lines-terminated-by
  • --lock-all-tables
  • --lock-tables
  • --max-allowed-packet
  • --net-buffer-length
  • --network-timeout
  • --no-autocommit
  • --no-create-db
  • --no-create-info
  • --no-data
  • --no-defaults
  • --no-set-names
  • --no-tablespaces
  • --opt
  • --order-by-primary
  • --pipe
  • --quote-names
  • --quick
  • --replace
  • --routines
  • --secure-auth
  • --set-charset
  • --shared-memory-base-name
  • --show-create-skip-secondary-engine
  • --skip-opt
  • --ssl-cipher
  • --ssl-fips-mode
  • --ssl-verify-server-cert
  • --tls-ciphersuites
  • --tls-version
  • --triggers
  • --tz-utc
  • --verbose
  • --xml
  • --zstd-compression-level

Para ver los valores permitidos, consulta la documentación pública de MySQL.

Controlar la migración

Una vez que hayas iniciado la replicación desde el servidor externo, tendrás que monitorizarla. Para obtener más información, consulta Monitorizar la replicación. A continuación, puedes completar la migración.

Solucionar problemas

Prueba las siguientes opciones para solucionar el problema:

Problema Solución de problemas
La réplica de lectura no ha empezado a replicarse al crearse. Probablemente haya un error más específico en los archivos de registro. Inspecciona los registros en Cloud Logging para encontrar el error real.
No se puede crear una réplica de lectura: error invalidFlagValue. Una de las marcas de la solicitud no es válida. Puede ser una marca que hayas proporcionado explícitamente o una que se haya definido con un valor predeterminado.

En primer lugar, comprueba que el valor de la marca max_connections sea mayor o igual que el del elemento principal.

Si la marca max_connections está configurada correctamente, inspecciona los registros en Cloud Logging para encontrar el error real.

No se ha podido crear la réplica de lectura debido a un error desconocido. Probablemente haya un error más específico en los archivos de registro. Inspecciona los registros en Cloud Logging para encontrar el error real.

Si el error es set Service Networking service account as servicenetworking.serviceAgent role on consumer project, inhabilita y vuelve a habilitar Service Networking API. Esta acción crea la cuenta de servicio necesaria para continuar con el proceso.

El disco está lleno. El disco de la instancia principal puede llenarse durante la creación de la réplica. Edita la instancia principal para actualizarla a un tamaño de disco mayor.
La instancia de réplica está usando demasiada memoria. La réplica usa memoria temporal para almacenar en caché las operaciones de lectura solicitadas con frecuencia, lo que puede hacer que use más memoria que la instancia principal.

Reinicia la instancia de réplica para recuperar el espacio de memoria temporal.

Replicación detenida. Se ha alcanzado el límite máximo de almacenamiento y el aumento automático del almacenamiento no está habilitado.

Edita la instancia para habilitar automatic storage increase.

La latencia de replicación es constantemente alta. La carga de escritura es demasiado alta para que la réplica pueda gestionarla. El retraso de la réplica se produce cuando el subproceso SQL de una réplica no puede seguir el ritmo del subproceso de E/S. Algunos tipos de consultas o cargas de trabajo pueden provocar una latencia de replicación alta temporal o permanente en un esquema determinado. Estas son algunas de las causas habituales del retraso de la réplica:
  • Consultas lentas en la réplica. Identifícalos y corrígelos.
  • Todas las tablas deben tener una clave principal o única. Cada actualización de una tabla de este tipo sin una clave única o principal provoca análisis completos de la tabla en la réplica.
  • Las consultas como DELETE ... WHERE field < 50000000 provocan un retraso en la replicación basada en filas, ya que se acumula un gran número de actualizaciones en la réplica.

Estas son algunas posibles soluciones:

El retraso de la replicación aumenta de repente. Esto se debe a transacciones de larga duración. Cuando se confirma una transacción (una o varias instrucciones) en la instancia de origen, la hora de inicio de la transacción se registra en el registro binario. Cuando la réplica recibe este evento de registro binario, compara esa marca de tiempo con la marca de tiempo actual para calcular el retraso de la replicación. Por lo tanto, una transacción de larga duración en la fuente provocaría un retraso de replicación grande e inmediato en la réplica. Si el número de cambios en las filas de la transacción es elevado, la réplica también tardará mucho en ejecutarla. Durante ese tiempo, la latencia de replicación aumenta. Una vez que la réplica finalice esta transacción, el periodo de puesta al día dependerá de la carga de trabajo de escritura en el origen y de la velocidad de procesamiento de la réplica.

Para evitar que la transacción se prolongue, puedes probar estas soluciones:

  • Dividir la transacción en varias transacciones pequeñas
  • Dividir una consulta de escritura grande en lotes más pequeños
  • Intenta separar las consultas SELECT largas de una transacción mixta con DMLs
Si se cambian las marcas de replicación paralela, se produce un error. Se ha asignado un valor incorrecto a una o varias de estas marcas.

En la instancia principal que muestra el mensaje de error, define las marcas de replicación en paralelo:

  1. Modifica las marcas binlog_transaction_dependency_tracking y transaction_write_set_extraction:
    • binlog_transaction_dependency_tracking=COMMIT_ORDER
    • transaction_write_set_extraction=OFF
  2. Añade la marca slave_pending_jobs_size_max:

    slave_pending_jobs_size_max=33554432

  3. Modifica la marca transaction_write_set_extraction:

    transaction_write_set_extraction=XXHASH64

  4. Modifica la marca binlog_transaction_dependency_tracking:

    binlog_transaction_dependency_tracking=WRITESET

La creación de réplicas falla por tiempo de espera agotado. Las transacciones sin confirmar de larga duración en la instancia principal pueden provocar que falle la creación de réplicas de lectura.

Vuelve a crear la réplica después de detener todas las consultas en ejecución.

Además, en el caso de MySQL, también puedes usar las siguientes opciones:

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