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

Las réplicas de lectura de Cloud SQL usan la replicación de streaming de PostgreSQL. Los cambios se escriben en el registro Write-Ahead Log (WAL) de la instancia principal. El remitente de WAL envía el WAL al receptor de WAL de la réplica, donde se aplican.

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.
Los dos primeros motivos anteriores se pueden monitorizar con la métrica network_lag. La tercera se observa a través de la métrica replica_lag. Un valor alto de replica_lag significa que la réplica no puede aplicar los cambios de replicación con la suficiente rapidez. La latencia total se puede observar mediante la métrica replica_byte_lag, que tiene etiquetas para indicar más detalles. 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.

Plantéate ajustar las marcas max_standby_archive_delay y max_standby_streaming_delay de tu réplica.

Si sospechas que el problema es VACUUM y no puedes cancelar la consulta, considera la posibilidad de definir la marca hot_standby_feedback en la réplica.

Consulta la documentación de PostgreSQL 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 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.

Consulta la documentación de PostgreSQL para obtener más información.

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étricaDescripción
Retraso de la replicación
(cloudsql.googleapis.com/database/replication/replica_lag)

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 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 concreto, las escrituras pueden considerarse retrasadas aunque la réplica las haya recibido, si aún no las ha aplicado a la base de datos.

Esta métrica se calcula mediante now() - pg_last_xact_replay_timestamp() en la réplica. Se trata de una aproximación. Si la réplica se interrumpe, la réplica no sabrá cuánto tiempo lleva de ventaja la base de datos principal y esta métrica no indicará la latencia total.
Bytes de retraso
(cloudsql.googleapis.com/database/postgres/replication/replica_byte_lag)

La cantidad de bytes por la que el estado de la réplica está por detrás del estado de la base de datos principal. replica_byte_lag exports 4 time series, and the replica_lag_type label can indicate any of the following:

  • sent_location: indica cuántos bytes de WAL se han generado, pero aún no se han enviado a la réplica.
  • write_location: la latencia de envío de escritura muestra los bytes de WAL de la red que se han enviado, pero que aún no se han escrito en la réplica.
  • flush_location: la latencia de escritura de la purga muestra los bytes de WAL escritos en la réplica, pero aún no purgados en ella.
  • replay_location: muestra el desfase total en bytes. La diferencia entre la repetición y el retraso de vaciado indica el retraso de la repetición.
Retraso de la red
(cloudsql.googleapis.com/database/replication/network_lag)

Tiempo, en segundos, que transcurre desde que se confirma en la base de datos principal hasta que llega al receptor WAL de la réplica.

Si el network_lag es cero o insignificante, pero el replica_lag es alto, significa que el receptor de WAL no puede aplicar los cambios de replicación con la suficiente rapidez.

Verificar la replicación

Para verificar que la replicación funciona, ejecuta la siguiente instrucción en la réplica:

  select status, last_msg_receipt_time from pg_stat_wal_receiver;

Si se está produciendo la replicación, verás el estado streaming y un valor reciente de last_msg_receipt_time:

  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á produciendo la réplica, se devuelve un resultado vacío:

  postgres=> select status, last_msg_receipt_time from pg_stat_wal_receiver;
  status | last_msg_receipt_time
  --------+-----------------------
  (0 rows)

Siguientes pasos