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

MySQL   |  PostgreSQL   |  SQL Server

En esta página, se describe cómo configurar y usar una importación administrada para los datos cuando se replica desde un servidor externo a Cloud SQL.

Debes completar todos los pasos de esta página. Cuando termines, puedes administrar y supervisar la instancia de representación de origen de la misma manera que lo harías con cualquier otra instancia de Cloud SQL.

Antes de comenzar

Antes de comenzar, completa estos pasos:

1. Configura el servidor externo.

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

3. Configura la réplica de Cloud SQL.

Actualiza 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 obligatorios

Hay 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

A continuación, se enumeran los privilegios para cada tipo de combinación de migración y volcado.

Tipo 1

La cuenta de usuario debe tener los siguientes privilegios:

• REPLICATION SLAVE
• EJECUTAR
• SELECCIONAR
• MOSTRAR VISTA
• REPLICATION CLIENT
• VOLVER A CARGAR
• ACTIVADOR
• (Para migrar desde Amazon RDS y Amazon Aurora únicamente) BLOQUEAR TABLAS

Para MySQL 8.0 y versiones posteriores, se recomienda omitir el privilegio BACKUP ADMIN a fin de obtener un rendimiento óptimo.

Nota: Para obtener más información sobre estos privilegios, consulta Privilegios proporcionados por MySQL.

Tipo 2

La cuenta de usuario debe tener los siguientes privilegios:

• REPLICATION SLAVE
• EJECUTAR

Nota: Para obtener más información sobre estos privilegios, consulta los siguientes vínculos:Privilegios proporcionados por MySQL.

Tipo 3

La cuenta de usuario debe tener los siguientes privilegios:

• SELECCIONAR
• MOSTRAR VISTA
• ACTIVADOR
• (Desde migrar desde fuentes con la configuración GTID_MODE = ON únicamente) VOLVER A CARGAR

Para MySQL 8.0 y versiones posteriores, se recomienda omitir el privilegio BACKUP ADMIN a fin de obtener un rendimiento óptimo.

Nota: Para obtener más información sobre estos privilegios, consulta Privilegios proporcionados por MySQL.

Tipo 4

No se requieren privilegios.

Nota: Para obtener más información sobre estos privilegios, consulta Privilegios proporcionados por MySQL.

Actualizar privilegios

Para actualizar los privilegios, abre una terminal en el servidor externo e ingresa 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 saliente de la réplica de Cloud SQL.
OLD_HOST	Es el valor actual asignado a Host que deseas cambiar.
USERNAME	La cuenta de usuario de replicación en el servidor externo.
GCP_USERNAME	El nombre de usuario para la cuenta de usuario.
HOST	El nombre de host de la cuenta de usuario.

Verifica la configuración de la replicación

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

La siguiente configuración de sincronización externa debe ser correcta.

• Conectividad entre la réplica de Cloud SQL y el servidor externo
• Privilegios del usuario de replicación
• Compatibilidad de versiones
• La réplica de Cloud SQL aún no se replica
• Los binlogs están habilitados en el servidor externo
• GTID se habilita si intentas realizar una sincronización externa desde un servidor externo de RDS y usas un bucket de Google Cloud

Para verificar esta configuración, abre una terminal de Cloud Shell y, luego, ingresa 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 muestran una lista de tipo sql#externalSyncSettingErrorList.

Si la lista está vacía, no hay errores. Aparecerá una respuesta sin errores como la siguiente:

  {
    "kind": "sql#externalSyncSettingErrorList"
  }

