Configuración de ranuras de conmutación por error en PostgreSQL-17

PostgreSQL 17 introduce los slots de failover que mejoran las configuraciones de alta disponibilidad. Un slot de replicación garantiza que los datos se mantengan confiables y consistentes entre nodos durante la replicación, mientras que un slot de failover asegura la consistencia entre nodos, específicamente durante y después de un failover.

Los slots de failover son una característica poderosa que asegura que la replicación lógica pueda continuar sin problemas, incluso después de un failover a un servidor en espera. Usar slots de failover permite que los slots de replicación lógica se sincronicen automáticamente entre nodos primarios y en espera, reduciendo significativamente el tiempo de inactividad y la necesidad de intervención manual durante un failover.

Esta guía te guiará a través de la configuración de un clúster de alta disponibilidad PostgreSQL utilizando la nueva función de slots de failover. Al final, tendrás una configuración de replicación robusta capaz de manejar un failover sin problemas.

Por qué los Slots de Failover son Importantes desde una Perspectiva Histórica

Desafíos en PostgreSQL 15

• Slots de Replicación Vinculados al Nodo Primario: En PostgreSQL 15, los slots de replicación solo se creaban en el servidor primario. Todos los slots de replicación lógica se perdían si el servidor primario fallaba, lo que conducía a retrasos significativos en la replicación y pérdida de datos.
• Gestión Manual del Failover: Durante los escenarios de failover, los administradores recreaban manualmente los slots de replicación en el nuevo servidor primario, lo que aumentaba la complejidad, introducía errores y prolongaba el tiempo de inactividad.
• Sin Sincronización de Slots: Los servidores en espera no tenían forma de conocer los slots de replicación lógica en el primario. Esta falta de sincronización llevaba a un reinicio completo de los flujos de replicación si ocurría un failover.

Mejoras en PostgreSQL 16

Decodificación Lógica Mínima

PostgreSQL 16 introdujo una característica llamada decodificación lógica mínima en los servidores en espera:

• Decodificación Mínima en el Servidor en Espera: Esto permitió a los servidores en espera decodificar los logs WAL para prepararse para la replicación lógica, permitiendo slots precalentados para usar en caso de un failover.
• Failover más Rápido: Al pre-decodificar los cambios WAL en el servidor en espera, fue posible reducir el retraso de replicación al promover un servidor en espera a primario. Sin embargo, esto aún requería alguna configuración manual para garantizar un failover sin problemas.

PostgreSQL 17: El Cambiador de Juego – Slots de Failover

• Slots de Failover: La introducción de slots de failover en PostgreSQL 17 elimina la necesidad de intervención manual al sincronizar automáticamente los slots de replicación lógica entre los servidores primario y en espera.
• Sincronización Automática: El nuevo worker de sincronización de slots garantiza que los slots habilitados para failover (failover = true) estén siempre sincronizados, incluso cuando el nodo primario está activo.
• Transición sin interrupciones: En caso de conmutación por error, el servidor en espera puede tomar el control como primario sin perder ningún espacio de replicación, asegurando cero pérdida de datos y replicación continua.

Creación de un clúster de alta disponibilidad con slots de conmutación por error

Esta sección te guiará en la creación de un clúster de alta disponibilidad de PostgreSQL con slots de conmutación por error. En nuestro ejemplo, utilizaremos los siguientes nodos:

1. NodoA (Servidor primario)
2. NodoB (Réplica física)
3. NodoC (Suscriptor lógico)

Prerrequisitos

Antes de comenzar, asegúrate de tener:

• PostgreSQL 17 instalado en los tres nodos.
• Acceso SSH sin contraseña entre cada nodo.
• Un conocimiento básico de PostgreSQL, replicación de PostgreSQL, y archivos de configuración de PostgreSQL.

Paso 1: Configurar el Nodo Primario (NodoA)

1.1 Inicializar el clúster en el NodoA

Después de instalar PostgreSQL en el nodo primario, inicialice el clúster; puede utilizar los siguientes comandos:

mkdir -p /home/pgedge/nodeA

​

initdb -D /home/pgedge/nodeA --no-locale -E UTF8 

​

pg_ctl -D /home/pgedge/nodeA -l /home/pgedge/logs/nodeA.log start 

1.2 Configurar la replicación en el archivo postgresql.conf

Después de inicializar el clúster, edite el archivo postgresql.conf, ubicado de forma predeterminada en /home/pgedge/nodeA/postgresql.conf. Establezca los siguientes valores de parámetros:

wal_level = logical

​

max_replication_slots = 10

​

max_wal_senders = 10

​

synchronous_standby_names = '*'

​

synchronized_standby_slots = 'sb1_slot'

​

port = 5432

1.3 Actualizar el archivo pg_hba.conf para permitir el Acceso a la Replicación

El archivo pg_hba.conf gestiona la autenticación de clientes para el servidor PostgreSQL. Agregue la siguiente entrada a /home/pgedge/nodeA/pg_hba.conf para garantizar el acceso a un usuario de replicación:

host replication replicator 127.0.0.1/32 md5

Luego, recargue la configuración:

pg_ctl -D /home/pgedge/nodeA reload 

