Hola a todos, hoy os queríamos enseñar una nueva funcionalidad de PostgreSQL 16, exploraremos cómo configurar la replicación bidireccional en esta nueva versión entre dos servidores de bases de datos. Esta configuración permite que ambas bases se sincronicen mutuamente, lo que es útil en situaciones de alta disponibilidad, balanceo de carga y replicación de datos entre sitios distribuidos.
Escenario para configurar replicación bidireccional
Supongamos que tienes dos servidores:
– Servidor A: db_server_a 192.168.1.1
– Servidor B: db_server_b 192.168.1.2
Ambos necesitan replicar una tabla común, inventory, para mantener la coherencia entre las bases de datos.
Paso 1: Configuración Inicial de los Servidores
1. Habilitar la replicación lógica en ambos servidores.
En el archivo postgresql.conf de ambos servidores, agrega:
wal_level = logical
max_replication_slots = 4
max_wal_senders = 4
Esto habilita la replicación lógica y permite que los servidores se comuniquen entre sí.
2. Configurar acceso en pg_hba.conf:
Para permitir la conexión entre los servidores, edita el archivo pg_hba.conf en ambos servidores y agrega:
host replication all 192.168.1.0/24 md5
Reinicia los servidores después de realizar estos cambios.
Paso 2: Crear la Tabla y Datos Comunes para la replicación bidireccional
En ambos servidores, crea la misma tabla para replicar:
CREATE TABLE inventory (
id SERIAL PRIMARY KEY,
product_name TEXT NOT NULL,
quantity INT NOT NULL
);
Agrega algunos datos de prueba en ambos servidores:
INSERT INTO inventory (product_name, quantity) VALUES ('Widget', 100);
Paso 3: Configuración de Publicaciones y Suscripciones
1. Crear una publicación en el Servidor A:
CREATE PUBLICATION pub_inventory_a FOR TABLE inventory;
2. Crear una publicación en el Servidor B:
CREATE PUBLICATION pub_inventory_b FOR TABLE inventory;
3. Crear suscripciones en ambos servidores:
En el Servidor A, agrega una suscripción para los datos de db_server_b:
CREATE SUBSCRIPTION sub_inventory_b
CONNECTION 'host=192.168.1.2 dbname=db_server_b user=replicator password=secret'
PUBLICATION pub_inventory_b;
En el Servidor B, agrega la suscripción para los datos de db_server_a:
CREATE SUBSCRIPTION sub_inventory_a
CONNECTION 'host=192.168.1.1 dbname=db_server_a user=replicator password=secret'
PUBLICATION pub_inventory_a;
Paso 4: Manejo de Conflictos en la Replicación Bidireccional
Dado que ambos servidores pueden recibir actualizaciones simultáneas, la replicación bidireccional puede generar conflictos. PostgreSQL no resuelve automáticamente estos conflictos, por lo que es importante implementar una estrategia.
Simulando un Conflicto
Si insertamos un registro con el mismo id en ambos servidores:
– En el Servidor A:
INSERT INTO inventory (product_name, quantity) VALUES ('Gadget', 150);
– En el Servidor B:
INSERT INTO inventory (product_name, quantity) VALUES ('Gadget', 120);
Esto puede generar un conflicto al intentar replicar el mismo id en ambos servidores. En este caso, debemos decidir cuál de los dos servidores tiene prioridad, o fusionar los datos manualmente.
Soluciones posibles:
1. Uso de marcas de tiempo (last_updated): Añadir una columna last_updated en la tabla puede ayudar a decidir cuál de las dos entradas es más reciente.
ALTER TABLE inventory ADD COLUMN last_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP;
2. Deshabilitar la escritura en una de las bases de datos: Si uno de los servidores es solo de lectura, podemos limitar las operaciones de escritura solo a uno de los nodos.
Paso 5: Validar la Configuración de replicación bidireccional
1. Insertar un nuevo registro en el Servidor A:
INSERT INTO inventory (product_name, quantity) VALUES ('Gadget', 200);
2. Verificar que el Servidor B reciba los datos replicados:
SELECT * FROM inventory;
Deberías ver el registro insertado en el Servidor A también en el Servidor B después de unos momentos.
Paso 6: Resolución de Conflictos y Prueba de Failover
Para probar la recuperación ante fallos, puedes simular la caída de uno de los servidores y ver cómo la replicación sigue funcionando entre los dos nodos. Esto garantiza que, incluso si uno de los servidores falla, la replicación se mantendrá activa entre el nodo restante.
Simular la caída del Servidor A:
Apaga el Servidor A y realiza operaciones en el Servidor B.
Verificar la replicación cuando el Servidor A vuelva a estar disponible:
Después de reiniciar el Servidor A, los datos deberían sincronizarse sin intervención manual, garantizando la continuidad.
Consideraciones Finales
Aunque PostgreSQL 16 facilita la replicación bidireccional, sigue siendo importante gestionar los posibles conflictos de datos y tener en cuenta las limitaciones de rendimiento en entornos con alta carga de escritura. Asegúrate de contar con un sistema de monitoreo robusto para identificar posibles problemas de sincronización y gestionar los recursos adecuadamente.
Esperamos que os sea de utilidad y nos vemos en futuras entradas. Si prefieres que nos encarguemos nosotros, puedes contactarnos sin problema.
¿Aún no conoces Query Performance? Descubre cómo puede ayudarte en tu entorno Oracle. Más información en su página de LinkedIn.
Sígue a GPS en LinkedIn