Propiedad	Descripción
SYNC_MODE	Garantiza que puedas mantener la réplica de Cloud SQL y el servidor externo sincronizados después de que se configure la replicación. Los modos de sincronización incluyen EXTERNAL_SYNC_MODE_UNSPECIFIED, ONLINE y OFFLINE.
SYNC_PARALLEL_LEVEL	Verifica la configuración que controla la velocidad a la que se transfieren los datos de las tablas de una base de datos. Los siguientes valores están disponibles: min: Toma la menor cantidad de recursos de procesamiento en la base de datos. Esta es la velocidad más lenta para transferir datos. optimal: Proporciona un rendimiento equilibrado con una carga óptima en la base de datos. max: Proporciona la mayor velocidad para transferir datos, pero esto podría aumentar la carga en la base de datos. Nota: El valor predeterminado de este parámetro es optimal, ya que esta configuración proporciona una buena velocidad para transferir los datos y tiene un impacto razonable en la base de datos. Te recomendamos usar este valor.
SYNC_FLAGS	Una lista de marcas de sincronización iniciales para verificar. Solo se recomienda si planeas usar marcas de sincronización personalizadas cuando se replica desde la fuente. Para obtener una lista de las marcas permitidas, consulta Marcas de sincronización iniciales.
PROJECT_ID	El ID del proyecto de Google Cloud
REPLICA_INSTANCE_ID	Es el ID de tu réplica de Cloud SQL.

Permiso global de bloqueo de lectura

Si no tienes permiso para acceder al bloqueo global de las operaciones de lectura en el servidor externo, como podría ocurrir con Amazon RDS y Amazon Aurora, pausa las escrituras en tu servidor como se describe en los pasos siguientes:

1. Ve al Explorador de registros y selecciona tu réplica de Cloud SQL de la lista de recursos. Deberías ver una lista de los registros más recientes para tu réplica de Cloud SQL. Omítelos por el momento.
2. Abre una terminal e ingresa los comandos en Iniciar replicación en el servidor externo para replicar desde el servidor externo.

3. Regresa 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, esto solo es necesario 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.
   
   

Inicia la replicación en el servidor externo

Después de verificar que puedes replicar desde el servidor externo, inicia la replicación. La velocidad para realizar la replicación del proceso de importación inicial es de hasta 500 GB por hora. Sin embargo, esta velocidad puede variar según el nivel de máquina, el tamaño del disco de datos, la capacidad de procesamiento de la red y la naturaleza de tu base de datos.

Precaución: Cuando inicias una importación desde una base de datos en un servicio administrado, como Amazon RDS o Amazon Aurora, Cloud SQL te indica que detengas las escrituras por unos segundos para que el volcado de datos sea coherente. Para evitar el tiempo de inactividad de las operaciones de escritura en tu instancia principal de servicio administrado, puedes seleccionar una réplica de lectura como tu fuente de replicación en lugar de la instancia principal. Durante la fase en la que se requiere detener las operaciones de escritura, puedes detener de forma temporal la replicación en la réplica de lectura de origen y, luego, reanudar la replicación una vez que finalice la fase de detención de escrituras.

Durante el proceso de importación inicial, no realices ninguna operación DDL en el servidor externo. De lo contrario, podrían producirse inconsistencias en el archivo de exportación. Una vez que se complete 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 puedas mantener la réplica de Cloud SQL y el servidor externo sincronizados después de que se configure la replicación.
SKIP_VERIFICATION	Indica si se debe omitir el paso de verificación integrado antes de sincronizar tus datos. Este parámetro solo se recomienda si ya verificaste tu configuración de replicación.
SYNC_PARALLEL_LEVEL	Proporciona una configuración que controle la velocidad a la que se transfieren los datos de las tablas de una base de datos. Los siguientes valores están disponibles: min: Toma la menor cantidad de recursos de procesamiento en la base de datos. Esta es la velocidad más lenta para transferir datos. optimal: Proporciona un rendimiento equilibrado con una carga óptima en la base de datos. max: Proporciona la mayor velocidad para transferir datos, pero esto podría aumentar la carga en la base de datos. Nota: El valor predeterminado de este parámetro es optimal, ya que esta configuración proporciona una buena velocidad para transferir los datos y tiene un impacto razonable en la base de datos. Te recomendamos usar este valor.
SYNC_FLAGS	Una lista de marcas de sincronización iniciales para verificar. Solo se recomienda si planeas usar marcas de sincronización personalizadas cuando se replica desde la fuente. Para obtener una lista de las marcas permitidas, consulta Marcas de sincronización iniciales.
PROJECT_ID	El ID del proyecto de Google Cloud
REPLICA_INSTANCE_ID	Es el ID de tu réplica de Cloud SQL.

