PDF de programación - Mecanismos de Replicación y Alta Disponibidad en PostgreSQL

Mecanismos de Replicación
y Alta Disponibidad en PostgreSQL
Álvaro Hernández Tortosa <[email protected]>



Acerca de mí

● Álvaro Hernández Tortosa <[email protected]>
● Fundador y Director Técnico en NOSYS
● ¿Qué hacemos en NOSYS?

✔ Formación, consultoría y desarrollo de software con
PostgreSQL (y Java)
✔ Partners de EnterpriseDB
✔ Formación avanzada en Java con
Javaspecialists.eu: Java Master Course y Java
Concurrency Course
✔ Partners de Amazon AWS. Formación y consultoría
en AWS

● Twitter: @ahachete


● LinkedIn: http://es.linkedin.com/in/alvarohernandeztortosa/

Conceptos básicos

● Disponibilidad: que un sistema esté accesible, esto es,
que se pueda conectar a él y operar con normalidad.

● Alta disponibilidad: sistema indisponible un porcentaje
muy bajo del tiempo (típicamente < 0,05%). Casi siempre
requiere que no haya SPOFs.

● Clustering: que un conjunto de máquinas individuales
formen un sistema distribuido, esto es, se comporten como
un todo.
No confundir con el cluster de PostgreSQL (una instancia)



Conceptos básicos (II)

● Replicación: técnica que permite transmitir el estado
(datos) de un servidor a otro(s) de manera que todos
terminen con una copia del estado. Puede ser:

 Síncrona/asíncrona
 Total/parcial (sólo una parte del estado se replica)

● Sharding o escalado horizontal: técnica para dividir una
carga de trabajo entre diversos nodos. Si no es
transparente, el sistema no se comporta como un todo.

● Consistencia eventual: garantía de una relación de
causalidad en los eventos pero no que éstos se

propaguen inmediatamente



Alta disponibilidad



http://www.xtium.com/blog/on-cloud-9-but-how-many-nines-do-i-need

Alta Disponibilidad y Capacidad de Recuperación

● Disponibilidad y Capacidad de Recuperación son dos
cosas distintas

●Las tablas eliminadas y actualizaciones erróneas son mucho
más comunes de lo que se piensa

● El archivado continuo (PITR, “Recuperación Point in Time”)
es el mejor mecanismo para recuperarse de este tipo de
fallos.

● Las técnicas de Alta Disponibilidad están dirigidas a
Escenarios de Fallos de Sistemas o Sitios.



Mecanismos de Alta Disponibilidad

1. Externos a la base de datos:

a. Almacenamiento compartido en red (SAN)
b. DRBD
c. Clustering (a nivel de S.O.)

2. A nivel de base de datos

a. pgpool
b. Log shipping
c. Replicación



Mecanismos externos a la BB.DD.

1. Ventajas generales:

a. No tienen impacto (arrastre) sobre la base de
datos
b. Tienen un RTO muy bajo
c. Tienen un RPO cero
2. Inconvenientes generales:

 Sólo dos nodos
 Configuración estrictamente activo-pasivo
 Distancia LAN
 No ofrece funcionalidades adicionales como ayuda

al backup, PITR, etc



HA: disco en red compartido (SAN)



HA: disco en red compartido (SAN)

● Ventajas:

➔ Transparente a la base de datos
➔ Permite un RTO muy bajo

● Inconvenientes:

➔ Configuración activo-pasivo
➔ Coste elevado
➔ Sólo dos nodos
➔ Es necesario un mecanismo para levantar el
servicio en el nodo secundario
➔ Requiere/utiliza multipath



HA: DRBD



HA: DRBD

● Ventajas e inconvenientes: los mismos que el disco
compartido en red salvo el coste, no requiere hardware
dedicado.

● Es open source y muy eficiente

● Replica los volúmenes de disco de forma asíncrona,
síncrona o semi-síncrona

● Puede dar lugar a configuraciones muy interesantes, como
por ejemplo replicar de un volumen efímero de AWS a un
EBS lento (con cuidado)



HA: Clustering a nivel de S.O.

● Técnica casi en desuso

● Requiere soporte del S.O.

● Permite que dos máquinas se comporten como una única.
Requiere una IP virtual.

● Configuración activo-pasivo



HA: pgpool

● Hace de pooling de conexiones (como pgbouncer)

● Si un servidor cae, la conexión con pgpool no, y sirve
carga a los demás

● Entiende la replicación (core o Slony) y divide r/w entre los
servidores esclavo(s)/maestro

● Permite ejecutar scripts ante eventos de HA

● Tiene un modo de HA para no ser SPOF



HA: WAL shipping

● WAL shipping es la técnica para enviar registros de WAL de
un servidor maestro de postgres a otro(s), esclavo(s), de
forma que el(los) esclavo(s) están continuamente
reproduciendo los segmentos de WAL, según llegan, y por lo
tanto contienen una copia de la base de datos maestra.

● Se basa en archivado continuo: cada vez que se rota un
fichero de WAL (de pg_xlog), archivado continuo lo copia al
directorio externo (archive_command). Este fichero externo
se copia a la base de datos esclava (el mecanismo es
independiente de la base de datos: NFS, cp, rsync, etc) y
ésta lo reproduce y aplica los cambios.


● Está disponible desde PostgreSQL 8.2.



HA: WAL shipping (II)

