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
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 las instancias de réplica secundarias, donde se aplican los cambios. El modo de disponibilidad utilizado es Asynchronous-commit mode.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.
network_lag
metric. El tercer motivo 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 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 que aparece más abajo.
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.
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. Puede que quieras tener réplicas independientes para el procesamiento de transacciones online (OLTP) y el procesamiento analítico online (OLAP), y enviar solo las 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 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.
CREATE INDEX, ALTER INDEX y INDEX
MAINTENANCE, pueden provocar un retraso en la replicación debido al gran número de registros de registro de transacciones que pueden generar estas instrucciones.
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.
| Métrica | Descripción |
|---|---|
| Retraso de la replicación ( cloudsql.googleapis.com/database/replication/seconds_behind_master) |
Número de segundos que el estado de la réplica está por detrás del estado de la instancia principal. Es la diferencia entre la marca de tiempo del último registro de registro rehecho en la secundaria y la marca de tiempo del último registro de registro enviado en la principal. |
| Retraso de la red ( cloudsql.googleapis.com) |
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 principal. |
Verificar la replicación
Para verificar que la replicación funciona, compruebe el valor de la métricacloudsql.googleapis.com/database/replication/state en la instancia principal. Si el estado es Running, la replicación está en buen estado.