En este documento, se proporciona una descripción general de la configuración de alta disponibilidad (HA) para instancias de AlloyDB para PostgreSQL. Para configurar una instancia nueva para HA o habilitar HA en una instancia existente, consulta Cómo ver la configuración del clúster y de la instancia settings.
Una configuración de HA garantiza la continuidad de las operaciones incluso después de eventos de falla. Si bien las instancias zonales pueden experimentar un tiempo de inactividad prolongado durante los eventos de falla, con la HA, tus datos permanecen disponibles para las aplicaciones cliente.
Instancias principal y secundaria
Una instancia principal de AlloyDB configurada con alta disponibilidad incluye un nodo activo y un nodo en espera, que se encuentran en diferentes zonas. Para el almacenamiento, AlloyDB usa un persistidor de registros regional para almacenar registros de escritura anticipada (WAL) de la base de datos y el servicio de almacenamiento regional de AlloyDB para almacenar bloques de datos. La dirección IP de la instancia enruta el tráfico al nodo activo mediante un balanceador de cargas.
Cuando procesa escrituras, la base de datos de AlloyDB primero escribe WAL en su persistidor de registros regional en el nodo activo y, luego, transfiere de forma asíncrona los registros a los servidores de procesamiento de registros regionales de AlloyDB, que materializan los registros en bloques de datos para el almacenamiento a largo plazo. Luego, AlloyDB limpia los registros que se procesan correctamente.
En el siguiente diagrama, se muestra la arquitectura de alta disponibilidad.
Figura 1. Arquitectura con alta disponibilidad
Conmutación por error
Si el nodo activo deja de estar disponible, AlloyDB conmuta por error automáticamente la instancia principal a su nodo en espera, que se convierte en el nuevo nodo activo. El balanceador de cargas reconoce el nuevo nodo activo y comienza a enrutar el tráfico hacia él. Después de una conmutación por error, el nuevo nodo activo permanece activo incluso después de que el nodo original vuelve a estar en línea. No se produce pérdida de datos durante la conmutación por error debido a las escrituras de WAL síncronas en el persistidor de registros regional.
En el siguiente diagrama, se muestra el flujo de tráfico después de la conmutación por error.
Figura 2. Flujo de tráfico después de la conmutación por error
En una de estas situaciones, se produce una conmutación por error:
- Falla el nodo o la zona activos. El sistema de supervisión de estado de AlloyDB verifica periódicamente si el nodo activo está en buen estado. Si el sistema de supervisión de estado falla en varias verificaciones, inicia la conmutación por error. Esta detección puede tardar hasta 30 segundos.
- La base de datos se inicia en el nodo en espera y comienza a aceptar conexiones. Este proceso suele tardar menos de 30 segundos.
- El nodo en espera cambia a principal. Con la dirección IP estática de la instancia, el nuevo nodo principal comienza a entregar datos y las consultas del cliente se realizan correctamente después de una reconexión.
- AlloyDB vuelve a crear un nodo en espera en la zona activa anterior. Este nodo en espera está listo para futuras conmutaciones por error.
Requisitos
Para que AlloyDB permita la conmutación por error, la configuración debe cumplir con estos requisitos:
- La instancia principal debe estar en un estado operativo normal (no detenido ni en mantenimiento).
- La zona y el nodo en espera deben estar en buen estado.
Nueva arquitectura
Las instancias de AlloyDB recién creadas con PostgreSQL 18 proporcionan una conmutación por error mejorada con una réplica de lectura en el nodo en espera (nodo en espera activa).
AlloyDB incluye una réplica de lectura en el nodo en espera activa. Durante la conmutación por error, esta réplica de lectura puede pasar a un modo de lectura y escritura más rápido, lo que reduce el tiempo de inactividad. Además, la réplica de lectura habilita las memorias caché activas, lo que ayuda a garantizar un rendimiento de consulta coherente después de la conmutación por error.
En el siguiente diagrama, se muestra la arquitectura de alta disponibilidad con el nodo en espera activa incluido.
Figura 3. Nodo en espera activa
Grupos de lectura
Las instancias de grupos de lectura con dos o más nodos tienen alta disponibilidad. Los nodos se distribuyen de manera uniforme en las zonas, lo que crea resiliencia a los eventos de falla. En caso de eventos de falla, como una falla de nodo o de zona, un balanceador de cargas regional enruta el tráfico a los nodos en buen estado restantes, lo que garantiza que no haya tiempo de inactividad para tus clientes.
Los grupos de lectura permanecen en línea durante una conmutación por error de la instancia principal. La replicación de WAL desde la instancia principal se pausa temporalmente durante la conmutación por error y se reanuda automáticamente después de que se recupera la instancia principal.
¿Qué sigue?
- Conmuta por error una instancia principal o secundaria de forma manual.
- Prueba una instancia principal para la alta disponibilidad.
- Reduce los costos con instancias básicas.