● La réplica está continuamente en modo recuperación,
aplicando los ficheros de WAL que reciba.

●Requiere un proceso de copia (síncrono o asíncrono) pero
externo a la base de datos.

● Hay una ventana de pérdida de datos, suma de:

 Tiempo de rotación del fichero de WAL (controlado por

checkpoint_timeout, checkpoint_segments,
checkpoint_completion_target).

 Tiempo de transmisión/copia del fichero rotado y archivado a la

base de datos esclava.



● Es un mecanismo extremadamente sencillo.



Replicación



http://www.flickr.com/photos/86624586@N00/10177597/

Replicación

● La replicación es la transmisión de información derivada de
las modificaciones de estado, de una base de datos a otra.

● Todas las operaciones que modifiquen el estado de la base
de datos se transmiten (transformadas o no) a otra base de
datos, que “replica” las operaciones, de forma que ambas
bases de datos tengan la misma información.

● La replicación permite alcanzar objetivos como:

✔ Alta disponibilidad (caída del maestro)
✔ Backups “calientes” (backup con poca o cero recuperación

necesaria)

✔ Disponer de una copia en otro lugar



geográfico



Replicación



Replicación basada en triggers

● Cada operación DML ejecuta un trigger (acción en
respuesta a un evento de la base de datos) que genera una
representación del cambio (SQL, JSON, formato binario, etc)
y la envía a la base de datos remota.

● Típicamente utiliza una cola para almacenar los cambios, a
un ritmo potencialmente diferente del de envío a la base de
datos remota (modelo productor-consumidor): asincronía

● Dado que los triggers se instalan por el software en las
tablas, se puede seleccionar un subconjunto arbitrario de
la(s) tabla(s) de la base(s) de datos que se quieren replicar.



Replicación basada en WAL

● Postgres ya dispone de un formato nativo de
representación de los cambios en la base de datos: el WAL
(Write-Ahead Log).

● Dado que el WAL ya se genera (sí o sí) para garantizar la
durabilidad de la base de datos, no supone más overhead

● Postgres además sabe cómo interpretar estos registros
(proceso de recuperación, wal writer, checkpoint) por lo que
la implementación es muy sencilla.

● Los registros de WAL pueden enviarse a la réplica por
ficheros (WAL shipping) o por la red (streaming)



Trigger vs. WAL

● Impacto en el maestro (overhead): trigger es alto
(10-15%) y en WAL es bajo (1-3%).

● Latencia de la replicación: baja/muy baja en WAL,
baja/media/alta en trigger.

● Posibilidad de seleccionar subconjuntos de bases de datos
y/o tablas (y secuencias) a replicar: WAL no, trigger sí.

● Adecuación a entornos MAN/alta latencia/canales ruidosos:
WAL establece canales TCP/IP permanentemente abiertos, y
es muy sensible; trigger funciona mucho mejor.


● Integración core de PostgreSQL: WAL sí, trigger no.



Hot standby

● Hot standby permite que una base de datos postgres en
modo recuperación acepte consultas de sólo lectura
durante dicho proceso de recuperación. Disponible desde
PostgreSQL 8.4

● Abre la puerta a escalabilidad horizontal de las consultas
de lectura en un esquema de replicación.

● No es “trivial”: ¿qué sucede si mientras una query larga se
ejecuta en un esclavo llega un DML de DROP TABLE? Se
puede retrasar la aplicación del cambio o cancelar la query.

● Permite tener esclavos retrasados para solucionar

fallos humanos.



Configuración de WAL shipping

● El primer paso es activar archivado continuo (repaso):
[postgresql.conf]
wal_level = archive
archive_mode = on
archive_command = 'test ! -f /path/dir/archivado/%f
&& cp %p /path/dir/archivado/%f'
[require restart de la base de datos]

● Configurar un mecanismo para que todos los ficheros en
/path/dir/archivado/ estén disponibles en la máquina del
esclavo. P.ej. directorio compartido en local o por NFS.

● Opcionalmente, forzar tiempo máximo de archivado:

archive_timeout = 300



Configuración de WAL shipping (II)

● Realizar un backup base del maestro y copiarlo al esclavo
(pg_start_backup + rsync/equivalente + pg_stop_backup).

● Crear recovery.conf en el esclavo:
[recovery.conf]
restore_command = 'cp /path/dir/esclavo/%f %p'
standby_mode = on

● Iniciar el esclavo. Se podrá comprobar en los logs que
comienza primero a recuperar la base de datos a partir del
backup, y que posteriormente entra en un bucle continuo de
esperar a que aparezcan nuevos ficheros WAL

y aplicarlos.



Configuración de hot standby

● Sea con WAL shipping o con streaming replication (a
continuación), se puede (o no) configurar hot standby para
que el esclavo acepte consultas de sólo lectura:

[postgresql.conf maestro]
wal_level = hot_standby
[postgresql.conf esclavo]
hot_standby = on
max_standby_archive_delay = 30s

● El parámetro wal_level es ignorado en el esclavo (no
genera WALs). Los parámetros hot_standby y
max_standby_archive_delay son ignorados en el maestro.

Así que el mismo postgresql.conf puede usarse para ambos.



WAL shipping + hot standby: logs en el esclavo

LOG: database system was interrupted; last known up at 2013-09-26 12:12:49 CEST
LOG: entering standby mode
LOG: database system was not properly shut down; automatic recovery in progress
LOG: redo starts at 0/2