Replicación

Replicación en flujo

La replicación integrada en PostgreSQL, llamada «Streaming Replication», se basa en los mecanismos de copia de seguridad y restauración para poner en marcha una o varias instancias llamadas «standby», de una instancia principal de PostgreSQL. 

Los procedimientos de copia de seguridad físicas integradas se basan en los archivos de traza de transacciones y, lógicamente, la replicación de los datos consiste en recrear de manera continua en las instancias «standby» el contenido de estos archivos de traza de transacciones.

Las primeras técnicas de replicación consistían en volver a leer los archivos de traza de transacciones archivados como resultado del argumento archive_command. Esta técnica siempre ha existido y se puede utilizar para permitir una mayor flexibilidad de la topología de los nodos PostgreSQL.

Con las versiones 9 de PostgreSQL, apareció el protocolo de replicación integrado, que permite a una instancia conectarse a otra instancia para leer de manera continuada el contenido de los archivos de traza de transacciones.

Esta técnica de replicación se puede utilizar en cascada, es decir, que cada uno de los servidores «standby» puede servir de fuente de replicación para otro servidor «standby», limitando de esta manera el peso de los servidores «standby» en el servidor principal.

Replicación síncrona

Por defecto, la replicación integrada es asíncrona, es decir, que la transacción en el servidor «primary» se valida antes de ser replicada. Es posible configurar la replicación en modo síncrono para replicar los datos antes de validar la transacción. Por defecto, los datos se replican, pero no son visibles inmediatamente en la instancia «standby». Desde de la versión 9.6 de PostgreSQL, es posible configurar la replicación para que sea síncrona hasta la visibilidad de los datos en la instancia «standby».

Una instancia «standby» se debe declarar en la directiva synchronous_standby_names de la instancia «primary». Esta directiva puede contener una lista de nombres separados por comas o combinaciones con los operadores FIRST o ANY, como se ha explicado en el capítulo Explotación. Cada instancia «standby» se identifica utilizando el argumento application_name de la cadena de conexión primary_conninfo del archivo recovery.conf.

Una vez arrancada la instancia «standby» para tener en cuenta esta configuración, es necesario verificar el estado de la columna sync_state de la vista pg_stat_replication para la conexión deseada, que debe tener el valor sync, y no async.

Además de esta configuración inicial, es posible ajustar de manera más fina...

Replicación lógica integrada

Desde la versión 10 de PostgreSQL, es posible implementar una replicación lógica sin herramienta adicional, es decir, sin utilizar Slony o Londiste. Esta funcionalidad se basa en los archivos de traza de transacciones enriquecidos y decodificados por las funciones de decodificación lógica de PostgreSQL. En los casos de la replicación lógica, independientemente de la técnica, se habla de «provider» para designar la instancia que ofrece el dato y de «subscriber» para la instancia que lo recibe.

Para permitir esta replicación, es necesario modificar el valor de la directiva de configuración wal_level a logical, en lugar de replica por defecto. Esta modificación hace necesario un rearranque de la instancia.

Una vez que se aplica esta modificación y el archivo pg_hba.conf se adapta para aceptar las conexiones, las siguientes sentencias CREATE PUBLICATION y CREATE SUBSCRIPTION permiten establecer un juego de tablas para replicar, después de abonarse a ellas desde otra instancia.

La siguiente sentencia permite crear la publicación en la instancia donde los datos de las tablas se modifican:

CREATE PUBLICATION clientes_repli FOR TABLE public.clientes,  
public.facturas, public.prestaciones; 

Luego, desde la instancia donde los datos se deben leer, indicando la conexión a la instancia «provider»:...

Replicación lógica con Slony

La herramienta Slony-I es un sistema de replicación lógica asíncrona maestro-esclavo. Permite replicar datos entre varios servidores PostgreSQL, sabiendo que solo uno de estos servidores será el servidor maestro, y el resto, los servidores esclavos. Estos servidores esclavo se pueden poner en cascada, pero la cantidad de servidores esclavos debe permanecer razonable para no tener impacto negativo en el rendimiento.

El servidor maestro es el que debe utilizar las aplicaciones para todas las modificaciones de datos. Los servidores esclavos reciben una copia de estas modificaciones de manera asíncrona. Esta replicación asíncrona implica que el servidor maestro no espera la validación de los servidores esclavos para validar su propia transacción a la aplicación cliente. La validación de una transacción en el servidor maestro solo tiene en cuenta el estado del servidor maestro, y no el de los servidores esclavos.

La replicación se puede realizar en una red local o en las redes extendidas (WAN). Esto se debe al hecho de que Slony utiliza conexiones TCP entre los servidores.

Las diferentes posibilidades de Slony son:

La unidad de replicación de Slony es la tabla. En un mismo grupo de servidores, Slony-I copia los datos de una tabla utilizando los triggers ubicados en estas tablas durante la inicialización de Slony. Es posible usar varias tablas, con la condición de que todas existan dentro de la misma base de datos.

Además, cada tabla debe tener una clave primaria; si el modelo de datos no define una clave primaria sobre una tabla, Slony-I puede añadir una columna para esto.