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 fallas, una de las cuales es el envío de registros de escritura anticipada (WAL). Esta solución permite que se implemente un servidor en espera mediante el trasvase 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 principal/maestro, que transmite los registros WAL al modo en espera a medida que se generan, sin esperar a que se complete el archivo WAL.

De forma predeterminada, la replicación de transmisión es asincrónica 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 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 streaming maestro-en espera Postgresql 12 en CentOS 8. Usaremos “ranuras de replicación” para el modo en espera como una solución para evitar que el servidor maestro recicle los viejos segmentos WAL antes de que el modo en espera los haya recibido.

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

Esta guía asume que está conectado a sus servidores de base de datos principal 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 incluye cambios importantes en la implementación y configuración de la replicación, como el reemplazo de recovery.conf y la conversión de los parámetros de recovery.conf a los parámetros de configuración normales de PostgreSQL, lo que facilita mucho la configuración de la replicación del clúster.

Paso 1: Configuración del 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 * que significa todo.

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

El comando ALTER SYSTEM SET 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 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 de los almacenados en postgresql.conf. Pero las configuraciones de la primera tienen prioridad sobre las de la última y otros archivos relacionados.

2. A continuación, cree una función de replicación que se utilizará para las conexiones desde el servidor en espera al servidor maestro, utilizando 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 de cliente /var/lib/pgsql/12/data/pg_hba.conf con el campo de la base de datos configurado para 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 en ejecución, debe agregar el servicio Postgresql en la configuración de 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 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 eliminar todo lo que se encuentra debajo como se muestra, antes de tomar la base apoyo.

# 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 la propiedad correcta (el usuario del sistema de base de datos, es decir, Postgres, dentro de la cuenta de usuario de Postgres) y con los permisos adecuados.

En el siguiente comando, la opción:

  • -h – specifies the host which is the master server.
  • -D – specifies the data directory.
  • -U – specifies the connection user.
  • -P – enables progress reporting.
  • -v – enables verbose mode.
  • -R – enables the creation of recovery configuration: Creates a standby.signal file and append connection settings to postgresql.auto.conf under the data directory.
  • -X – used to include the required write-ahead log files (WAL files) in the backup. A value of stream means to stream the WAL while the backup is created.
  • -C – enables the creation of a replication slot named by the -S option before starting the backup.
  • -S – specifies the replication slot name.
$ 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 señal de espera 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/

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.

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

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

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

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

11. Ahora comience las operaciones normales de la base de datos en el servidor de reserva 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 una conexión con éxito entre el maestro y el standby, verá un proceso de receptor WAL en el servidor standby con un estado de transmisión, puede verificar esto usando la vista pg_stat_wal_receiver.

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

y un proceso de remitente WAL correspondiente en el servidor principal/maestro con un estado de transmisión y un sync_state de async, puede verificar esta vista pg_stat_replication pg_stat_replication.

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

En la captura de pantalla anterior, la replicación de transmisión es asincrónica. En la siguiente sección, demostraremos cómo habilitar opcionalmente la replicación sincrónica.

[en espera] postgres u003d # \ l

Opcional: Habilitación de la replicación sincrónica

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/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 síncronos.

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

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

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

# systemctl reload postgresql-12.service

16. Ahora, cuando vuelva a consultar el proceso del remitente WAL en el servidor principal, debería mostrar un estado de transmisión y un estado de sincronización de 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 la base de datos principal-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 de PostgreSQL.

Hay muchos usos de la replicación y siempre puede elegir una solución que se adapte a su entorno de TI y/o requisitos específicos de la aplicación. Para obtener más detalles, vaya a Log-Shipping Standby Servers en la documentación de PostgreSQL 12.