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. Para obtener más información sobre la métrica, consulta el artículo Monitorizar el retraso de la replicación.
Asegurarse de que la réplica se ha aprovisionado correctamente
Una instancia de réplica que sea más pequeña que la instancia principal (por ejemplo, con menos vCPUs y memoria) puede experimentar un retraso en la replicación. Una réplica más pequeña también puede tener marcas de configuración predeterminadas diferentes en comparación con una instancia principal más grande. Te recomendamos que la instancia de réplica sea al menos tan grande como la instancia principal para que tenga suficientes recursos para gestionar la carga de replicación.
Un uso elevado de la CPU en la réplica también puede provocar un retraso en la replicación. Si el uso de CPU de la réplica es alto (por ejemplo, superior al 90%), considera la posibilidad de aumentar la capacidad de CPU de 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.
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 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 el elemento 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.