Intervalo de replicación

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.
Los dos primeros casos mencionados se pueden supervisar con la métrica network_lag. El tercero se observa con 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 con 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 Supervisa el retraso de replicación.

Asegúrate de que la réplica esté aprovisionada de forma adecuada

Una instancia de réplica que es más pequeña que la instancia principal (por ejemplo, con menos vCPU y memoria) puede experimentar un retraso de replicación. Una réplica más pequeña también puede tener diferentes marcas de configuración predeterminadas en comparación con una instancia principal más grande. Recomendamos que la instancia de réplica sea al menos tan grande como la instancia principal para tener suficientes recursos para controlar la carga de replicación.

El uso alto de CPU en la réplica también puede causar un retraso de replicación. Si el uso de CPU de la réplica es alto (por ejemplo, más del 90%), considera 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 la instancia principal, y compararlas para ver las diferencias.

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. Esto puede suceder cuando la replicación intenta aplicar cambios (como una operación VACUUM) a las filas que lee una consulta en la réplica.

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.

Para ayudar a abordar los retrasos o bloqueos de replicación causados por transacciones de larga duración, te recomendamos lo siguiente:

  • Ajusta las marcas de demora en espera. Las marcas max_standby_archive_delay y max_standby_streaming_delay controlan cuánto tiempo esperará una réplica antes de cancelar las consultas en espera que entren en conflicto con la replicación. Los valores razonables suelen ser de entre 30 y 60 segundos. Puedes consultar la vista pg_stat_database_conflicts para obtener información sobre los conflictos de consultas.
  • Habilita la marca hot_standby_feedback. Si configuras la marca hot_standby_feedback en on en la réplica, puedes retrasar las operaciones de vacío en la instancia principal. Sin embargo, esto puede causar una expansión de la tabla en la instancia principal, por lo que es una compensación.

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

Retraso de red alto

Un retraso de red alto indica que la instancia principal no envía los registros WAL o que la réplica no los recibe lo suficientemente rápido. Esto puede deberse a lo siguiente:

  • Replicación entre regiones. La replicación entre diferentes regiones puede generar una latencia de red más alta.
  • Uso alto de CPU principal. Si la CPU principal supera el 90%, es posible que el proceso del emisor de WAL no obtenga suficiente tiempo de CPU. Considera reducir la carga en la instancia principal o aumentar su CPU.
  • Uso alto de CPU de la réplica. Si la CPU de la réplica supera el 90%, es posible que el proceso del receptor de WAL no obtenga suficiente tiempo de CPU. Considera reducir la carga en la réplica o aumentar su CPU.
  • Problemas de ancho de banda de red o cuellos de botella de E/S de disco. Una región más cercana o una configuración de disco de mayor capacidad de procesamiento podrían ayudar. Considera modificar el valor de la marca wal_compression en la instancia principal para ayudar a reducir el tráfico entre regiones.
Puedes supervisar el retraso de red con la métrica cloudsql.googleapis.com/database/replication/network_lag. Esta métrica tiene un límite máximo de 25 segundos, incluso si el retraso real es mayor.

Esta métrica network_lag es similar a la métrica cloudsql.googleapis.com/database/postgresql/replication/replica_byte_lag, que mide el retraso de sent_location en términos de bytes indicados 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 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.

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

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 now() - pg_last_xact_replay_timestamp() en la réplica. Esta es una aproximación. Si la replicación se interrumpe, la réplica no sabrá qué tan avanzada está la base de datos principal y esta métrica no indicará el retraso total.
Bytes de retraso
(cloudsql.googleapis.com/database/postgres/replication/replica_byte_lag)

La cantidad de bytes que el estado de la réplica está por atrás respecto del estado de la base de datos principal. replica_byte_lag exporta 4 series temporales, y la etiqueta replica_lag_type puede indicar cualquiera de las siguientes opciones:

  • sent_location: Indica cuántos bytes de WAL se generaron, pero que aún no se enviaron a la réplica.
  • write_location: El retraso de escritura menos envío muestra los bytes de WAL en la red que se enviaron, pero que aún no se escribieron en la réplica.
  • flush_location: El retraso de eliminación menos escritura muestra los bytes de WAL escritos en la réplica, pero que aún no se limpiaron en ella.
  • replay_location: Muestra el retraso total en bytes. La repetición menos la demora de limpieza indica la demora de la repetición.
Retraso de red
(cloudsql.googleapis.com/database/replication/network_lag)

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 el network_lag es cero o es insignificante, pero el replica_lag es alto, indica que el receptor de WAL no puede aplicar los cambios de replicación lo suficientemente rápido.

Debido a que network_lag se redondea al segundo más cercano, un valor informado de 1 segundo puede representar un retraso subyacente de cualquier valor desde uno o dos milisegundos hasta un segundo completo.

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)

Pasos siguientes: