Replicación Bases de Datos PostgreSQL modo: Streaming Replication

El presente instructivo tiene como finalidad mostrar los pasos básicos necesarios para la instalación y configuración de Replicación de Base de Datos en PostgreSQL modo: Streaming Replication (hot_standby).

Streaming Replication (SR) es una funcionalidad que permite transferir asincrónicamente(*) registros WAL sobre la marcha (record-based log shipping) entre un servidor maestro y uno/varios esclavos.

La replicación streaming de PostgreSQL es asíncrona por defecto. Si el maestro falla, algunas de las ransacciones realizadas, puede que no se hayan replicado a la copia standby, provocando una pérdida de datos. La cantidad de datos perdidos será proporcional al tiempo de retraso de la replicación durante el fallo.

En la práctica un proceso denominado receptor WAL (WAL receiver) es el servidor esclavo, se conecta mediante una conexión TCP/IP en el servidor maestro. En el servidor maestro existen otro proceso denominado remitente WAL (WAL Sender) que es el encargado de enviar los registros WAL sobre la marcha al servidor esclavo.

Los Archivos WAL (Write Ahead Log / REDO) son utilizados por postgreSQL para guardar toda la información sobre las transacciones y cambios realizados en la base de datos. Los archivos WAL se utilizan para garantizar la integridad de los datos grabados en la base de datos. También se utilizan para reparar automáticamente posibles inconsistencias en la base de de datos después de una caída súbita del servidor. Estos archivos tienen un nombre único y un tamaño por defecto de 16MB y se generan en el subdirectorio pg_xlog que se encuentra en el directorio de datos ($PGDATA). El número de ficheros WAL contenidos en pg_xlog dependerá del valor asignado al parámetro checkpoint_segments en el fichero de configuración postgresql.conf

(*) Replicación/transferencia asincrónica: Cuando los datos se transfieren de un sistema A a otro B, sin esperar por el “acuse de recibo” de B antes de hacer disponibles en A los datos replicados . En un sistema de replicación asincrónico puede existir un cierto retraso ó demora en la disponibilidad de los datos en el sistema esclavo. La replicación asíncrona evita los costes de la replicación síncrona, gracias a que se proporciona una respuesta al cliente antes de la coordinación entre copias

Para el presente instructivo se toma el siguiente escenario:
Se desea configurar dos servidores postgres postgreSQL01 (maestro) y postgreSQL02 (esclavo). El servidor master postgreSQL01 estará modo Lectura/Escritura (Read/writer) y el servidor slave postgreSQL02 estará modo sólo Lectura (Read).

Diagrama:

  .------.                 .--------.
  |      |          W      |   DB   |
  |Pgpool|----+----------->| MASTER |----.
  |      |    |            |        |    |
  `------`    |            `--------`    | STREAMING REPLICATION
              |            .--------.    |
              |     R      |   DB   |    |
              +----------->|  SLAVE |<---+      
                           |        |    
                           `--------` 

Requisitos:

  • Se debe contar con suficiente privilegios para la configuración de aplicativos
  • Se debe contar con instalación de postgresql 9.4 (probado en 9.5 y 9.6) en servidor maestro y esclavo

Plataforma:

  • Equipos de arquitectura 64 bits
  • Sistema operativo ‘GNU/Linux’ Debian versión 8.0 (probado en debian 9.0)

Importante: Al inciar la configuración, el servicio del PostgreSQL del servidor “esclavo” debe estar “detenido”

-EN AMBOS SERVIDORES:

Configurar resolución local de DNS:

# vim /etc/hosts

Efectuar el cambio: (master)

127.0.0.1	localhost
127.0.1.1	postgreSQL01
192.168.0.2	postgreSQL01
192.168.0.3	postgreSQL02

Efectuar el cambio: (esclavo)

127.0.0.1	localhost
127.0.1.1	postgreSQL02
192.168.0.3	postgreSQL02
192.168.0.2	postgreSQL01


SERVIDOR MAESTRO:

 1. Editar archivo de configuración de postgres:
root@postgreSQL01:/# vim /etc/postgresql/9.4/main/postgresql.conf

Efectuar los siguientes cambios:

listen_addresses = '*'
port = 5432
wal_level = hot_standby
archive_mode = on
archive_command = 'cp -i "%p" /opt/archive/"%f" </dev/null'
max_wal_senders = 5
wal_keep_segments = 30

Donde:

  • wal_level = hot_standby -> Define cuanta información se grabará en los archivos WAL generados
  • archive_mode = on -> Se activa la generación de archivos WAL en el servidor
  • (*)archive_command -> Comando que se ejecute cada vez que haya un nuevo archivo WAL listo para ser enviado. Si la opción "wal_keep_segments" contiene un número que permite retener los WAL enviados al servidor esclavo, la opción archive_command no es necesaria. En éste caso hace una copia de los WAL hacia la carpeta '/opt/archive'
  • max_wal_senders = 1 -> Indica las conexiones concurrentes o simultáneas desde los servidores "esclavos"
  • wal_keep_segments = 30 -> Especifica el número máximo de archivos WAL que serán retenidos en el directorio pg_xlog en caso de retrasarse el proceso "Streaming replication"

