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

PostgreSQL La base de datos admite varias soluciones de replicación para crear aplicaciones de alta disponibilidad, escalables y tolerantes a fallas, una de las cuales es 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 de transmisión, se configura un servidor de base de datos en espera (esclavo de replicación) para conectarse al servidor maestro/principal, que transmite WAL registros al modo de espera a medida que se generan, sin esperar el WAL archivo a llenar.

De forma predeterminada, la replicación de transmisión es asíncrona, donde 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 de reserva. 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 un Postgresql 12 replicación de transmisión maestra en espera en CentOS 8 . Usaremos “ranuras de replicación ” para el modo de espera como una solución para evitar que el servidor maestro recicle WAL antiguos segmentos antes de que el standby los haya recibido.

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

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 (usa Sudo comando 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 base de datos deben tener Postgresql 12 instalado, 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 la replicación, como el reemplazo de recovery.conf y la conversión de recovery.conf parámetros a los parámetros de configuración normales de PostgreSQL, lo que facilita mucho la configuración de la replicación de clústeres.

Paso 1:Configuración del servidor de base de datos maestro/principal 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 CONJUNTO ALTER SYSTEM El comando SQL 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 postgresql.conf.auto archivo ubicado en la raíz de la carpeta de datos (por ejemplo, /var/lib/pgsql/12/data/ ) y leer además de los almacenados en postgresql.conf . Pero las configuraciones en el primero tienen prioridad sobre las del último y otros archivos relacionados.

Configurar direcciones IP en PostgreSQL Master

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

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

Crear usuario de replicación en Pgmaster

3. Luego ingrese la siguiente entrada al final de /var/lib/pgsql/12/data/pg_hba.conf archivo de configuración de autenticación del cliente 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

Configurar autenticación de replicación

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

# systemctl restart postgresql-12.service

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

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

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

6. A continuación, debe realizar una copia de seguridad base del servidor maestro desde el servidor en espera; esto ayuda a arrancar 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/ ), luego elimine todo lo que hay debajo como se muestra, antes de realizar la copia de seguridad 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 el pg_basebackup herramienta para tomar la copia de seguridad base con la propiedad correcta (el usuario del sistema de base de datos, es decir, Postgres , dentro de Postgres cuenta de usuario) 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 – activa los informes de progreso.
• -v – habilita el modo detallado.
• -R – habilita la creación de la configuración de recuperación:Crea una standby.signal archivar y agregar configuraciones de conexión a postgresql.auto.conf en el directorio de datos.
• -X – se utiliza para incluir los archivos de registro de escritura anticipada necesarios (archivos WAL) en la copia de seguridad. Un valor de stream significa transmitir el WAL mientras se crea la copia de seguridad.
• -C – habilita la creación de una ranura de replicación nombrada 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.5 -D /var/lib/pgsql/12/data -U replicator -P -v  -R -X stream -C -S pgstandby1
$ exit

Copia de seguridad base del servidor maestro

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. Una señal.de.espera se crea y la configuración de conexión se agrega a postgresql.auto.conf . Puede listar su contenido usando el comando ls.

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

Verificar directorio de datos de copia de seguridad

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

9. Ahora, de vuelta en el servidor maestro, debería poder ver la ranura de replicación llamada pgstandby1 cuando abres pg_replication_slots ver de la siguiente manera.

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

Crear ranura de replicación

10. Para ver la configuración de conexión adjunta en postgresql.auto.conf archivo, use el comando cat.

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

Ver configuración de conexión

11. Ahora comience las operaciones normales de la base de datos en el servidor en espera iniciando el servicio PostgreSQL de la siguiente manera.

# systemctl start postgresql-12

Paso 3:probar la replicación de transmisión de PostgreSQL

12. Una vez que se establezca correctamente una conexión entre el maestro y el standby, verá un WAL proceso del receptor en el servidor en espera con un estado de transmisión, puede verificar esto usando el pg_stat_wal_receiver ver.

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

Comprobar el proceso del receptor WAL

y un WAL correspondiente proceso del remitente en el servidor maestro/principal con un estado de transmisión y un sync_state de asíncrono, puede consultar esta vista pg_stat_replication pg_stat_replication.

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

Comprobar el proceso del remitente WAL en maestro

De la captura de pantalla anterior, la replicación de transmisión es asíncrona. En la siguiente sección, demostraremos cómo habilitar opcionalmente la replicación síncrona.

13. Ahora pruebe si la replicación funciona bien creando una base de datos de prueba en el servidor maestro y verifique si existe en el servidor en espera.
[maestro]postgres=# CREAR BASE DE DATOS tecmint;
[espera]postgres=# \l

Probar replicación de transmisión

Opcional:habilitar la replicación síncrona

14. La replicación síncrona ofrece la capacidad de confirmar una transacción (o escribir datos) en la base de datos principal y en la réplica/en espera simultáneamente. Solo confirma que una transacción es exitosa cuando todos los cambios realizados por la transacción se han transferido a uno o más servidores en espera sincrónicos.

Para habilitar la replicación síncrona, synchronous_commit también debe estar activado (que es el valor predeterminado, por lo que no es necesario realizar ningún cambio) y también debe configurar synchronous_standby_names parámetro a un valor no vacío. Para esta guía, lo configuraremos para todos.

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

Establecer sincronización de nombres en espera en maestro

15. Luego, vuelva a cargar el servicio PostgreSQL 12 para aplicar los nuevos cambios.

# systemctl reload postgresql-12.service

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

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

Comprobar el proceso de remitente WAL en maestro

Hemos llegado al final de esta guía. Hemos mostrado cómo configurar PostgreSQL 12 replicación de transmisión de base de datos master-standby en CentOS 8 . También cubrimos cómo habilitar la replicación síncrona en un clúster de base de datos de 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.

Compartir es cuidar…
Compartir en FacebookCompartir en TwitterCompartir en LinkedinCompartir en Reddit