Table of Contents

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 Registro anticipado. ( WAL. Envío. Esta solución permite que se implemente un servidor en espera utilizando 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 utiliza un servidor de base de datos en espera (esclavo de replicación). configurado para conectarse al servidor principal/maestro, que transmite los registros WAL. al modo de 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 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 una pequeña demora 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 causar la pérdida de datos.

Esta guía muestra cómo configurar un Postgresql 12. replicación de transmisión principal-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 los viejos segmentos WAL. 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: freestar.config.enabled_slots.push (LocationName: “tecmint_incontent”, slotId: “tecmint_incontent”) ;

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):

Servidor de base de datos maestro de Postgresql: 10.20.20.9 Servidor de base de datos en espera de Postgresql: 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 los parámetros de recovery.conf. a los parámetros de configuración normales de PostgreSQL, lo que hace que sea mucho más fácil configurar 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 de Postgres y configure las direcciones IP en las que el servidor maestro escuchará las conexiones de los clientes.

En este caso, usaremos * significando todos.

# 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 último y otros archivos relacionados.

Configurar direcciones IP en PostgreSQL Master

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 Crear usuario de replicación en Pgmaster

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 configurado para replicación como se muestra en la captura de pantalla.

replicador de replicación de host 10.20.20.8/24 md5 Configurar la autenticación de replicación

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 base para Bootstrap del 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/) y luego eliminar 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 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-especifica el host que es el servidor maestro.
• -D-especifica el directorio de datos.
• -U-especifica la conexión usuario.
• -P: habilita los informes de progreso.
• -v: habilita el modo detallado.
• -R: habilita la creación de la configuración de recuperación: Crea un standby.signal. y agregue la configuración de conexión a postgresql.auto.conf. en el directorio de datos.
• -X: se usa para incluir la escritura anticipada requerida archivos de registro (archivos WAL) en la copia de seguridad. Un valor de transmisión significa transmitir la WAL mientras se crea la copia de seguridad.
• -C: permite 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.9-D/var/lib/pgsql/12/data-U replicator-P-v-R-X stream-C-S pgstandby1 $ exit Copia de seguridad básica 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. Se crea una señal de espera. y la configuración de la conexión se agrega a postgresql.auto.conf. Puede listar su contenido usando el comando ls.

# ls-l/var/lib/pgsql/12/data/ Verificar el directorio de datos de respaldo

Un esclavo de replicación se ejecutará en el modo” Hot Standby. “si el hot_standby. El parámetro 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 llamado pgstandby1. cuando abre la vista pg_replication_slots. de la siguiente manera.

# su-postgres $ psql-c “SELECT * FROM pg_replication_slots;” $ salida Crear ranura de replicación

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 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 una conexión con éxito entre el maestro y el modo de espera, verá un proceso de receptor WAL. en el servidor de reserva con un estado de transmisión, puede verificar esto usando el Vista pg_stat_wal_receiver.

$ psql-c “\ x”-c “SELECCIONAR * FROM pg_stat_wal_receiver;” Verifique el proceso del receptor WAL

y el proceso del remitente WAL. correspondiente en el servidor maestro/primario 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;” Verifique el proceso del remitente WAL en el maestro

De 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 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; [en espera] postgres = # \ l

Prueba de replicación de transmisión

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

14.. La replicación sincrónica ofrece la capacidad de confirmar una transacción (o escribir datos) en la base de datos principal y en la réplica o en espera de forma simultánea. 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, el compromiso_sincrónico. también debe estar establecido en on (que es el valor predeterminado, por lo tanto, no es necesario 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 ‘*’;” Establecer nombres de espera de sincronización en maestro

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

# systemctl reload postgresql-12.service

16.. Ahora, cuando consulte el WAL. 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 “SELECCIONAR * DE pg_stat_replication;” Verificar WAL Proceso de remitente en maestro

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