Intervalo de replicación

MySQL   |  PostgreSQL   |  SQL Server

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 grupos de disponibilidad Always On de SQL Server para la replicación. Los cambios se escriben en el registro de transacciones de la instancia principal. La instancia principal reenvía las transacciones a cualquier instancia de réplica secundaria, en la que se aplican los cambios. El modo de disponibilidad usado es el modo de confirmación asíncrona.

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.

Los dos primeros motivos anteriores se pueden supervisar con la network_lag metric. El tercero se observa a través de la métrica seconds_behind_master. Una métrica seconds_behind_master alta significa que la réplica no puede aplicar 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.

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.

Consultas de larga duración en la réplica de lectura

Las consultas de larga duración en la réplica pueden bloquear la replicación de Cloud SQL. Es recomendable que tengas réplicas separadas para el procesamiento de transacciones en línea (OLTP) y el procesamiento analítico en línea (OLAP) y solo envíes consultas de larga duración a la réplica de OLAP.

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.

Además, las sentencias DDL, como CREATE INDEX, ALTER INDEX y INDEX MAINTENANCE, pueden causar un retraso en la replicación debido a la gran cantidad de registros de transacciones que pueden generar estas sentencias.

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/database/replication/seconds_behind_master)	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 marca de tiempo del último registro de registro rehecho en el secundario y la marca de tiempo del último registro de registro enviado en el principal.
Retraso de red (cloudsql.googleapis.com/database/replication/network_lag)	Es la diferencia entre la marca de tiempo de la última entrada de registro recibida en la réplica y la última entrada de registro enviada en la instancia principal.

Comprueba la replicación

Para comprobar que la replicación funcione, comprueba el valor de la métrica cloudsql.googleapis.com/database/replication/state en la instancia principal. Si el estado es Running, la replicación está en buen estado.