NOTA:

  • Los parámetros hot_standby y max_standby_archive_delay son ignorados por el servidor maestro
  • (*)Básicamente, una vez la opción de "archive_mode = on" se activa, PostgreSQL se convierte en el responsable de que para cada archivo WAL que se genera, el programa "archive_command" se ejecute con éxito, intentandolo de forma indefinida en caso de error (espacio en disco lo permite)

2. Crear carpeta archive: (Esto en caso de configurar el archive_command para copia de WAL)

root@postgreSQL01:/# mkdir -p /opt/archive

3. Cambiar el dueño de la carpeta: (Esto en caso de configurar el archive_command para copia de WAL)

root@postgreSQL01:/# chown postgres:postgres /opt/archive

NOTA: Es ventajoso si el directorio que contiene los registros WAL "/var/lib/postgresql/9.x/main/pg_xlog" se encuentra en un disco (o volumen) diferente de los principales archivos de bases de datos. Esto puede lograrse moviendo el directorio pg_xlog a otra ubicación (mientras el servidor está apagado) y crear un enlace simbólico desde la ubicación original en el directorio principal de datos a la nueva ubicación.

4. Crear carpeta para WAL:

root@postgreSQL01:/# mkdir -p /opt/WAL

5. Mover el contenido de la carpeta pg_xlog a la nueva carpeta creada:

root@postgreSQL01:/# mv /var/lib/postgresql/9.x/main/pg_xlog /opt/WAL

6. Cambiar el dueño de la carpeta:

root@postgreSQL01:/# chown postgres:postgres -R /opt/WAL

7. Efectuar enlace simbólico:

root@postgreSQL01:/# ln -s /opt/WAL/pg_xlog/ /var/lib/postgresql/9.x/main/pg_xlog

8. Ajustar los permisos de acceso para usuario replicar, editar archivo de configuración de conexión:

root@postgreSQL01:/# vim /etc/postgresql/9.4/main/pg_hba.conf

Efectuar los siguientes cambios:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    replication     replicar        IP_address_of_slave/32    md5
host    replication     replicar        IP_address_of_master/32   md5

9. Iniciar servicio PostgreSQL

root@postgreSQL01:/# /etc/init.d/postgresql restart

10. Crear usuario "replicar" con roles de "replication":

root@postgreSQL01:/# psql -Upostgres -h127.0.0.1 -p5432 -c "CREATE USER replicar REPLICATION LOGIN CONNECTION LIMIT 1 ENCRYPTED PASSWORD 'CONTRASEÑA';"

Respaldar base de datos origen:
NOTA: Se requiere tener instalado rsync y un usuario valido en servidor esclavo para transmitir la información

11. Inciar modo backup en postgresql:

root@postgreSQL01:/# psql -Upostgres -h127.0.0.1 -p5432 -c "select pg_start_backup('initial_backup');"

12. Efectuar copia de la información desde el servidor "maestro" al servidor "esclavo":

root@postgreSQL01:/# rsync -cva --inplace --exclude=*pg_xlog* postmaster.pid /var/lib/postgresql/9.4/main/ IP_servidor_esclavo:/var/lib/postgresql/9.4/main/

Nota: El postgresql del servidor esclavo debe estar detenido

donde:

  • -cva -> -c(--checksum), -v(--verbose), -a(--archive)
  • --inplace -> rsync escribe los datos actualizados directamente en el archivo de destino
  • --exclude -> archivos a "excluir" en la copia de la información
  • ruta_cluster_servidor_master -> Por defecto Debian: "/var/lib/postgresql/9.4/main/"
  • IP_servidor_esclavo -> dirección IP del servidor "esclavo"
  • ruta_cluster_servidor_esclavo -> Por defecto Debian: "/var/lib/postgresql/9.4/main/"

13. Detener modo backup postgresql servidor maestro:

root@postgreSQL01:/# psql -Upostgres -h127.0.0.1 -p5432 -c "select pg_stop_backup();"

SERVIDOR ESCLAVO:
14. El servicio de postgresql debe estar apagado:

root@postgreSQL02:/# /etc/init.d/postgresql stop

15. Editar archivo de configuración de conexión:

root@postgreSQL02:/# vim /etc/postgresql/9.4/main/pg_hba.conf

Efectuar los siguientes cambios:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    replication     replicar      IP_address_of_master/32    md5
host    replication     replicar      IP_address_of_slave/32     md5

16. Editar archivo de configuración:

root@postgreSQL02:/# vim /etc/postgresql/9.4/main/postgresql.conf

17. Efectuar los siguientes cambios:

