Cómo configurar la replicación de transmisión de PostgreSQL 12 en CentOS 8

La base de datos PostgreSQL admite varias soluciones de replicación para crear aplicaciones de alta disponibilidad, escalables y tolerantes a fallos, una de las cuales es el registro de escritura anticipada (WAL ) Envío. Esta solución permite implementar un servidor en espera mediante el envío de registros basado en archivos o la replicación de transmisión o, cuando sea posible, una combinación de ambos enfoques.

Con la replicación por streaming, se configura un servidor de base de datos en espera (esclavo de replicación) para conectarse al servidor maestro/primario, que transmite registros WAL al servidor en espera a medida que se generan, sin esperar a que el WAL archivo a completar.

De forma predeterminada, la replicación de transmisión es asíncrona y los datos se escriben en los servidores en espera después de que se haya confirmado una transacción en el servidor principal. Esto significa que hay un pequeño retraso entre la confirmación de una transacción en el servidor maestro y los cambios que se hacen visibles en el servidor en espera. Una desventaja de este enfoque es que, en caso de que el servidor maestro falle, es posible que las transacciones no confirmadas no se repliquen y esto puede provocar la pérdida de datos.

Esta guía muestra cómo configurar una replicación de transmisión maestro-en espera de Postgresql 12 en CentOS 8. Usaremos “ranuras de replicación” para el modo de espera como solución para evitar que el servidor maestro recicle segmentos WAL antiguos antes de que el modo de espera los haya recibido.

Tenga en cuenta que, en comparación con otros métodos, las ranuras de replicación retienen solo la cantidad de segmentos que se sabe que son necesarios.

Entorno de prueba:

Esta guía asume que usted se conectó a sus servidores de base de datos maestro y en espera como raíz a través de SSH (use el comando Sudo cuando sea necesario si está conectado como un usuario normal con derechos administrativos):

Postgresql master database server: 		10.20.20.9
Postgresql standby database server:		10.20.20.8

Ambos servidores de bases de datos deben tener instalado Postgresql 12; de lo contrario, consulte: Cómo instalar PostgreSQL y pgAdmin en CentOS 8.

Nota: PostgreSQL 12 viene con cambios importantes en la implementación y configuración de replicación, como el reemplazo de recovery.conf y la conversión de los parámetros recovery.conf a parámetros de configuración normales de PostgreSQL, lo que facilita mucho la configuración de la replicación del clúster.

Paso 1: Configurar el servidor de base de datos principal/maestro de PostgreSQL

1. En el servidor maestro, cambie a la cuenta del sistema postgres y configure las direcciones IP en las que el servidor maestro escuchará las conexiones de los clientes.

En este caso, usaremos * es decir, todo.

su - postgres
psql -c "ALTER SYSTEM SET listen_addresses TO '*';"

El comando SQL ALTER SYSTEM SET es una característica poderosa para cambiar los parámetros de configuración de un servidor, directamente con una consulta SQL. Las configuraciones se guardan en el archivo postgresql.conf.auto ubicado en la raíz de la carpeta de datos (por ejemplo, /var/lib/pgsql/12/data/) y se leen además. a los almacenados en postgresql.conf. Pero las configuraciones del primero tienen prioridad sobre las del segundo y otros archivos relacionados.

2. Luego cree una función de replicación que se usará para las conexiones desde el servidor en espera al servidor maestro, usando el programa createuser. En el siguiente comando, el indicador -P solicita una contraseña para el nuevo rol y -e repite los comandos que createuser genera y envía al servidor de la base de datos.

su – postgres
createuser --replication -P -e replicator
exit

3. Luego ingrese la siguiente entrada al final del archivo de configuración de autenticación del cliente /var/lib/pgsql/12/data/pg_hba.conf con el campo de la base de datos establecido en replicación como se muestra en la captura de pantalla.

host    replication     replicator      10.20.20.8/24     md5

4. Ahora reinicie el servicio Postgres12 usando el siguiente comando systemctl para aplicar los cambios.

