Retraso de replicación

En esta página se describe cómo solucionar problemas de latencia de replicación en réplicas de lectura de Cloud SQL.

Información general

La latencia de replicación puede producirse en varios casos, como los siguientes:

• La instancia principal no puede enviar los cambios a la réplica con la suficiente rapidez.
• La réplica no puede recibir los cambios con la suficiente rapidez.
• La réplica no puede aplicar los cambios con la suficiente rapidez.

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 los cambios de replicación con la suficiente rapidez. Estas métricas se describen en la sección Monitorizar el retraso de la réplica de abajo.

Configuración de réplicas 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
• Descarga de alto rendimiento

Replicación paralela

La replicación en paralelo puede ayudar a reducir el retraso de la replicación configurando la réplica para que use varios subprocesos que actúen en paralelo para aplicar los cambios en la réplica. Para obtener información sobre cómo usar la replicación en paralelo, consulta Configurar la replicación en paralelo.

Vaciado de alto rendimiento

De forma predeterminada, Cloud SQL para MySQL vacía 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.

Define la marca innodb_flush_log_at_trx_commit en la réplica de lectura como 2. También debe asignar un valor más alto a la marca sync_binlog para que la marca innodb_flush_log_at_trx_commit sea efectiva.

Consulta Consejos para trabajar con marcas para obtener más información sobre esta marca.

Si la marca innodb_flush_log_at_trx_commit está definida en la réplica de lectura y Cloud SQL detecta que puede haberse producido un fallo, Cloud SQL recrea automáticamente la réplica.

Optimizar consultas y esquemas

En esta sección se sugieren algunas optimizaciones habituales de consultas y esquemas que puedes hacer para mejorar el rendimiento de la replicación.

Nivel de aislamiento de consultas en la réplica de lectura

Los niveles de aislamiento de transacciones REPEATABLE READ y SERIALIZABLE adquieren bloqueos que pueden bloquear los cambios de replicación. Puedes reducir el nivel de aislamiento de las consultas en la réplica. El nivel de aislamiento de transacciones READ COMMITTED puede ofrecer un mejor rendimiento.

Transacciones de larga duración en la base de datos principal

Si se actualiza un gran número de filas en una sola transacción, puede producirse un aumento repentino en el número de cambios que deben aplicarse a la instancia principal y, a continuación, enviarse a la réplica. Esto se aplica a las actualizaciones o eliminaciones de una sola instrucción que afectan a muchas filas a la vez. Los cambios se envían a la réplica después de confirmarse. Si se aplica un aumento repentino de los cambios en la réplica, puede aumentar la posibilidad de que se produzca una contención de bloqueos en la réplica si la carga de consultas en la réplica también es alta, lo que provoca un retraso en la replicación.

Considera la posibilidad de dividir las transacciones grandes en varias más pequeñas.

Faltan claves principales

Las réplicas de lectura de Cloud SQL utilizan la replicación basada en filas, que no funciona bien si las tablas de MySQL que se replican no tienen claves principales. Recomendamos que todas las tablas replicadas tengan claves principales.

En MySQL 8 o versiones posteriores, le recomendamos que defina la marca sql_require_primary_key como ON para que las tablas de su base de datos tengan claves principales.

Bloqueos exclusivos debido a DDL

Los comandos del lenguaje de definición de datos (DDL), como ALTER TABLE y CREATE INDEX, pueden provocar un retraso en la réplica debido a los bloqueos exclusivos. Para evitar conflictos de bloqueo, programa la ejecución de DDL en momentos en los que la carga de consultas en las réplicas sea menor.

Réplica sobrecargada

Si una réplica de lectura recibe demasiadas consultas, la replicación podría bloquearse. Te recomendamos que dividas las lecturas entre varias réplicas para reducir la carga de cada una.

Para evitar picos en las consultas, considera la posibilidad de limitar las consultas de lectura de réplicas en la lógica de tu aplicación o en una capa de proxy, si utilizas una.

Si hay picos de actividad en la instancia principal, considera la posibilidad de espaciar las actualizaciones.

Base de datos principal monolítica

Considera la posibilidad de fragmentar la base de datos principal verticalmente (u horizontalmente) para evitar que una o varias tablas con retraso impidan el funcionamiento del resto de las tablas.

Monitorizar el retraso de la replicación

Puedes usar las métricas replica_lag y network_lag para monitorizar la latencia de replicación e identificar si la causa de la latencia está en la base de datos principal, en la red o en la réplica.

Verificar la replicación

Para verificar que la replicación funciona, 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 está produciendo la replicación, en la primera columna, Slave_IO_State, se muestra Waiting for master to send event o un mensaje similar. Además, el campo Last_IO_Error está vacío.

Si no se está produciendo la replicación, en la columna Slave_IO_State se muestra el estado Connecting to master y en la columna Last_IO_Error se muestra el estado error connecting to master cloudsqlreplica@x.x.x.x:3306.