Marcas de sincronización iniciales

Para migrar con marcas de bases de datos personalizadas, puedes 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 obtener los valores permitidos, consulta la documentación pública de MySQL.

Supervisa la migración

Una vez que inicies la replicación desde el servidor externo, deberás supervisar la replicación. Para obtener más información, consulta Supervisa la réplica. Luego, puedes completar tu migración.

Solucionar problemas

Considera las siguientes opciones de solución de problemas:

Problema	Soluciona problemas
La réplica de lectura no comenzó a replicarse cuando se creó.	Es probable que 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 proporcionaste explícitamente o una que se configuró como un valor predeterminado. Primero, comprueba que el valor de la marca max_connections sea mayor o igual que el valor en el principal. Si la marca max_connections se configuró de forma correcta, inspecciona los registros en Cloud Logging para encontrar el error real.
No se puede crear una réplica de lectura: error desconocido.	Es probable que 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 la Service Networking API. Esta acción crea la cuenta de servicio que se necesita para continuar con el proceso.
El disco está lleno.	El tamaño del disco de la instancia principal puede llenarse durante la creación de una réplica. Edita la instancia principal para actualizarla a un tamaño de disco más grande.
La instancia de réplica usa demasiada memoria.	La réplica usa memoria temporal para almacenar en caché las operaciones de lectura solicitadas con frecuencia, lo que puede ocasionar que use más memoria que la instancia principal. Reinicia la instancia de réplica para recuperar el espacio de memoria temporal.
Se detuvo la replicación.	Se alcanzó el límite de almacenamiento máximo y el aumento de almacenamiento automático no está habilitado. Edita la instancia para habilitar automatic storage increase.
El retraso de replicación se mantiene alto.	La carga de escritura es demasiado alta para que la réplica la maneje. El retraso de la replicación se produce cuando el subproceso de SQL en una réplica no puede mantener el ritmo del subproceso de E/S. Algunos tipos de consultas o cargas de trabajo pueden causar un gran retraso de la replicación de forma temporal o permanente en un esquema determinado. Algunas de las causas típicas del retraso de la replicación son las siguientes: Consultas lentas en la réplica. Encuéntralas y corrígelas. Todas las tablas deben tener una clave primaria o única. Cada actualización en una tabla sin una clave única o primaria genera análisis completos de la tabla en la réplica. Las consultas como DELETE ... WHERE field < 50000000 provocan un retraso de la replicación basado en filas, ya que se acumula una gran cantidad de actualizaciones en la réplica. Estas son algunas de las soluciones posibles: Configura la replicación paralela. Establece la marca innodb_flush_log_at_trx_commit de la réplica de lectura como 2. Consulta Sugerencias para trabajar con marcas si deseas obtener más información sobre esta marca. Edita la instancia para aumentar el tamaño de la réplica. Reduce la carga en la base de datos. Envía tráfico de lectura a la réplica de lectura. Indexa las tablas. Identifica y corrige consultas de escritura lentas. Vuelve a crear la réplica.
El retraso de la replicación aumenta de manera repentina.	Esto se debe a las transacciones de larga duración. Cuando se confirma una transacción (una sola declaración o varias declaraciones) 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 binlog, compara esa marca de tiempo con la marca de tiempo actual para calcular el retraso de replicación. Por lo tanto, una transacción de larga duración en la fuente generaría un gran retraso de replicación inmediato en la réplica. Si la cantidad de cambios de fila en la transacción es grande, la réplica también tardaría mucho tiempo en ejecutarla. Durante ese tiempo, el retraso de la replicación aumenta. Una vez que la réplica finalice esta transacción, el período de actualización dependerá de la carga de trabajo de escritura en el origen y la velocidad de procesamiento de la réplica. Para evitar una transacción larga, algunas soluciones posibles incluyen las siguientes: Divide la transacción en varias transacciones pequeñas Divide una sola consulta de escritura grande en lotes más pequeños Intenta separar las consultas SELECT largas de una transacción mezclada con DML
Si cambias las marcas de replicación paralelas, se generará un error.	Se configuró un valor incorrecto para una o más de estas marcas. En la instancia principal que muestra el mensaje de error, configura las marcas de replicación paralelas: Modifica las marcas binlog_transaction_dependency_tracking y transaction_write_set_extraction: binlog_transaction_dependency_tracking=COMMIT_ORDER transaction_write_set_extraction=OFF Agrega la marca slave_pending_jobs_size_max: slave_pending_jobs_size_max=33554432 Modifica la marca transaction_write_set_extraction: transaction_write_set_extraction=XXHASH64 Modifica la marca binlog_transaction_dependency_tracking: binlog_transaction_dependency_tracking=WRITESET
La creación de la réplica falla con el tiempo de espera.	Las transacciones no confirmadas de larga duración en la instancia principal pueden generar una falla en la creación de la réplica de lectura. Vuelve a crear la réplica después de detener todas las consultas en ejecución.

