AlloyDB tiene una arquitectura que separa el procesamiento y el almacenamiento, lo que permite que cada uno se escale de forma independiente. Si bien las instancias principales y de grupos de lectura comparten el mismo almacenamiento subyacente, la replicación sigue siendo un proceso fundamental 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 del 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 inmediatamente el WAL en el disco.
- Aplicación (o reproducción) del WAL: El WAL persistente se reproduce en la réplica, lo que significa que los cambios se aplican a las memorias caché de la réplica.
Las demoras en cualquiera de estos pasos contribuyen a lo que se conoce como rezago de replicación. Sin embargo, este término puede ser ambiguo. Para ser más precisos, podemos desglosar el retraso de la replicación en los siguientes dos componentes:
- Vaciamiento o retraso de la red: Es la demora en el paso de vaciamiento del WAL. Es el tiempo que tarda el WAL en enviarse desde la instancia principal y persistirse 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.
Si debes preocuparte más por el retraso de vaciado o el retraso de reproducción depende de tu caso de uso:
- Si te preocupa la pérdida de datos, por ejemplo, con los clústeres secundarios, debes prestar mucha atención al retraso de vaciado. Si el WAL aún no se persiste en la réplica y falla el nodo principal, 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 al retraso de vaciado y 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 obsoletos 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 de tu grupo de lectura y recibir alertas en un límite especificado con Crea políticas de alertas de límite 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 solucionarlas.
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 verticalmente o escalar 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 estos casos, se recomienda usar nodos de lectura más grandes para brindarles 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, se bloquea la reproducción hasta que la consulta libera el recurso.
Puedes identificar estos conflictos buscando mensajes canceling statement due to conflict with recovery en el archivo postgres.log del 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 podría provocar 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 trasladar las consultas de larga duración a otro grupo de lectura en el que el retraso de replicación bajo no sea tan crítico.
Verifica que
alloydb.promote_cancel_to_terminateesté activo: Esta marca, que está activada de forma predeterminada, permite que AlloyDB finalice de forma forzosa los backends de consultas 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 basadas en el rezago
AlloyDB también te permite controlar si habilitar la limitación basada en el rezago 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 deteniendo el inicio de las consultas nuevas y leyendo los búferes nuevos durante un máximo de un minuto cuando el retraso de la replicación supera un segundo. Esta función realiza una compensación que mejora el retraso de la replicación, ya que le otorga más recursos a la reproducción para que se ponga 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
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.Supervisión de Cloud: 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 durante el 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 las métricas de estadísticas del sistema.Estadísticas de consultas: En el panel de 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 al retraso de la 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 de replicación. Puedes supervisar el tráfico de escritura en tu instancia principal en la consola de Google Cloud .
Transacciones grandes
Las transacciones que modifican una gran cantidad de filas (por ejemplo, borrar 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 las 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 la replicación.
Soluciona problemas que impiden la replicación
Antes de que pueda haber un retraso en la replicación, debe haber un grupo de lectura en funcionamiento. Los siguientes problemas pueden impedir que se produzca la replicación por completo, ya sea impidiendo la creación de un grupo de lectura o provocando que falle una réplica de lectura.
Fallas en la instancia del grupo de lectura
En PostgreSQL 14, una transacción de larga duración en la instancia principal que contiene una larga lista de bloqueos exclusivos puede hacer que crezca el uso de memoria de una réplica de lectura, lo que podría 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, esto no se aplica a 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, si cambias su tamaño, es posible que la réplica no tenga una caché completamente activa cuando se complete la operación, según la carga de trabajo. Esto significa que es más lento reproducir o procesar registros que aún no se almacenaron en la caché. En ese caso, es posible que el retraso de la reproducción aumente temporalmente.