AlloyDB tiene una arquitectura que separa el procesamiento y el almacenamiento, lo que permite que cada uno escale de forma independiente. Si bien las instancias principal y del grupo de lectura comparten el mismo almacenamiento subyacente, la replicación sigue siendo un proceso crucial para mantener la coherencia y la actualización de los datos en las réplicas de lectura. En un clúster de AlloyDB, las escrituras se realizan en la instancia principal y, luego, se registran en el registro de escritura anticipada (WAL). Luego, estos cambios se replican en los nodos del grupo de lectura. Comprender los dos pasos principales de este proceso de replicación es clave para solucionar cualquier problema:
- Vaciado de WAL: El registro de escritura anticipada (WAL), que contiene los cambios en la base de datos, se envía de la instancia principal a la réplica. Luego, la réplica conserva de inmediato el WAL en el disco.
- Aplicación (o reproducción) de WAL: El WAL persistente se reproduce en la réplica, lo que significa que los cambios se aplican a las cachés de la réplica.
Los retrasos en cualquiera de estos pasos contribuyen a lo que se conoce como retraso de replicación. Sin embargo, este término puede ser ambiguo. Para ser más precisos, podemos desglosar el retraso de replicación en los siguientes dos componentes:
- Retraso de vaciado o de red: Es la demora en el paso de vaciado del WAL. Es el tiempo que tarda el WAL en enviarse desde la instancia principal y persistir en la réplica.
- Retraso de reproducción: Es la demora en el paso de aplicación del WAL. Es el tiempo que tarda la réplica en aplicar los cambios del WAL.
La importancia de la demora de vaciado o la demora de reproducción depende de tu caso de uso:
- Si te preocupa la pérdida de datos, por ejemplo, con clústeres secundarios, debes prestar mucha atención al retraso de vaciado. Si el WAL aún no se conserva en la réplica y la instancia principal falla, los cambios se pierden desde la perspectiva de la réplica.
- Si te preocupa la actualización de los datos en tus réplicas de lectura, debes prestar mucha atención tanto al retraso de vaciado como al retraso de reproducción. Una demora en cualquiera de los pasos, ya sea en la transmisión del WAL o en su aplicación, genera datos inactivos en tus réplicas de lectura.
Verifica el retraso de replicación
Puedes supervisar el retraso de replicación de tus instancias de grupo de lectura en la consola de Google Cloud . Para obtener más información, consulta Supervisa instancias. También puedes supervisar el retraso de replicación del grupo de lectura y recibir alertas en un umbral especificado con Crea políticas de alertas de umbral de métricas.
Causas comunes del retraso de replicación
A continuación, se indican algunas causas comunes del retraso de replicación y cómo abordarlas.
Contención de recursos
La replicación también puede ralentizarse debido a la contención de recursos del sistema, como la CPU y la memoria.
- Presión de CPU y memoria: Una carga de trabajo de lectura pesada en una instancia de grupo de lectura puede competir con el proceso de replicación por los recursos de CPU y memoria. Puedes verificar el uso de CPU y memoria de tus instancias en la consola de Google Cloud . Si observas un uso alto de recursos, es posible que debas escalar vertical u horizontalmente tus instancias de grupo de lectura.
- Tamaño del nodo del grupo de lectura: Si tu instancia principal es mucho más grande que los nodos del grupo de lectura, es posible que genere registros de replicación más rápido de lo que los nodos de lectura pueden procesarlos. En esos casos, se recomienda usar nodos de lectura de mayor tamaño para dar más recursos a las réplicas.
Conflictos de replicación
A veces, las consultas de lectura pueden bloquear el proceso de replicación porque retienen recursos que el proceso de replicación está esperando. Si una consulta de lectura mantiene un bloqueo en un objeto de base de datos que el proceso de reproducción necesita actualizar, se produce un conflicto de bloqueo. Si una consulta mantiene una fijación en un búfer de datos que la reproducción necesita modificar, se produce un conflicto de fijación de búfer. En ambos casos, la reproducción se bloquea hasta que la consulta libera el recurso.
Para identificar estos conflictos, busca mensajes canceling statement due to conflict with recovery en el archivo postgres.log en el Explorador de registros.
Para mitigar los conflictos de replicación, puedes hacer lo siguiente:
Reduce
max_standby_streaming_delay: este parámetro determina cuánto tiempo espera el proceso de reproducción antes de cancelar las consultas que lo bloquean. El valor predeterminado es 30 segundos. Reducir este valor puede ayudar a reducir el retraso de la replicación, pero también puede causar que se cancelen más consultas de lectura. Puedes ajustar este parámetro para encontrar el mejor equilibrio para tu aplicación.Evita las consultas de larga duración: las consultas de larga duración en los grupos de lectura pueden aumentar la probabilidad de conflictos de replicación. Considera mover las consultas de larga duración a un grupo de lectura diferente en el que el retraso de replicación bajo no sea tan crítico.
Verifica que
alloydb.promote_cancel_to_terminateesté activa: esta marca, que está activada de forma predeterminada, permite que AlloyDB finalice de forma forzosa los backends de consulta que no responden a las solicitudes de cancelación. Esto puede ayudar a evitar que los backends que no responden bloqueen la replicación durante períodos prolongados.
Regulación de consultas de lectura basada en el retraso
AlloyDB también te permite controlar si deseas habilitar la limitación basada en el retraso de las consultas de lectura en los nodos de lectura con la marca google_storage.log_replay_throttle_read_transactions. Si el parámetro se establece en su valor predeterminado de on, las consultas de lectura se limitan pausando el inicio de consultas nuevas y leyendo búferes nuevos durante un máximo de un minuto cuando el retraso de replicación supera un segundo. Esta función hace un intercambio que mejora el retraso de la replicación, ya que le da a la repetición más recursos para ponerse al día más rápido, a costa de aumentar potencialmente la latencia de las consultas de lectura. Si tu aplicación no es sensible al retraso de replicación, puedes priorizar la mejora de la latencia de las consultas de lectura configurando google_storage.log_replay_throttle_read_transactions como off.
Puedes supervisar el impacto de la limitación de consultas con los siguientes métodos:
Registros: Busca mensajes de
Delayed.*due to replica lagen el archivopostgres.logen el Explorador de registros para identificar cuándo se retrasan las consultas debido al retraso de la réplica.Cloud Monitoring: Usa la métrica
alloydb.googleapis.com/instance/postgresql/wait_countpara ver cuántas consultas se limitaron. Para ello, filtra la métrica porwait_event_namey buscaHighLagThrottle. Para ver el tiempo total que se limitaron las consultas, puedes usar la métricaalloydb.googleapis.com/instance/postgresql/wait_timecon el mismo filtro. Para obtener más información, consulta la referencia de métricas de estadísticas del sistema.Estadísticas de consultas: En el panel Estadísticas de consultas, la vista Consultas activas muestra el evento de espera
HighLagThrottleen la columna Evento de espera cuando se limita una consulta debido a un retraso de replicación. Para obtener más detalles, consulta Supervisa las consultas activas.
Carga de trabajo pesada
Un aumento repentino en la carga de trabajo de escritura en la instancia principal puede generar una gran cantidad de registros de replicación, lo que puede sobrecargar las instancias del grupo de lectura y causar un retraso en la replicación. Puedes supervisar el tráfico de escritura en tu instancia principal en la consola de Google Cloud .
Gran volumen de registros de escritura anticipada debido a la compilación del índice de ScaNN
La compilación del índice de ScaNN puede generar grandes cantidades de registros de WAL de escritura de página completa. Esto puede causar un retraso en el envío de registros de WAL desde tu instancia principal
a las instancias de lectura. Si el retraso de la replicación corresponde a la compilación del índice de ScaNN
en grandes cantidades de incorporaciones, puedes activar wal_compression en la instancia principal para ahorrar E/S de red y disco, y reducir el retraso de la replicación. Esto puede generar una pequeña cantidad
de sobrecarga adicional de CPU.
wal_compression solo comprime los registros de escritura de página completa y no tiene
efecto en la mayoría de los registros de WAL. Cambiar esta marca no requiere un reinicio y
no tiene tiempo de inactividad.
Transacciones grandes
Las transacciones que modifican una gran cantidad de filas, por ejemplo, borrando varias tablas o tablas grandes, generan registros COMMIT o ABORT excepcionalmente grandes en el registro de escritura anticipada (WAL). Estos registros pueden tardar una cantidad de tiempo significativa en reproducirse en los nodos del grupo de lectura, lo que genera un aumento temporal en el retraso de la replicación.
Para mitigar este problema, evita realizar operaciones por lotes muy grandes, como eliminaciones, en una sola transacción. En su lugar, divide estas operaciones en transacciones más pequeñas y frecuentes. Esto reduce el tamaño de los registros individuales de COMMIT y ABORT, lo que permite que el flujo de replicación siga siendo más fluido y reduce el retraso máximo de replicación.
Soluciona problemas que impiden la replicación
Antes de que puedas tener un retraso de replicación, debes tener un grupo de lectura en funcionamiento. Los siguientes problemas pueden impedir que se realice la replicación, ya sea porque no se puede crear un grupo de lectura o porque se produce una falla en una réplica de lectura.
Fallas de la instancia de grupo de lectura
En PostgreSQL 14, una transacción de larga duración en la instancia principal que contiene una lista larga de bloqueos exclusivos puede hacer que aumente el uso de memoria de una réplica de lectura, lo que, con el tiempo, puede provocar que la instancia del grupo de lectura falle.
Para mitigar este problema, puedes finalizar la transacción de larga duración en la instancia principal.
Impacto del cambio de tamaño de la instancia en el retraso de replicación
La arquitectura de almacenamiento de AlloyDB garantiza que el retraso de vaciado del grupo de lectura no se vea afectado por el cambio de tamaño de la instancia. Sin embargo, no ocurre lo mismo con la repetición. La capacidad de la réplica para reproducir depende de la carga que tenga. Si actualizas la configuración de la instancia, por ejemplo, cambiando su tamaño, según la carga de trabajo, es posible que la réplica no tenga una caché completamente preparada cuando se complete la operación. Esto significa que es más lento reproducir o procesar registros que aún no se almacenaron en caché. En ese caso, esto podría significar que el retraso de la reproducción aumenta de forma temporal.