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:
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.
Tipo 2
La cuenta de usuario debe tener los siguientes privilegios:
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.
Tipo 4
No se requieren privilegios.
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:
Nota: El valor predeterminado de este parámetro es |
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:
- 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.
- Abre una terminal e ingresa los comandos en Iniciar replicación en el servidor externo para replicar desde el servidor externo.
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.
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.
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:
Nota: El valor predeterminado de este parámetro es |
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 Si la marca |
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 |
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 |
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:
Estas son algunas de las soluciones posibles:
|
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:
|
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:
|
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 |
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 Ejecuta el comando |
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:
|
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:
Ve al Visor de registros en la consola de Google Cloud.
- Selecciona la réplica de Cloud SQL del menú desplegable Instancia.
- 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.