Solucionar problemas de replicación

AlloyDB tiene una arquitectura que separa la computación del almacenamiento, lo que permite que cada uno se escale de forma independiente. Aunque las instancias del grupo de lectura y la principal 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, a continuación, se registran en el registro Write-Ahead Log (WAL) del almacenamiento compartido. Estos cambios se replican en las cachés en memoria de las instancias del grupo de lectura. Para solucionar cualquier problema, es fundamental conocer los dos pasos principales de este proceso de replicación:

  • Sincronización de WAL: el registro Write-Ahead Log (WAL), que contiene los cambios en la base de datos, se envía de la principal a la réplica. A continuación, la réplica persiste inmediatamente el WAL en el disco. Los retrasos en cualquiera de estos pasos contribuyen a lo que se conoce como "latencia 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 dos componentes siguientes:

  • Retraso de la red o de la descarga: es el retraso en el paso de descarga de WAL. Es el tiempo que tarda en enviarse el WAL desde el elemento principal y en conservarse en la réplica.

  • Retraso de la réplica: es el retraso en el paso de aplicación de WAL. Es el tiempo que tarda la réplica en aplicar los cambios del WAL.

Si debes preocuparte más por la latencia de vaciado o la latencia de repetición depende de tu caso práctico:

  • Si le preocupa la pérdida de datos (por ejemplo, con réplicas entre regiones), debe prestar mucha atención a la latencia de vaciado. Si el WAL aún no se ha conservado en la réplica y el servidor principal falla, los cambios se pierden desde la perspectiva de la réplica.
  • Si te preocupa la actualización de los datos de tus réplicas de lectura, debes prestar mucha atención al retraso de la reproducción. Un intervalo de réplica alto significa que los datos de tus réplicas de lectura están obsoletos.

Comprobar la latencia de replicación

Puede monitorizar el desfase de replicación de las instancias de su grupo de lectura en la Google Cloud consola. Para obtener más información, consulta Monitor instances (Monitorizar instancias). También puede monitorizar el desfase de replicación del grupo de lectura y recibir alertas cuando se alcance un umbral específico mediante la opción Crear políticas de alertas basadas en métricas.

Causas habituales del retraso de la réplica

A continuación, se indican algunas causas habituales de la latencia 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 consultar el uso de la CPU y la memoria de tus instancias en la Google Cloud consola. Si observas un uso elevado de los recursos, puede que tengas que aumentar o ampliar las instancias de tu grupo de lectura.
  • Tamaño de los nodos del grupo de lectura: si tu instancia principal es mucho más grande que los nodos del grupo de lectura, puede generar 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 de mayor tamaño para proporcionar más recursos a las réplicas.

Conflictos de replicación

Las consultas de lectura a veces 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 conflictos se conocen como conflictos de fijación de búferes.

Para identificar estos conflictos, busca 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 de 30 segundos. Reducir este valor puede ayudar a reducir el retraso de la replicación, pero también puede 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 que se produzcan conflictos de replicación. Plantéate mover las consultas de larga duración a otro grupo de lectura en el que la latencia de replicación baja no sea tan importante.

  • Habilita alloydb.promote_cancel_to_terminate: esta marca, que está activada de forma predeterminada, permite que AlloyDB finalice de forma forzosa los back-ends de consultas que no responden a las solicitudes de cancelación. Esto puede ayudar a evitar que los back-ends que no responden bloqueen la replicación durante periodos prolongados.

Limitación temporal de consultas de lectura

AlloyDB también te permite controlar si quieres habilitar la limitación basada en la latencia de una consulta de lectura en los nodos de lectura mediante la marca google_storage.log_replay_throttle_read_transactions. Si el parámetro tiene el valor predeterminado on, las consultas de lectura se limitan pausando el inicio de nuevas consultas y la lectura de nuevos búferes durante un minuto como máximo cuando la latencia de replicación supera un segundo. Esta función hace un intercambio que mejora el retraso de la réplica al dar 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 a la latencia 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 monitorizar el impacto de la limitación de consultas con los siguientes métodos:

  • Registros: busca mensajes de Delayed.*due to replica lag en el archivo postgres.log del Explorador de registros para identificar cuándo se retrasan las consultas debido al desfase de las réplicas.

  • Monitorización en la nube: usa la métrica alloydb.googleapis.com/instance/postgresql/wait_count para ver cuántas consultas se han limitado. Para ello, filtre la métrica por wait_event_name y busque HighLagThrottle. Para ver el tiempo total durante el que se han limitado las consultas, puede usar la métrica alloydb.googleapis.com/instance/postgresql/wait_time con el mismo filtro. Para obtener más información, consulta la referencia de métricas de estadísticas del sistema.

  • Estadísticas de las consultas: en el panel de control Estadísticas de las consultas, la vista Consultas activas muestra el evento de espera HighLagThrottle en la columna Evento de espera cuando se limita una consulta debido al retraso de la replicación. Para obtener más información, consulta Monitorizar consultas activas.

Carga de trabajo pesada

Un aumento repentino de 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 provocar un retraso en la replicación. Puedes monitorizar el tráfico de escritura de tu instancia principal en la consola de Google Cloud .

Transacciones grandes

Las transacciones de gran tamaño, como los registros COMMIT o ABORT que afectan a un gran número de filas, pueden tardar mucho tiempo en replicarse en las instancias del grupo de lectura. En PostgreSQL 14, una transacción de larga duración que contiene una lista larga de bloqueos exclusivos puede provocar que aumente el uso de memoria de la 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.

Solucionar problemas que impiden la replicación

Para que haya un retraso en la replicación, debe tener un grupo de lectura que funcione. Los siguientes problemas pueden impedir que se produzca la replicación, ya sea impidiendo la creación de un grupo de lectura o provocando que se bloquee una réplica de lectura.

Problemas con la creación de grupos de lectura

Si no se puede crear un grupo de lectura, es posible que veas un mensaje Failed to create read pool en los registros de AlloyDB en Cloud Logging. Esto puede ocurrir si el clúster ha alcanzado su límite de almacenamiento máximo, lo que impide que la instancia principal asigne más espacio. Aunque AlloyDB escala el almacenamiento automáticamente, es posible que tengas que investigar qué consume almacenamiento y eliminar los datos innecesarios, o ponerte en contacto con el equipo de Asistencia para solicitar un aumento de tu cuota de almacenamiento.

Fallos de instancias de grupos 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 provocar que aumente 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 la replicación

La arquitectura de almacenamiento de AlloyDB asegura 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 volver a reproducir depende de la carga que tenga. Si actualiza la configuración de la instancia (por ejemplo, cambiando su tamaño), es posible que la réplica no tenga una caché totalmente calentada cuando se complete la operación, en función de la carga de trabajo. Esto significa que tarda más en reproducir o procesar registros que aún no ha almacenado en caché. En ese caso, puede que el retraso de la repetición aumente temporalmente.