En esta página, se describe cómo solucionar problemas y arreglar el retraso de replicación de las réplicas de lectura de Cloud SQL.
Descripción general
Las réplicas de lectura de Cloud SQL usan la replicación basada en filas de MySQL a través de identificadores de transacciones globales (GTID). Los cambios se escriben en el registro binario de la instancia principal y se envían a la réplica, en la que se reciben y, luego, se aplican a la base de datos.El retraso de la replicación puede ocurrir en algunas situaciones, como las siguientes:
- La instancia principal no puede enviar los cambios lo suficientemente rápido a la réplica.
- La réplica no puede recibir los cambios lo suficientemente rápido.
- La réplica no puede aplicar los cambios lo suficientemente rápido.
network_lag para supervisar las dos primeras situaciones en las que la instancia principal no puede enviar cambios lo suficientemente rápido o la réplica no puede recibir cambios lo suficientemente rápido.
El rezago total se observa con la métrica replica_lag.
La diferencia entre replica_lag y network_lag puede indicar el tercer motivo por el que la réplica no puede aplicar los cambios de replicación lo suficientemente rápido.
Estas métricas se describen en la sección Cómo supervisar el retraso de replicación que aparece a continuación.
Una configuración de réplica más rápida
Tenemos dos formas de hacer que una réplica de MySQL aplique los cambios más rápido. Los usuarios pueden configurar sus réplicas con las siguientes opciones:
- Replicación paralela
- Limpieza de alto rendimiento
Replicación paralela
La replicación paralela puede ayudar evitar el retraso de la replicación a través de la configuración de la réplica para que use varios subprocesos que actúan en paralelo para aplicar cambios en la réplica. Para obtener más información sobre el uso de la replicación paralela, consulta Configura la replicación paralela.
Limpieza de alto rendimiento
De forma predeterminada, Cloud SQL para MySQL limpia los registros de rehacer en el disco después de cada transacción. El vaciado de alto rendimiento reduce la frecuencia con la que los registros de rehacer se vacían en el disco a una vez por segundo, lo que mejora el rendimiento de escritura.
Establece la marca innodb_flush_log_at_trx_commit en la réplica de lectura como 2. También debes establecer la marca sync_binlog en un valor superior para que la marca innodb_flush_log_at_trx_commit sea efectiva.
Consulta Sugerencias para trabajar con marcas si deseas obtener más información sobre esta marca.
Cuando la marca innodb_flush_log_at_trx_commit se configura en la réplica de lectura y Cloud SQL detecta que puede ocurrir una falla, Cloud SQL vuelve a crear la réplica de forma automática.
Optimiza las consultas y el esquema
En esta sección, se sugieren algunas optimizaciones comunes de consultas y esquemas que puedes realizar para mejorar el rendimiento de la replicación.
Nivel de aislamiento de consultas en la réplica de lectura
Los niveles de aislamiento de transacción REPEATABLE READ y SERIALIZABLE adquieren bloqueos que podrían bloquear los cambios de replicación. Considera reducir el nivel de aislamiento para tus consultas en la réplica. El nivel de aislamiento de transacción READ COMMITTED puede funcionar mejor.
Transacciones de larga duración en la base de datos principal
Si se actualiza una gran cantidad de filas en una sola transacción, se puede generar un aumento repentino en el número de cambios que se deben aplicar a la instancia principal y, luego, enviarse a la réplica. Esto se aplica a las actualizaciones o eliminaciones de una sola declaración que afectan a muchas filas a la vez. Los cambios se envían a la réplica después de que se confirman. La aplicación de un aumento repentino de los cambios en la réplica puede aumentar la posibilidad de contención de bloqueo en la réplica si la carga de consulta en la réplica también es alta, lo que genera un retraso de replicación.
Considera dividir las transacciones grandes en varias transacciones más pequeñas.
Faltan claves primarias
Las réplicas de lectura de Cloud SQL usan la replicación basada en filas, que tiene un bajo rendimiento si las tablas de MySQL que se replican no tienen claves primarias. Recomendamos que todas las tablas replicadas tengan claves primarias.
Para MySQL 8 o versiones posteriores, te recomendamos que configures la marca sql_require_primary_key como ON para exigir que las tablas de tu base de datos tengan claves primarias.
Bloqueos exclusivos debido a DDL
Los comandos del lenguaje de definición de datos (DDL), como ALTER TABLE y CREATE INDEX, pueden causar un retraso de la replicación en la réplica debido a bloqueos exclusivos. Para evitar la contención de bloqueo, considera programar la ejecución de DDL durante los momentos en que la carga de consulta sea más baja en las réplicas.
Réplica sobrecargada
Si una réplica de lectura recibe demasiadas consultas, la replicación podría bloquearse. Considera dividir las lecturas entre varias réplicas para reducir la carga en cada una.
Para evitar aumentos repentinos de consultas, limita las consultas de lectura de la réplica en la lógica de tu aplicación o en una capa de proxy si usas una.
Si hay aumentos repentinos de actividad en la instancia principal, considera distribuir las actualizaciones.
Base de datos principal monolítica
Considera fragmentar la base de datos principal de forma vertical (o horizontal) para evitar que una o más tablas atrasadas detengan el resto de las tablas.
Supervisa el retraso de replicación
Puedes usar las métricas replica_lag y network_lag para supervisar el retraso de replicación e identificar si la causa del retraso se encuentra en la base de datos principal, la red o la réplica.
| Métrica | Descripción |
|---|---|
| Intervalo de replicación ( cloudsql.googleapis.com) |
La cantidad de segundos de estado de la réplica que se retrasa con respecto al estado de la instancia principal. Esta es la diferencia entre la hora actual y la marca de tiempo original en la que la base de datos principal confirmó la transacción que se está aplicando en la réplica. En particular, es posible que las escrituras se cuenten con retraso, incluso si la réplica las recibió, si aún no aplicó la escritura a la base de datos. Esta métrica informa el valor de |
| Número de error de la última conversación de E/S ( cloudsql.googleapis.com) |
Indica el último error que causó que el subproceso de E/S falle. Si no es cero, la replicación se rompe. Esto es poco frecuente, pero puede ocurrir. Consulta la documentación de MySQL para comprender lo que indica el código de error. Por ejemplo, es posible que los archivos binlog de la instancia principal se hayan borrado antes de que la reciba la reciba la réplica.
Por lo general, Cloud SQL vuelve a crear la réplica de forma automática si la replicación está interrumpida.
Esta métrica |
| Número de error de la última conversación de SQL ( cloudsql.googleapis.com) |
Indica el último error que causó que el subproceso de SQL falle. Si no es cero, la replicación se rompe. Esto es poco frecuente, pero puede ocurrir. Consulta la documentación de MySQL para comprender lo que indica el código de error.
Por lo general, Cloud SQL volverá a crear la réplica de forma automática si la replicación está interrumpida.
Esta métrica |
| Retraso de red ( cloudsql.googleapis.com) |
La cantidad de tiempo, en segundos, que lleva escribir el binlog en la base de datos principal para alcanzar el subproceso de E/S en la réplica. Si |
Verifica la replicación
Para verificar que la replicación funcione, ejecuta la siguiente instrucción en la réplica:
mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
Slave_IO_State: Queueing master event to the relay log
Master_Host: xx.xxx.xxx.xxx
Master_User: cloudsqlreplica
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.199927
Read_Master_Log_Pos: 83711956
Relay_Log_File: relay-log.000025
Relay_Log_Pos: 24214376
Relay_Master_Log_File: mysql-bin.199898
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:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 24214163
Relay_Log_Space: 3128686571
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: Yes
Master_SSL_CA_File: master_server_ca.pem
Master_SSL_CA_Path: /mysql/datadir
Master_SSL_Cert: replica_cert.pem
Master_SSL_Cipher:
Master_SSL_Key: replica_pkey.pem
Seconds_Behind_Master: 2627
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: 321071839
Master_UUID: 437d04e9-8456-11e8-b13d-42010a80027b
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: System lock
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 437d04e9-8456-11e8-b13d-42010a80027b:52111095710-52120776390
Executed_Gtid_Set: 437d04e9-8456-11e8-b13d-42010a80027b:1-52113039508
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
Si se produce una replicación, la primera columna, Slave_IO_State, muestra Waiting
for master to send event o un mensaje similar. Además, el campo Last_IO_Error está vacío.
Si no ocurre una replicación, la columna Slave_IO_State muestra el estado Connecting to master y la columna Last_IO_Error muestra el estado error connecting to master cloudsqlreplica@x.x.x.x:3306.
Según la documentación de MySQL, algunos otros campos interesantes relacionados con el retraso de replicación son los siguientes:
| Campo | Descripción |
|---|---|
Master_Log_File |
Nombre del archivo de registro binario de origen desde el que lee el subproceso de E/S. |
Read_Master_Log_Pos |
La posición en el archivo de registro binario de origen actual que ha leído el subproceso de E/S. |
Relay_Log_File |
El nombre del archivo de registro de retransmisión desde el que lee y ejecuta el subproceso de SQL. |
Relay_Log_Pos |
La posición en el archivo de registro de retransmisión actual que leyó y ejecutó hasta el subproceso de SQL. |
Relay_Master_Log_File |
El nombre del archivo de registro binario de origen que contiene el evento más reciente que ejecutó el subproceso de SQL. |
En el ejemplo anterior, Relay_Master_Log_File tiene el valor mysql-bin.199898.
Master_Log_File tiene el valor mysql-bin.199927. El sufijo numérico 199898 es menor que 199927. Esto significa que, aunque la réplica recibió un archivo de registro mysql-bin.199927 más reciente, aún aplica el mysql-bin.199898 anterior.
En este caso, el subproceso de SQL se retrasa en la réplica.
También puedes conectarte a la base de datos principal y ejecutar lo siguiente:
SHOW MASTER STATUS;
Este comando te muestra qué archivo binlog se escribe en la base de datos principal.
Si el archivo de registro binario de la base de datos principal es más reciente que el Master_Log_File en la réplica, significa que el subproceso de E/S se retrasa. La réplica aún lee un archivo de registro binario más antiguo de la base de datos principal.
Cuando el subproceso de E/S se retrasa, la métrica network_lag también es alta. Cuando el subproceso de SQL se retrasa, pero el subproceso de E/S no, la métrica network_lag no es tan alta, pero replica_lag es alto.
Los comandos anteriores te permiten observar los detalles del retraso mientras se produce el retraso, pero las métricas network_lag y replica_lag te proporcionan una forma de ver los casos anteriores del retraso.
Cómo volver a crear una réplica rezagada
Vuelve a crear una réplica rezagada cuando la replicación se retrasa por un período de tiempo aceptable.
Con Cloud SQL, puedes configurar tu réplica de lectura para que se vuelva a crear si la replicación se retrasa (o se demora) más allá de un período aceptable, y esa demora persiste durante al menos cinco minutos.
Si defines un retraso de replicación aceptable como inferior a 360 segundos (seis minutos) y persiste un retraso de replicación de al menos 361 segundos durante más de cinco minutos, después de ese tiempo, la instancia principal crea una nueva instantánea de sí misma y la réplica de lectura se vuelve a crear con esta instantánea.
Volver a crear una réplica de lectura rezagada proporciona los siguientes beneficios:
- Tú controlas lo que se considera un rango aceptable para la demora de replicación.
- Puedes reducir en horas o incluso días el tiempo que dedicas a solucionar problemas relacionados con el retraso de la replicación.
Se aplican detalles adicionales de las funciones:
- Es compatible con las siguientes versiones:
- MySQL 5.7
- MySQL 8.0
- MySQL 8.4
- Se debe definir un rango aceptable para el retraso de la replicación en segundos.
- El valor aceptable mínimo es 300 segundos o cinco minutos.
- El valor máximo aceptable es de 31,536,000 segundos o un año.
- Si habilitas la opción para volver a crear la réplica rezagada para una instancia, pero no estableces el retraso de replicación máximo aceptable, Cloud SQL usará el valor predeterminado de un año.
- Tipos de instancias admitidos:
- Réplica de lectura
- Réplica de lectura entre regiones
- Réplica en cascada
- El valor establecido para el campo
replicationLagMaxSecondses específico para cada instancia de réplica. Si una instancia principal tiene varias instancias de réplica, puedes establecer cada réplica con un valor diferente. - Cuando se vuelve a crear una réplica, los usuarios pueden esperar un tiempo de inactividad mientras se completan las siguientes operaciones:
- Se detuvo la replicación.
- Se borró la réplica.
- Se crea una instantánea de la instancia principal.
- La réplica se vuelve a crear a partir de esta última instantánea. La réplica nueva usa el mismo nombre y la misma dirección IP que la réplica anterior. Como resultado, MySQL debe detenerse y reiniciarse.
- La réplica nueva comienza a replicar datos.
replicationLagMaxSecondses un campo a nivel de la instancia. Cada instancia tiene su propio valor.Si tienes varias réplicas de lectura para la misma instancia principal, puedes establecer un valor único para el campo
replicationLagMaxSecondsde cada réplica.Definir diferentes umbrales de tiempo para diferentes réplicas puede ayudarte a evitar una situación en la que todas las réplicas se detengan al mismo tiempo.
Habilita la opción para recrear la réplica rezagada
La función para volver a crear la réplica rezagada está inhabilitada de forma predeterminada. Para habilitarlo cuando crees una instancia, usa uno de los siguientes métodos:
gcloud
Usa el comando gcloud sql instances create para crear una instancia de réplica de lectura nueva con la marca
--replication-lag-max-seconds-for-recreate:
gcloud beta sql instances create REPLICA_INSTANCE_NAME \ --master-instance-name=PRIMARY_INSTANCE_NAME \ --database-version=DATABASE_VERSION \ --tier=TIER \ --edition=EDITION \ --region=REGION \ --root-password=PASSWORD \ --replication-lag-max-seconds-for-recreate=REPLICATION_LAG_MAX_SECONDS
Aquí:
REPLICA_INSTANCE_NAMEes el nombre de la instancia de réplica.PRIMARY_INSTANCE_NAMEes el nombre de la instancia principal.DATABASE_VERSIONes la versión de la base de datos de la instancia. Por ejemplo,MYSQL_8_0_31TIERes el tipo de máquina que quieres usar para la instancia de réplica. Por ejemplo,db-perf-optimized-N-4Para obtener más información, consulta Configuración de instancias personalizadas.EDITIONes la edición que deseas usar para la instancia de réplica. Por ejemplo,ENTERPRISE_PLUSPara obtener más información, consulta Crea una instancia.REGIONes la región que deseas usar para la instancia de réplica. Por ejemplo,us-central1PASSWORDes la contraseña raíz de la instancia.REPLICATION_LAG_MAX_SECONDSes el rezago o retraso de replicación máximo aceptable en segundos. Por ejemplo,600El valor aceptable mínimo es 300 segundos o cinco minutos. El valor máximo aceptable es de 31,536,000 segundos o un año.
API de REST
El campo replicationLagMaxSeconds se encuentra en el recurso DatabaseInstance. Agrega este campo al cuerpo de la solicitud:
{ "settings": { "replicationLagMaxSeconds" :REPLICATION_LAG_MAX_SECONDS, } ... }
Aquí:
REPLICATION_LAG_MAX_SECONDSes el rezago o retraso de replicación máximo aceptable en segundos. Por ejemplo,600
Actualiza el período de recreación del retraso de replicación
Para ver la configuración de una instancia, usa cualquiera de los métodos que se describen en Cómo ver la información resumida de una instancia.
Con esta información, puedes elegir si deseas actualizar el período de rezago de replicación que especificaste como aceptable antes de que se vuelva a crear la réplica.
gcloud
Usa el comando gcloud sql instances patch para actualizar el período durante el que se puede volver a crear la instancia en función del retraso de la replicación:
gcloud beta sql instances patch INSTANCE_NAME \ --replication-lag-max-seconds-for-recreate=REPLICATION_LAG_MAX_SECONDS
Aquí:
INSTANCE_NAMEes el nombre de la instancia.REPLICATION_LAG_MAX_SECONDSes el rezago o retraso de replicación máximo aceptable en segundos. Por ejemplo,700Si deseas volver al valor predeterminado de un año, ingresa31536000. El valor aceptable mínimo es 300 segundos o cinco minutos. El valor máximo aceptable es de 31,536,000 segundos o un año.
API de REST
La política se puede actualizar con instances.patch y instance.insert.
Para ver un ejemplo de cómo actualizar el parámetro de configuración con la API de REST, consulta Edita una instancia.
Limitaciones
Se aplican las siguientes limitaciones a la recreación de réplicas rezagadas:
- Los valores de
replicationLagMaxSecondssolo se pueden establecer en segundos. - No se conservarán los índices creados en la réplica de lectura antes de una operación de recreación. Si existe un índice, crea un índice secundario después de que se vuelva a crear la réplica.
- Para evitar tiempos de inactividad frecuentes en las réplicas de lectura, las recreaciones se limitan a una por día y por instancia.
- Las réplicas de servidores externos no son compatibles con esta función.
- Si habilitas la recreación de réplicas rezagadas en una réplica en cascada, Cloud SQL recreará primero las réplicas hoja para mantener la coherencia de la replicación.
- La recreación de una réplica entre regiones genera un costo adicional.
- No puedes habilitar la recreación de réplicas rezagadas en la consola de Google Cloud .