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 retraso 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 cambios de replicación lo suficientemente rápido.
Estas métricas se describen en la sección Supervisa el retraso de replicación a continuación.
Una configuración de réplica más rápida
Tenemos dos maneras de hacer que una réplica de MySQL aplique 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. La limpieza de alto rendimiento reduce la frecuencia con la que los registros de rehacer se vacían al 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 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 Slave_IO_State (primera columna) 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 |
Es el nombre del archivo de registro binario de origen del 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.