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) en el almacenamiento compartido. Luego, estos cambios se replican en las cachés en memoria de las instancias 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 de inmediato el WAL en el disco. 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 el retraso 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 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 las réplicas entre regiones, 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 reproducción. Un retraso de reproducción alto significa que los datos de tus réplicas de lectura están desactualizados.
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 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 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. Por ejemplo, si una consulta de lectura tiene un bloqueo en un objeto de base de datos que el proceso de replicación necesita actualizar, la replicación se bloquea hasta que se libera el bloqueo. Estos se conocen como conflictos de fijación de búfer.
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 replicación antes de cancelar las consultas que lo bloquean. El valor predeterminado es 30 segundos. Reducir este valor puede ayudar a disminuir 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.
Habilita
alloydb.promote_cancel_to_terminate: 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 temporal de consultas de lectura
AlloyDB también te permite controlar si habilitar la limitación basada en el rezago de una consulta de lectura en 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 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.logdel 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 grandes, como los registros COMMIT o ABORT que afectan a una gran cantidad de filas, pueden tardar mucho en replicarse en las instancias del grupo de lectura. En PostgreSQL 14, una transacción de larga duración que mantiene una larga lista de bloqueos exclusivos puede hacer que crezca el uso de memoria de la réplica de lectura, lo que podría provocar que se falle la instancia del grupo de lectura.
Para mitigar este problema, puedes finalizar la transacción de larga duración en la instancia principal.
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.
Problemas de creación de grupos de lectura
Si no se puede crear un grupo de lectura, es posible que veas un mensaje de Failed to create read pool en los registros de AlloyDB en Cloud Logging. Esto puede suceder si el clúster alcanzó su límite de almacenamiento máximo, lo que impide que la instancia principal asigne más espacio. Si bien AlloyDB ajusta automáticamente la escala del almacenamiento, es posible que debas investigar qué consume el almacenamiento y borrar los datos innecesarios, o bien comunicarte con el equipo de asistencia para solicitar un aumento en tu cuota de almacenamiento.
Fallas en la instancia del grupo de lectura
En PostgreSQL 14, una transacción de larga duración en la instancia principal que mantiene 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 tu 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 repetición aumente temporalmente.