1.4 Crear un Usuario de Replicación

Luego, inicie sesión en PostgreSQL y cree el usuario de replicación:

psql -d postgres -p 5432 

CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'replicator_password';

1.5 Crear una Tabla y Configurar una Publicación

A continuación, deberá crear una tabla y crear una publicación asociada:

CREATE TABLE foo (c1 INT PRIMARY KEY);

​

GRANT SELECT ON foo TO replicator;

​

CREATE PUBLICATION mypub FOR TABLE foo;

Paso 2: Configurar el Segundo Nodo Físico (NodeB)

2.1 Inicializar NodeB

Después de instalar PostgreSQL, inicialice NodeB:

mkdir -p /home/pgedge/nodeB 

​

initdb -D /home/pgedge/nodeB --no-locale -E UTF8 

​

pg_ctl -D /home/pgedge/nodeB -l /home/pgedge/logs/nodeB.log start

2.1 Crear una Copia de Seguridad Base

Luego, use pg_basebackup para realizar una copia de seguridad del clúster:

mkdir -p /home/pgedge/nodeB 

​

pg_basebackup -D /home/pgedge/nodeB -R -X stream -P -h localhost -p 5432 -U replicator

2.2 Configurar postgresql.conf en el Nodo-B

Modifique el archivo postgresql.conf (ubicado en /home/pgedge/nodeB/postgresql.conf), estableciendo:

port = 5433

​

primary_conninfo = 'host=localhost port=5432 user=replicator password=replicator_password dbname=postgres application_name=sb1_slot'

​

primary_slot_name = 'sb1_slot'

​

hot_standby_feedback = on

​

sync_replication_slots = on

2.3 Habilitar la Sincronización de Slots de Failover

Utilice el cliente psql para iniciar sesión en NodeB:

psql -d postgres -p 5433 

Luego, utilice las siguientes declaraciones para configurar la replicación para NodeB:

ALTER SYSTEM SET sync_replication_slots = on;

​

ALTER SYSTEM SET hot_standby_feedback = on;

​

ALTER SYSTEM SET synchronized_standby_slots = 'sb1_slot';

Salga del cliente psql y reinicie NodeB:

pg_ctl -D /home/pgedge/nodeB restart 

2.4 Verificar la Sincronización de Slots

Luego, vuelva a conectarse a NodeB con psql y verifique que los slots estén sincronizados:

SELECT slot_name, failover, synced FROM pg_replication_slots;

Paso 3: Configuración del Suscriptor Lógico (NodeC)

3.1 Inicialice el clúster y configure NodeC

Después de instalar PostgreSQL, inicialice el clúster; puede utilizar los siguientes comandos:

mkdir -p /home/pgedge/nodeC

​

initdb -D /home/pgedge/nodeC --no-locale -E UTF8

Luego, edite el archivo /home/pgedge/nodeC/postgresql.conf, estableciendo los siguientes valores de parámetros:

wal_level = logical

​

max_replication_slots = 10

​

max_wal_senders = 10

​

sync_replication_slots = on

​

port = 5444

​

After editing the configuration file, start NodeC:

​

pg_ctl -D /home/pgedge/nodeC -l /home/pgedge/logs/nodeC.log start

3.2 Crear una Suscripción en NodeC

Utilice el siguiente comando para crear una suscripción en NodeC:

CREATE SUBSCRIPTION foosub CONNECTION 'dbname=postgres host=localhost port=5432 user=replicator password=replicator_password' PUBLICATION mypub WITH (failover = true);

Paso 4: Simulación de Failover y Garantía de Continuidad

Puede utilizar los siguientes comandos para simular un failover y confirmar que la replicación continúa y la integridad de los datos se mantiene.

4.1 Simulación de un Failover

Utilice los siguientes comandos para simular una falla de NodeA, seguida por la promoción de standby a primario de NodeB:

pg_ctl -D /home/pgedge/nodeA stop

​

pg_ctl -D /home/pgedge/nodeB promote

4.2 Actualizar la Suscripción en NodeC

Después de promocionar el nodo B, inicie sesión en el nodo C y actualice la conexión para reflejar que el nodo B es ahora el nodo principal:

ALTER SUBSCRIPTION foosub DISABLE;

​

ALTER SUBSCRIPTION foosub CONNECTION 'dbname=postgres host=localhost port=5433 user=replicator password=replicator_password';

​

ALTER SUBSCRIPTION foosub ENABLE;

4.3 Verificar la Continuidad de los Datos

Para probar la replicación, use psql para iniciar sesión en el Nodo-B (ahora el principal):

INSERT INTO foo VALUES (3), (4);

Verificar la replicación en el Nodo-C:

SELECT * FROM foo;

Conclusión

La característica de espacio de failover de PostgreSQL 17 permite un failover sin inconvenientes en entornos de replicación lógica. Siguiendo los pasos descritos en esta guía, puede crear un clúster de alta disponibilidad que garantiza un flujo de datos ininterrumpido, incluso durante una falla del servidor principal.

Optimizando las configuraciones y aprovechando las nuevas capacidades de PostgreSQL 17, puede crear una infraestructura de base de datos resiliente y eficiente para sus aplicaciones críticas.