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 de transmisión de PostgreSQL. Los cambios se escriben en el registro de escritura anticipada (WAL) en la instancia principal. El emisor de WAL envía el WAL al receptor de WAL en la réplica, donde se aplica.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.
network_lag
.
El tercero se observa a través de la métrica replica_lag
. Si replica_lag
es alto, significa que la réplica no puede aplicar cambios de replicación lo suficientemente rápido. El retraso total se puede observar a través de la métrica replica_byte_lag
, que tiene etiquetas para indicar más detalles. 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.
Considera ajustar las marcas max_standby_archive_delay
y max_standby_streaming_delay
de tu réplica.
Si sospechas que VACUUM es la causa y la cancelación de la consulta no es aceptable, considera establecer la marca hot_standby_feedback
en la réplica.
Consulta la documentación de PostgreSQL con espera activa para obtener más información.
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.
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 ) |
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 se calcula con |
Bytes de retraso ( cloudsql.googleapis.com ) |
La cantidad de bytes que el estado de la réplica está por atrás respecto del estado de la base de datos principal.
|
Retraso de red ( cloudsql.googleapis.com ) |
La cantidad de tiempo en segundos que se tarda desde que se confirma en la base de datos principal hasta que se alcanza el receptor WAL en la réplica. Si |
Verifica la replicación
Para verificar que la replicación funcione, ejecuta la siguiente instrucción en la réplica:select status, last_msg_receipt_time from pg_stat_wal_receiver;
Si la replicación está en curso, verás el estado streaming
y un last_msg_receipt_time reciente:
postgres=> select status, last_msg_receipt_time from pg_stat_wal_receiver;
status | last_msg_receipt_time
-----------+-------------------------------
streaming | 2020-01-21 20:19:51.461535+00
(1 row)
Si no se está realizando la replicación, se muestra un resultado vacío:
postgres=> select status, last_msg_receipt_time from pg_stat_wal_receiver;
status | last_msg_receipt_time
--------+-----------------------
(0 rows)