systemctl restart postgresql-12.service

5. A continuación, si tiene el servicio firewalld ejecutándose, debe agregar el servicio Postgresql en la configuración del firewalld para permitir solicitudes desde el servidor en espera al maestro.

firewall-cmd --add-service=postgresql --permanent
firewall-cmd --reload

Paso 2: hacer una copia de seguridad básica para iniciar el servidor en espera

6. A continuación, debe realizar una copia de seguridad básica del servidor maestro desde el servidor en espera; esto ayuda a iniciar el servidor en espera. Debe detener el servicio postgresql 12 en el servidor en espera, cambiar a la cuenta de usuario de postgres, hacer una copia de seguridad del directorio de datos (/var/lib/pgsql/12/data/) y luego eliminar todo lo que hay debajo. como se muestra, antes de realizar la copia de seguridad de la base.

systemctl stop postgresql-12.service
su - postgres
cp -R /var/lib/pgsql/12/data /var/lib/pgsql/12/data_orig
rm -rf /var/lib/pgsql/12/data/*

7. Luego use la herramienta pg_basebackup para realizar la copia de seguridad base con el propietario correcto (el usuario del sistema de base de datos, es decir, Postgres, dentro del cuenta de usuario de Postgres) y con los permisos adecuados.

En el siguiente comando, la opción:

• -h: especifica el host que es el servidor maestro.
• -D: especifica el directorio de datos.
• -U – especifica el usuario de la conexión.
• -P: habilita informes de progreso.
• -v: habilita el modo detallado.
• -R: permite la creación de una configuración de recuperación: crea un archivo standby.signal y agrega la configuración de conexión a postgresql.auto.conf debajo de los datos. directorio.
• -X: se utiliza para incluir los archivos de registro de escritura anticipada necesarios (archivos WAL) en la copia de seguridad. Un valor de flujo significa transmitir el WAL mientras se crea la copia de seguridad.
• -C: habilita la creación de una ranura de replicación denominada por la opción -S antes de iniciar la copia de seguridad.
• -S: especifica el nombre de la ranura de replicación.

pg_basebackup -h 10.20.20.9 -D /var/lib/pgsql/12/data -U replicator -P -v  -R -X stream -C -S pgstandby1
exit

8. Cuando finalice el proceso de copia de seguridad, el nuevo directorio de datos en el servidor en espera debería verse así en la captura de pantalla. Se crea una standby.signal y la configuración de conexión se agrega a postgresql.auto.conf. Puede enumerar su contenido usando el comando ls.

ls -l /var/lib/pgsql/12/data/

Un esclavo de replicación se ejecutará en modo “Hot Standby” si el parámetro hot_standby está activado (el valor predeterminado) en postgresql.conf y hay un archivo standby.signal presente en el directorio de datos.

su - postgres
psql -c "SELECT * FROM pg_replication_slots;"
exit

cat /var/lib/pgsql/12/data/postgresql.auto.conf

systemctl start postgresql-12

psql -c "\x" -c "SELECT * FROM pg_stat_wal_receiver;"

psql -c "\x" -c "SELECT * FROM pg_stat_replication;"

psql -c "ALTER SYSTEM SET synchronous_standby_names TO  '*';"

systemctl reload postgresql-12.service

16. Ahora, cuando consultes el proceso del remitente WAL en el servidor principal una vez más, debería mostrar un estado de transmisión y un sync_state de < fuerte>sincronización.

psql -c "\x" -c "SELECT * FROM pg_stat_replication;"

Hemos llegado al final de esta guía. Hemos mostrado cómo configurar la replicación de transmisión de bases de datos maestro-en espera de PostgreSQL 12 en CentOS 8. También cubrimos cómo habilitar la replicación sincrónica en un clúster de base de datos PostgreSQL.

Hay muchos usos de la replicación y siempre puede elegir una solución que cumpla con su entorno de TI y/o los requisitos específicos de la aplicación. Para obtener más detalles, vaya a Servidores en espera de envío de registros en la documentación de PostgreSQL 12.