listen_addresses = '*'
port = 5432
hot_standby = on

Donde:

  • hot_standby = on -> especifica si el servidor tiene la habilidad de ejecutar transacciones de solo lectura mientras se encuentre en modo standby (Read Only)

Nota: El parámetro "wal_level" es ignorados por el servidor esclavo

18. Crear archivo recovery:

root@postgreSQL02:/# vim /var/lib/postgresql/9.4/main/recovery.conf

Incluir la siguiente información:

standby_mode = 'on'
primary_conninfo = 'host=IP_SERVIDOR_MAESTRO port=5432 user=replicar password=yourpassword'
trigger_file = '/tmp/trigger_failover'
restore_command = 'cp /opt/archive/%f "%p"'
archive_cleanup_command = 'pg_archivecleanup -d /opt/archive %r 2>>/var/log/postgresql/cleanup.log'

Donde:

  • standby_mode -> Activar el modo standby
  • primary_conninfo -> Cadena de conexión desde el servidor esclavo hacia el servidor maestro
  • trigger_failover -> Especifica un archivo "desencadenante", que en caso de crearse/existir, podrá fin a la replicación, sacará al servidor esclavo del modo "hot standby" y de recuperación continua. Esto en caso de falla del master y promover el servidor esclavo como master
  • (*)restore_command -> Comando shell para copiar un segmento almacenado de la serie de archivos WAL
  • (**)archive_cleanup_command -> Comando de shell que se ejecutará en cada restart point

NOTA:

  • (*)La magia que hace que los dos servidores trabajan en conjunto es simplemente una restore_command utilizado en el servidor "Esclavo". El restore_command se especifica en el recovery.conf archivo en el servidor de "esclavo".
  • (**)"archive_cleanup_command" permite la limpieza de viejos archivos comprimidos WAL que ya no son necesarios por el servidor esclavo

19. Cambiar el dueño de la carpeta recovery.conf:

root@postgreSQL02:/# chown postgres:postgres /var/lib/postgresql/9.4/main/recovery.conf

20. Crear carpeta archive:

root@postgreSQL02:/# mkdir -p /opt/archive

21. Cambiar el dueño de la carpeta creada:

root@postgreSQL02:/# chown postgres:postgres /opt/archive

22. Reiniciar el Servicio:

root@postgreSQL02:/# /etc/init.d/postgres start

Comprobar Replicación:

23. Comprobar la transmisión de la replicación: (servidor Maestro)

root@postgreSQL01:/# psql -Upostgres -h127.0.0.1 -p5432 -c "SELECT * FROM pg_stat_replication;"

Nota: Esta información sólo se puede leer en el maestro. Si intenta que en el esclavo (hot_standby = on), no consigue ver nada.

24. Comprobar el modo de replicación:

root@postgreSQL01:/# psql -Upostgres -c "SELECT sync_state FROM pg_stat_replication;"

25. Comprobar la ubicación del último registro de transacciones que fue transmitido por el esclavo y también se escribe en el servidor esclavo: (servidor Esclavo)

root@postgreSQL02:/# psql -Upostgres -h127.0.0.1 -p5432 -c "SELECT pg_last_xlog_receive_location ();"

IMPORTANTE
Tarea de administración y mantenimiento:

Una vez que todo está funcionando, se tendrá que mantener el sistema y administrarlo en caso de fallo en el servidor maestro. Las tareas que se tienen que implementar/realizar serán:

  • Limpiar el directorio donde se archivan los WAL en el servidor maestro, borrando los archivos de WAL antiguos que no se necesiten:
    root@postgreSQL01:/# /usr/lib/postgresql/9.4/bin/pg_archivecleanup -d /opt/archive 000000010000000000000001
  • Limpiar el directorio a donde se transfieren los archivos WAL en el servidor esclavo, borrando los archivos de WAL antiguos que no se necesiten
  • Activar automáticamente el servidor esclavo como nuevo servidor maestro en caso de fallo del servidor maestro en uso:
    root@postgreSQL01:/# touch /tmp/trigger_failover
  • Monitorizar el estado de la replicación para saber el retraso del servidor esclavo en relación al maestro

Enlace:
Replicación en PostgreSQL (II) – Hot Standby/Streaming Replication
Streaming Replication Postgresql
Hot_Standby Postgresql
HA PostgreSQL Cluster by Streaming Replication + pgpool-II
How To Set Up Master Slave Replication on PostgreSQL on an Ubuntu 12.04 VPS
Replicación y Alta Disponibilidad en PostgreSQL
Instalación de PostgreSQL – Parte 4 – Configuración de la replicación
Configuring EDB Postgres Advanced Server Streaming Replication
hot-standby-y-streaming-replication
18.6. Replicación
Tip: Here's how to resolve the problem of the pg_wal location (once known as pg_xlog) running out of disk space in PostgreSQL 10

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

w

Conectando a %s