La alta disponibilidad (HA) en AlloyDB para PostgreSQL mantiene tu base de datos operativa y tus datos accesibles para las aplicaciones cliente durante las fallas zonales o de instancias. A diferencia de las instancias zonales, que pueden experimentar un tiempo de inactividad prolongado durante una interrupción, las instancias de HA conmutan por error automáticamente entre los nodos activos y en espera en todas las zonas. Para configurar una instancia para la HA, consulta Visualiza la configuración del clúster y de la instancia.
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 zonas diferentes. Para el almacenamiento, AlloyDB usa un persistente de registros regional para almacenar los 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 con un balanceador de cargas.
Cuando se procesan las operaciones de escritura, la base de datos de AlloyDB primero escribe el WAL en su persistencia de registros regional en el nodo activo y, luego, transfiere de forma asíncrona los registros a los servidores de procesamiento de registros regionales en AlloyDB, que materializan los registros en bloques de datos para el almacenamiento a largo plazo. Luego, AlloyDB limpia los registros que se procesaron 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 realiza la conmutación por error de la instancia principal de forma automática 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 vuelva a estar en línea. No se produce pérdida de datos durante la conmutación por error debido a las escrituras síncronas de WAL en el persistente 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.
La conmutación por error se produce en la siguiente secuencia de eventos:
- El nodo o la zona activos fallan. El sistema de supervisión de estado de AlloyDB verifica de forma periódica si el nodo activo está en buen estado. Si el sistema de supervisión de estado falla en varias verificaciones, se 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 de los clientes se realizan correctamente después de una reconexión.
- AlloyDB vuelve a crear un nodo en espera en la zona que estaba activa anteriormente. Este nodo en espera estará 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.
Arquitectura de espera activa
Las instancias de AlloyDB con PostgreSQL 18 proporcionan una conmutación por error mejorada con la función de espera activa.
Con la función de espera activa, AlloyDB ejecuta el nodo en espera como una réplica. Durante la conmutación por error, esta réplica puede pasar a un modo de lectura y escritura más rápido, lo que reduce el tiempo de inactividad. Además, la replicación habilita las cachés activas, lo que ayuda a garantizar un rendimiento de consultas coherente después de la conmutación por error.
En el siguiente diagrama, se muestra la arquitectura de alta disponibilidad con la
espera activa incluida.
Figura 3. Espera activa.
Grupos de lectura
Las instancias de grupo de lectura con dos o más nodos tienen alta disponibilidad. Los nodos se distribuyen de manera uniforme entre las zonas, lo que crea resiliencia ante 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 detiene temporalmente durante la conmutación por error y se reanuda automáticamente después de que se recupera la instancia principal.