PostgreSQL puede funcionar por separado en varias máquinas con la misma estructura de datos, lo que hace que la capa de persistencia de la aplicación sea más resistente y esté preparada para algún evento inesperado que pueda comprometer la continuidad del servicio.
La idea detrás de esto es mejorar el tiempo de respuesta del sistema al distribuir las solicitudes en una red "Round Robin" donde cada nodo presente es un clúster. En este tipo de configuración no importa a cuál se entregarán las solicitudes para ser procesadas, ya que la respuesta siempre sería la misma.
En este blog, explicaremos cómo replicar un clúster de PostgreSQL utilizando las herramientas proporcionadas en la instalación del programa. La versión utilizada es PostgreSQL 11.5, la versión actual estable y generalmente disponible para el sistema operativo Debian Buster. Para los ejemplos de este blog, se supone que ya está familiarizado con Linux.
Programas PostgreSQL
Dentro del directorio /usr/bin/ se encuentra el programa encargado de administrar el clúster.
# 1. Lists the files contained in the directory
# 2. Filters the elements that contain 'pg_' in the name
ls /usr/bin/ | grep pg_Las actividades realizadas a través de estos programas se pueden realizar secuencialmente o incluso en combinación con otros programas. Es posible ejecutar un bloque de estas actividades a través de un solo comando gracias a un programa de Linux que se encuentra en el mismo directorio, llamado make.
Para listar los clusters presentes use el programa pg_lsclusters. También puede usar make para ejecutarlo. Su trabajo depende de un archivo llamado Makefile, que debe estar en el mismo directorio donde se ejecutará el comando.
# 1. The current directory is checked
pwd
# 2. Creates a directory
mkdir ~/Documents/Severalnines/
# 3. Enroute to the chosen directory
cd ~/Documents/Severalnines/
# 4. Create the file Makefile
touch Makefile
# 5. Open the file for editingLa definición de un bloque se muestra a continuación, teniendo como nombre ls, y un único programa a ejecutar, pg_lsclusters.
# 1. Block name
ls:
# 2. Program to be executed
pg_lsclustersEl archivo Makefile puede contener varios bloques, y cada uno puede ejecutar tantos programas como necesite e incluso recibir parámetros. Es imperativo que las líneas pertenecientes a un bloque de ejecución sean correctas, utilizando tabulaciones para sangría en lugar de espacios.
El uso de make para ejecutar el programa pg_lsclusters se logra usando el comando make ls.
# 1. Executes pg_lsclusters
make lsEl resultado obtenido en una instalación reciente de PostgreSQL trae un solo clúster llamado main, ubicado en el puerto 5432 del sistema operativo. Cuando se utiliza el programa pg_createcluster, se asigna un nuevo puerto al nuevo clúster creado, teniendo como punto de partida el valor 5432, hasta encontrar otro en orden ascendente.
Registro de escritura anticipada (WAL)
Este procedimiento de replicación consiste en hacer una copia de seguridad de un clúster en funcionamiento que continúa recibiendo actualizaciones. Sin embargo, si esto se hace en la misma máquina, se pierden muchos de los beneficios que brinda esta técnica.
Escalar un sistema horizontalmente asegura una mayor disponibilidad del servicio, ya que si ocurriera algún problema de hardware, no haría mucha diferencia ya que hay otras máquinas listas para asumir la carga de trabajo.
WAL es el término utilizado para representar un algoritmo complejo interno de PostgreSQL que asegura la integridad de las transacciones que se realizan en el sistema. Sin embargo, solo un único clúster debe tener la responsabilidad de acceder a él con permiso de escritura.
La arquitectura ahora tiene tres tipos distintos de clústeres:
- Un primario con la responsabilidad de escribir a WAL;
- Una réplica lista para hacerse cargo del puesto principal;
- Otras réplicas diversas con servicio de lectura WAL.
Las operaciones de escritura son cualquier actividad que tiene como objetivo modificar la estructura de datos, ya sea ingresando nuevos elementos o actualizando y eliminando registros existentes.
Configuración del clúster de PostgreSQL
Cada clúster tiene dos directorios, uno que contiene sus archivos de configuración y otro con los registros de transacciones. Estos se encuentran en /etc/postgresql/11/$(cluster) y /var/lib/postgresql/11/$(cluster), respectivamente (donde $(cluster) es el nombre del clúster).
El archivo postgresql.conf se crea inmediatamente después de crear el clúster ejecutando el programa pg_createcluster, y las propiedades se pueden modificar para personalizar un clúster.
No se recomienda editar este archivo directamente porque contiene casi todas las propiedades. Sus valores han sido comentados, con el símbolo # al comienzo de cada línea, y varias otras líneas comentadas que contienen instrucciones para cambiar los valores de propiedad.
Es posible agregar otro archivo que contenga los cambios deseados, simplemente edite una sola propiedad llamada include, reemplazando el valor predeterminado #include =‘’ con include =‘postgresql.replication.conf’.
Antes de iniciar el clúster, necesita la presencia del archivo postgresql.replication.conf en el mismo directorio donde encuentra el archivo de configuración original, llamado postgresql.conf.
# 1. Block name
create:
# 2. Creates the cluster
pg_createcluster 11 $(cluster) -- --data-checksums
# 3. Copies the file to the directory
cp postgresql.replication.conf /etc/postgresql/11/$(cluster)/
# 4. A value is assigned to the property
sed -i "s|^#include = ''|include = 'postgresql.replication.conf'|g" /etc/postgresql/11/$(cluster)/postgresql.confEl uso de --data-checksums en la creación del clúster agrega un mayor nivel de integridad a los datos, lo que cuesta un poco de rendimiento pero es muy importante para evitar la corrupción de los archivos cuando transferido de un clúster a otro.
Los procedimientos descritos anteriormente se pueden reutilizar para otros clústeres, simplemente pasando un valor a $(cluster) como parámetro en la ejecución del programa make.
# 1. Executes the block 'create' by passing a parameter
sudo make create cluster=primaryAhora que se ha establecido una breve automatización de las tareas, lo que queda por hacer es la definición del archivo postgresql.replication.conf de acuerdo a la necesidad de cada clúster.
Replicación en PostgreSQL
Hay dos formas posibles de replicar un clúster, una es completa, la otra involucra a todo el clúster (llamada replicación de transmisión) y otra puede ser parcial o completa (llamada replicación lógica).
La configuración que se debe especificar para un clúster se divide en cuatro categorías principales:
- Servidor maestro
- Servidores en espera
- Servidores de envío
- Suscriptores
Como vimos anteriormente, WAL es un archivo que contiene las transacciones que se realizan en el clúster, y la replicación es la transmisión de estos archivos de un clúster a otro.
Dentro de la configuración presente en el archivo postgresql.conf, podemos ver propiedades que definen el comportamiento del clúster en relación con los archivos WAL, como el tamaño de esos archivos.
# default values
max_wal_size = 1GB
min_wal_size = 80MBOtra propiedad importante llamada max_wal_senders. Pertenecer a un clúster con Servidores de Envío característicos, es la cantidad de procesos encargados de enviar estos archivos a otros clústeres, debiendo siempre un valor superior al número de clústeres que dependen de su recepción.
Los archivos WAL se pueden almacenar para su transmisión a un clúster que se conecta tarde, o que ha tenido problemas para recibirlo, y necesita archivos anteriores en relación con la hora actual, teniendo como especificación la propiedad wal_keep_segments para cuántos segmentos de archivo WAL debe mantener un clúster.
Una ranura de replicación es una funcionalidad que permite que el clúster almacene los archivos WAL necesarios para proporcionar a otro clúster todos los registros, teniendo como propiedad la opción max_replication_slots.
# default values
max_wal_senders = 10
wal_keep_segments = 0
max_replication_slots = 10Cuando la intención es externalizar el almacenamiento de estos archivos WAL, se puede utilizar otro método de procesamiento de estos archivos, denominado archivado continuo.
Archivado continuo
Este concepto le permite dirigir los archivos WAL a una ubicación específica, utilizando un programa Linux y dos variables que representan la ruta del archivo y su nombre, como %p y %f, respectivamente.
Esta propiedad está deshabilitada de forma predeterminada, pero su uso se puede implementar fácilmente eliminando la responsabilidad de un clúster de almacenar archivos tan importantes y se puede agregar al archivo postgresql.replication.conf.
# 1. Creates a directory
mkdir ~/Documents/Severalnines/Archiving
# 2. Implementation on postgresql.replication.conf
archive_mode = on
archive_command = 'cp %p ~/Documents/Severalnines/Archiving/%f'
# 3. Starts the cluster
sudo systemctl start [email protected]Después de la inicialización del clúster, es posible que sea necesario modificar algunas propiedades y que sea necesario reiniciar el clúster. Sin embargo, algunas propiedades solo se pueden volver a cargar, sin necesidad de un reinicio completo de un clúster.
La información sobre estos temas se puede obtener a través de los comentarios presentes en el archivo postgresql.conf, que aparece como # (nota:el cambio requiere reiniciar).
Si este es el caso, una forma sencilla de solucionarlo es con el programa de Linux systemctl, utilizado anteriormente para iniciar el clúster, teniendo únicamente que anular la opción de reiniciar.
Cuando no se requiere un reinicio completo, el propio clúster puede reasignar sus propiedades a través de una consulta que se ejecuta dentro de sí mismo; sin embargo, si varios clústeres se ejecutan en la misma máquina, será necesario pasar un parámetro que contiene el valor del puerto que se asigna al clúster en el sistema operativo.
# Reload without restarting
sudo -H -u postgres psql -c ‘SELECT pg_reload_conf();’ -p 5433En el ejemplo anterior, la propiedad archive_mode requiere un reinicio, mientras que archive_command no. Después de esta breve introducción a este tema, veamos cómo un clúster de réplica puede hacer una copia de seguridad de estos archivos WAL archivados mediante la Recuperación a un momento dado (PITR).
Recuperación de un momento dado de la replicación de PostgreSQL
Este sugerente nombre permite que un clúster vuelva a su estado desde un cierto período de tiempo. Esto se hace a través de una propiedad llamada recovery_target_timeline, que espera recibir un valor en formato de fecha, como 2019-08-22 12:05 GMT, o la asignación más reciente, informando la necesidad de una recuperación hasta el último registro existente.
El programa pg_basebackup cuando se ejecuta, hace una copia de un directorio que contiene los datos de un clúster a otra ubicación. Este programa suele recibir múltiples parámetros, siendo uno de ellos -R, que crea un archivo llamado recovery.conf dentro del directorio copiado, que a su vez no es el mismo que contiene los otros archivos de configuración vistos anteriormente, como postgresql.conf .
El archivo recovery.conf almacena los parámetros pasados en la ejecución del programa pg_basebackup, y su existencia es fundamental para la implementación de Streaming Replication, pues es dentro de él donde se puede realizar la operación inversa al Archivado Continuo. realizarse.
# 1. Block name
replicate:
# 2. Removes the current data directory
rm -rf /var/lib/postgresql/11/$(replica)
# 3. Connects to primary cluster as user postgres
# 4. Copies the entire data directory
# 5. Creates the file recovery.conf
pg_basebackup -U postgres -d postgresql://localhost:$(primaryPort) -D /var/lib/postgresql/11/$(replica) -P -R
# 6. Inserts the restore_command property and its value
echo "restore_command = 'cp ~/Documents/Severalnines/Archiving/%f %p'" >> /var/lib/postgresql/11/$(replica)/recovery.conf
# 7. The same is done with recovery_target_timeline
echo "recovery_target_timeline = 'latest'" >> /var/lib/postgresql/11/$(replica)/recovery.confEste bloque de réplica especificado anteriormente debe ser ejecutado por el usuario de postgres del sistema operativo para evitar posibles conflictos con quién es el propietario de los datos del clúster, postgres o el usuario root.
El clúster de réplica aún está en pie, hilvanándolo para iniciar con éxito la replicación, haciendo que el proceso de clúster de réplica llamado pg_walreceiver interactúe con el clúster principal llamado pg_walsender a través de una conexión TCP.
# 1. Executes the block ‘replicate’ by passing two parameters
sudo -H -u postgres make replicate replica=replica primaryPort=5433
# 2. Starts the cluster replica
sudo systemctl start [email protected]La verificación del estado de este modelo de replicación, llamado Streaming Replication, se realiza mediante una consulta que se ejecuta en el clúster principal.
# 1. Checks the Streaming Replication created
sudo -H -u postgres psql -x -c ‘select * from pg_stat_replication;’ -p 5433Conclusión
En este blog, mostramos cómo configurar la replicación de transmisión asíncrona entre dos clústeres de PostgreSQL. Sin embargo, recuerde que existen vulnerabilidades en el código anterior, por ejemplo, no se recomienda usar el usuario de postgres para realizar dicha tarea.
La replicación de un clúster brinda varios beneficios cuando se utiliza de la manera correcta y tiene fácil acceso a las API que llegan a interactuar con los clústeres.