Además, para MySQL, también considera las siguientes opciones:

Problema	Soluciona problemas
Lost connection to MySQL server during query when dumping table.	Es posible que el origen haya dejado de estar disponible o que el volcado contenga paquetes demasiado grandes. Asegúrate de que la instancia principal externa 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 para estas marcas, consulta Configura marcas de base de datos. Si deseas obtener más información sobre el uso de marcas de mysqldump para la migración de importaciones administradas, consulta Marcas de sincronización iniciales permitidas y predeterminadas.
La migración inicial de los datos se realizó de forma correcta, pero no se están replicando los datos.	Una causa raíz podría ser que la base de datos de origen haya definido marcas de replicación que den como resultado 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 manera conflictiva. Ejecuta el comando show master status en la instancia principal para ver la configuración actual.
La migración inicial de los datos se realizó de forma correcta, pero la réplica de datos dejó de funcionar después de un tiempo.	Solución: Verifica las métricas de réplica para la instancia de réplica en la sección Cloud Monitoring de la consola de Google Cloud. Los errores del subproceso de IO de MySQL o el de SQL se pueden encontrar en Cloud Logging en los archivos mysql.err log. El error también se puede encontrar cuando te conectas a la instancia de réplica. Ejecuta el comando SHOW SLAVE STATUS y verifica 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 de réplica está lleno. Aumenta el tamaño del disco de la instancia de réplica. Puedes aumentar el tamaño del disco de forma manual o habilitar el aumento de almacenamiento automático.

Revisa los registros de replicación

Cuando verificas la configuración de la replicación, se generan registros.

Puedes ver estos registros mediante los siguientes pasos:

1. Ve al Visor de registros en la consola de Google Cloud.

   Ir al visor de registros

2. Selecciona la réplica de Cloud SQL del 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, confirma lo siguiente:

• Cualquier firewall en el servidor externo se configura para permitir conexiones desde la dirección IP saliente de la réplica de Cloud SQL.
• Tu configuración de SSL/TLS es correcta.
• Tu usuario de repetición, host y contraseña son correctos.

¿Qué sigue?

• Obtén más información sobre cómo actualizar una instancia.
• Aprende cómo administrar réplicas.
• Obtén información sobre la supervisión de instancias.
• Obtén más información para ascender la réplica de Cloud SQL.