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 escenarios se pueden monitorizar con la métrica network_lag. La tercera se observa mediante 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. Para obtener más información sobre estas métricas, 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.

Puedes usar el comando SHOW ALL para ver la configuración de la réplica y de la instancia principal, y compararlas para detectar diferencias.

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. Esto puede ocurrir cuando la replicación intenta aplicar cambios (por ejemplo, de una operación VACUUM) a las filas que está leyendo una consulta en la réplica.

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.

Para solucionar los retrasos o bloqueos de la replicación causados por transacciones de larga duración, te recomendamos que hagas lo siguiente:

  • Ajusta las marcas de retardo de espera. Las marcas max_standby_archive_delay y max_standby_streaming_delay controlan el tiempo que esperará una réplica antes de cancelar las consultas en espera que entren en conflicto con la replicación. Los valores razonables suelen estar entre 30 y 60 segundos. Puedes consultar la vista pg_stat_database_conflicts para obtener información valiosa sobre los conflictos de consultas.
  • Habilita la marca hot_standby_feedback. Si se define la marca hot_standby_feedback en on en la réplica, se pueden retrasar las operaciones de vacío en la principal. Sin embargo, esto puede provocar que la tabla se hinche en la principal, por lo que es una solución intermedia.

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

Retraso de red alto

Una latencia de red alta indica que el servidor principal no envía los registros WAL o que la réplica no los recibe con la suficiente rapidez. Esto puede deberse a lo siguiente:

  • Replicación entre regiones. La replicación entre diferentes regiones puede provocar una mayor latencia de red.
  • Uso elevado de la CPU principal. Si la CPU de la réplica principal supera el 90%, es posible que el proceso de envío de WAL no obtenga suficiente tiempo de CPU. Considera la posibilidad de reducir la carga de la instancia principal o de aumentar su CPU.
  • Uso elevado de la CPU de la réplica. Si la CPU de la réplica supera el 90%, es posible que el proceso de receptor de WAL no obtenga suficiente tiempo de CPU. Prueba a reducir la carga de la réplica o a aumentar su CPU.
  • Problemas de ancho de banda de red o cuellos de botella de E/S de disco. Puede que te ayude elegir una región más cercana o una configuración de disco con un mayor rendimiento. Prueba a modificar el valor de la marca wal_compression en la instancia principal para reducir el tráfico entre regiones.
Puedes monitorizar la latencia de la red con la métrica cloudsql.googleapis.com/database/replication/network_lag. Esta métrica tiene un límite máximo de 25 segundos, aunque la latencia real sea mayor.

Esta métrica network_lag es similar a la métrica cloudsql.googleapis.com/database/postgresql/replication/replica_byte_lag que mide el sent_location en términos de bytes indicado por su etiqueta replica_lag_type.

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 usando 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 escritura menos la enviada 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 repetición menos 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 la operación 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 replicación, 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