Retraso de replicación

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.
Usa la métrica 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 cuando la réplica no puede aplicar los 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

Hay 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. La limpieza de alto rendimiento reduce la frecuencia con la que se pasan los registros de rehacer al disco 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 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, es posible que la replicación se bloquee. 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 y, luego, identificar si la causa del retraso se encuentra en la base de datos principal, la red o la réplica.

MétricaDescripción
Intervalo de replicación
(cloudsql.googleapis.com/database/replication/replica_lag)

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 Seconds_Behind_Master cuando SHOW SLAVE STATUS se ejecuta en la réplica. Para obtener más información, consulta Verifica el estado de replicación en el manual de referencia de MySQL.

Número de error de la última conversación de E/S
(cloudsql.googleapis.com/database/mysql/replication/last_io_errno)

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 last_io_errno podría indicarte el motivo.

Número de error de la última conversación de SQL
(cloudsql.googleapis.com/database/mysql/replication/last_sql_errno)

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 last_sql_errno puede indicarte el motivo.

Retraso de red
(cloudsql.googleapis.com/database/replication/network_lag)

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 network_lag es cero o es insignificante, pero el replica_lag es alto, indica que el subproceso de SQL no puede aplicar los cambios de replicación lo suficientemente rápido.

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:

CampoDescripción
Master_Log_File
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.