Según la documentación de MySQL, hay otros campos interesantes relacionados con la latencia de replicación, como los siguientes:

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 inferior a 199927. Esto significa que, aunque la réplica haya recibido un archivo de registro mysql-bin.199927 más reciente, sigue aplicando el mysql-bin.199898 anterior.

En este caso, el subproceso SQL está retrasado en la réplica.

También puedes conectarte a la base de datos principal y ejecutar lo siguiente:

  SHOW MASTER STATUS;

Este comando muestra en qué archivo binlog se está escribiendo 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 de la réplica, significa que el subproceso de E/S está retrasado. La réplica sigue leyendo un archivo de registro binario 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 SQL se retrasa, pero el subproceso de E/S no, la métrica network_lag no es tan alta, pero la métrica replica_lag sí lo es.

Los comandos anteriores te permiten observar los detalles del retraso mientras se produce, pero las métricas network_lag y replica_lag te ofrecen una forma de consultar las incidencias anteriores del retraso.

Recrear réplica con retraso

Recrea una réplica con retraso cuando la replicación se retrase un periodo 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 más de un periodo de tiempo aceptable y ese retraso persiste durante al menos cinco minutos.

Si defines un retraso de replicación aceptable de menos de 360 segundos (seis minutos) y se produce un retraso de replicación de al menos 361 segundos durante más de cinco minutos, al cabo de cinco minutos, 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.

Recrear una réplica de lectura con retraso ofrece las siguientes ventajas:

• Tú controlas lo que se considera un intervalo aceptable para la latencia de replicación.
• Puedes reducir el tiempo dedicado a solucionar problemas de retraso de la replicación en horas o incluso días.

Se aplican detalles adicionales sobre las funciones:

• Compatible con las siguientes versiones:
  • MySQL 5.7
  • MySQL 8.0
  • MySQL 8.4
• Se debe definir un intervalo aceptable para el retraso de la replicación en segundos.
• El valor mínimo aceptable es de 300 segundos o cinco minutos.
• El valor máximo aceptable es de 31.536.000 segundos o un año.
  • Si habilita la opción para recrear réplicas con retraso en una instancia, pero no define 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 asignado al campo replicationLagMaxSeconds es específico de cada instancia de réplica. Si una instancia principal tiene varias instancias de réplica, puede asignar un valor diferente a cada réplica.
• Cuando se recrea una réplica, los usuarios pueden experimentar un tiempo de inactividad mientras se completan las siguientes operaciones:
  • La replicación se ha detenido.
  • La réplica se elimina.
  • Se crea una captura de la instancia principal.
  • La réplica se vuelve a crear a partir de esta última instantánea. La nueva réplica usa el mismo nombre y la misma dirección IP que la réplica anterior. Como resultado, MySQL debe detenerse y reiniciarse.
  • La nueva réplica empieza a replicar datos.
• El campo replicationLagMaxSeconds es un campo a nivel de instancia. Cada instancia tiene su propio valor.

• Si tienes varias réplicas de lectura para la misma instancia principal, puedes definir un valor único para el campo replicationLagMaxSeconds de cada réplica.

  Definir umbrales de tiempo diferentes para distintas réplicas puede ayudarte a evitar que todas las réplicas fallen al mismo tiempo.

Habilitar la recreación de la réplica con retraso

La función de recreación de réplicas con retraso está inhabilitada de forma predeterminada. Para habilitarlo al crear una instancia, utiliza uno de los siguientes métodos:

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

{
  "settings": {
  "replicationLagMaxSeconds" :REPLICATION_LAG_MAX_SECONDS,
  }
  ...
}

Actualizar el periodo de recreación de la latencia de replicación

Para ver los ajustes de una instancia, usa cualquiera de los métodos descritos en Ver información de resumen de una instancia.

Con esta información, puedes elegir si quieres actualizar el periodo de desfase de la réplica que has especificado como aceptable antes de que se vuelva a crear la réplica.

gcloud beta sql instances patch INSTANCE_NAME \
  --replication-lag-max-seconds-for-recreate=REPLICATION_LAG_MAX_SECONDS

Limitaciones

Se aplican las siguientes limitaciones a la recreación de réplicas con retraso:

• Los valores de replicationLagMaxSeconds solo se pueden definir en segundos.
• Los índices creados en la réplica de lectura antes de una operación de recreación no se conservarán. Si existe un índice, crea un índice secundario después de recrear 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.
• Esta función no admite réplicas de servidores externos.
• Si habilitas la recreación de réplicas con retraso en una réplica en cascada, Cloud SQL recreará primero las réplicas hoja para mantener la coherencia de la replicación.
• Volver a crear una réplica entre regiones conlleva un coste adicional.
• No puedes habilitar la recreación de réplicas con retraso en la consola de Google Cloud .

Siguientes pasos

• Promocionar réplicas para la migración regional o la recuperación tras fallos