Mecanismos de Replicacin

y Alta Disponibidad en PostgreSQL

lvaro Hernndez Tortosa <aht@Nosys.es>

Acerca de m

lvaro Hernndez Tortosa <aht@Nosys.es>

Fundador y Director Tcnico en NOSYS
Qu hacemos en NOSYS?

Formacin, consultora y desarrollo de software con

PostgreSQL (y Java)

Partners de EnterpriseDB

Formacin avanzada en Java con

Javaspecialists.eu: Java Master Course y Java
Concurrency Course

Partners de Amazon AWS. Formacin y consultora

en AWS
Twitter: @ahachete
LinkedIn: http://es.linkedin.com/in/alvarohernandeztortosa/

Conceptos bsicos
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 (tpicamente < 0,05%). Casi siempre
requiere que no haya SPOFs.

Clustering: que un conjunto de mquinas individuales

formen un sistema distribuido, esto es, se comporten como
un todo.
No confundir con el cluster de PostgreSQL (una instancia)

Conceptos bsicos (II)

Replicacin: tcnica que permite transmitir el estado
(datos) de un servidor a otro(s) de manera que todos
terminen con una copia del estado. Puede ser:
Sncrona/asncrona
Total/parcial (slo una parte del estado se replica)

Sharding o escalado horizontal: tcnica para dividir una

carga de trabajo entre diversos nodos. Si no es
transparente, el sistema no se comporta como un todo.

Consistencia eventual: garanta de una relacin 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 Recuperacin

Disponibilidad y Capacidad de Recuperacin son dos
cosas distintas

Las tablas eliminadas y actualizaciones errneas son mucho

ms comunes de lo que se piensa

El archivado continuo (PITR, Recuperacin Point in Time)

es el mejor mecanismo para recuperarse de este tipo de
fallos.

Las tcnicas de Alta Disponibilidad estn 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. Replicacin

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:
Slo dos nodos
Configuracin 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:

Configuracin activo-pasivo

Coste elevado

Slo 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 volmenes de disco de forma asncrona,

sncrona o semi-sncrona

Puede dar lugar a configuraciones muy interesantes, como

por ejemplo replicar de un volumen efmero de AWS a un
EBS lento (con cuidado)

HA: Clustering a nivel de S.O.

Tcnica casi en desuso

Requiere soporte del S.O.

Permite que dos mquinas se comporten como una nica.

Requiere una IP virtual.

Configuracin activo-pasivo

HA: pgpool

Hace de pooling de conexiones (como pgbouncer)

Si un servidor cae, la conexin con pgpool no, y sirve

carga a los dems

Entiende la replicacin (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 tcnica para enviar registros de WAL de
un servidor maestro de postgres a otro(s), esclavo(s), de
forma que el(los) esclavo(s) estn continuamente
reproduciendo los segmentos de WAL, segn 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 rplica est continuamente en modo recuperacin,
aplicando los ficheros de WAL que reciba.

Requiere un proceso de copia (sncrono o asncrono) pero

externo a la base de datos.

Hay una ventana de prdida de datos, suma de:

Tiempo de rotacin del fichero de WAL (controlado por
checkpoint_timeout, checkpoint_segments,
checkpoint_completion_target).
Tiempo de transmisin/copia del fichero rotado y archivado a la
base de datos esclava.

Es un mecanismo extremadamente sencillo.

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

Replicacin
La replicacin es la transmisin de informacin 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 informacin.

La replicacin permite alcanzar objetivos como:

Alta disponibilidad (cada del maestro)

Backups calientes (backup con poca o cero recuperacin
necesaria)
Disponer de una copia en otro lugar
geogrfico

Replicacin

Replicacin basada en triggers

Cada operacin DML ejecuta un trigger (accin en
respuesta a un evento de la base de datos) que genera una
representacin del cambio (SQL, JSON, formato binario, etc)
y la enva a la base de datos remota.

Tpicamente utiliza una cola para almacenar los cambios, a

un ritmo potencialmente diferente del de envo a la base de
datos remota (modelo productor-consumidor): asincrona

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.

Replicacin basada en WAL

Postgres ya dispone de un formato nativo de
representacin 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 ms overhead

Postgres adems sabe cmo interpretar estos registros

(proceso de recuperacin, wal writer, checkpoint) por lo que
la implementacin es muy sencilla.

Los registros de WAL pueden enviarse a la rplica 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 replicacin: 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.

Adecuacin a entornos MAN/alta latencia/canales ruidosos:

WAL establece canales TCP/IP permanentemente abiertos, y
es muy sensible; trigger funciona mucho mejor.

Integracin core de PostgreSQL: WAL s, trigger no.

Hot standby
Hot standby permite que una base de datos postgres en
modo recuperacin acepte consultas de slo lectura
durante dicho proceso de recuperacin. Disponible desde
PostgreSQL 8.4

Abre la puerta a escalabilidad horizontal de las consultas

de lectura en un esquema de replicacin.

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 aplicacin del cambio o cancelar la query.

Permite tener esclavos retrasados para solucionar

fallos humanos.

Configuracin 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/ estn disponibles en la mquina del
esclavo. P.ej. directorio compartido en local o por NFS.

Opcionalmente, forzar tiempo mximo de archivado:

archive_timeout = 300

Configuracin 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.

Configuracin de hot standby

Sea con WAL shipping o con streaming replication (a
continuacin), se puede (o no) configurar hot standby para
que el esclavo acepte consultas de slo lectura:

[postgresql.conf maestro]
wal_level = hot_standby
[postgresql.conf esclavo]
hot_standby = on
max_standby_archive_delay = 30s
El parmetro wal_level es ignorado en el esclavo (no
genera WALs). Los parmetros 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/2000028
LOG: record with zero length at 0/2003600
LOG: consistent recovery state reached at 0/2003600
LOG: database system is ready to accept read only connections
LOG: restored log file "000000010000000000000002" from archive
LOG: restored log file "000000010000000000000003" from archive
cp: /tmp/archived/000000010000000000000004: No such file or directory
cp: /tmp/archived/000000010000000000000004: No such file or directory
[...]
LOG: restored log file "000000010000000000000004" from archive
cp: /tmp/archived/000000010000000000000005: No such file or directory
cp: /tmp/archived/000000010000000000000005: No such file or directory
[...]

Streaming Replication

WAL shipping tiene dos inconvenientes:

Hasta que un WAL no rota, no se copiar y procesar al esclavo,

por lo que hay una ventana de potencial prdida de datos.
Requiere interaccin con un mecanismo externo para la copia de los
ficheros.

Para resolverlos, en 9.0 se introdujo Streaming Replication

(SR), que copia los registros de WAL (segn se produzcan,
no cuando rote el fichero) a las bases de datos esclavas a
travs de la red (streaming).

El overhead es muy bajo: los esclavos se comportan como

una conexin ms a la base de datos para obtener los WAL.

Streaming Replication (II)

Por defecto, SR es asncrono (el COMMIT en el maestro no
espera a que los esclavos hayan recibido los registros WAL).

Normalmente, la latencia de replicacin (que determina la

mxima prdida de datos) es muy baja (inferior al segundo)

Desde 9.1 se soporta tambin modo sncrono (el COMMIT

en maestro slo se produce cuando todos los esclavos han
recibido -no necesariamente replicado- los registros de
WAL). El modo sncrono se puede seleccionar por cada tx.
En modo sncrono no hay nunca prdida de datos.

Desde 9.3 se soporta replicacin en cascada (un esclavo

puede servir de maestro de envo de registros de WAL).

Streaming Replication (III)

Si la sincronizacin maestro/esclavo(s) se desfasa mucho,
puede suceder que el esclavo se desconecte (si los
segmentos de WAL que se deben enviar por streaming al
esclavo, ste no los ha consumido, y en el maestro se
reciclan, ya no se le podrn enviar). En este caso, es
necesario comenzar de nuevo (backup base).

SR es compatible con WAL shipping (y es la configuracin

recomendada): postgres puede aplicar los registros de WAL
independientemente de donde vengan (sea de la red o de
ficheros archivados). As, si la red cae o se reciclan
segmentos en el maestro, se podrn seguir aplicando de
ficheros archivados sin que se desconecte el esclavo.

Configuracin SR asncrono

Realizar un backup base del maestro al esclavo.

Opcionalmente, configurar archivado continuo.

[postgresql.conf maestro]
wal_level = hot_standby
max_wal_senders = X
# nmero mx esclavos
wal_keep_segments = Y
# nmero de segmentos WAL a
# conservar (desconexiones)
[postgresql.conf esclavo]
hot_standby = on
max_standby_streaming_delay = 30s
hot_standby_feedback = on
# previene conflictos

Configuracin SR asncrono (II)

[recovery.conf]
primary_conninfo = host=ip port=5432 user=...
standby_mode = on
La replicacin se realiza mediante conexiones a la bbdd de
los esclavos al maestro que requieren permisos especiales.

Es necesario un usuario con privilegios de replication

(CREATE USER WITH REPLICATION).

Adems, hace falta una entrada especfica en pg_hba, con

conexiones a la base de datos llamada replication:
[pg_hba.conf]
host replication user ip/mask trust/md5

Monitorizacin bsica SR asncrono

Se puede consultar en cada mquina cul es el ltimo
registro de WAL creado, enviado y recibido:

[maestro]
SELECT pg_current_xlog_location();
[esclavo]
select pg_last_xlog_receive_location(); # recibido
select pg_last_xlog_replay_location();
# aplicado
Desde PostgreSQL 9.2:
SELECT * FROM pg_stat_replication;

SR en 9.4
Replication slots: permite segmentar la replicacin
pendiente en los esclavos de forma que puedan
reconectarse sin necesidad de backup base ni archivado
continuo.
http://blog.2ndquadrant.com/postgresql-9-4-slots/

Time delayed standbys: permite aplicar un retraso en el

nodo esclavo para aplicar la replicacin. Esto permite
recuperar fcilmente errores humanos (borrados
accidentales, por ejemplo).
http://www.depesz.com/2013/12/20/waiting-for-9-4-allow-t
ime-delayed-standbys-and-recovery/

BDR en 9.5/10
Replicacin lgica, pero no basada en triggers, sino en
decoding del WAL.

Incluida en el core de postgres en 9.5 10. Las

caractersticas bsicas internas van a estar ya en 9.4.

Adems, va a implementar BRD: Bi-Directional Replication

(esto es, maestro-maestro).

No pretende lograr un cluster (conjunto que se comporta

como un todo), sino sistemas separados (aunque
interconectados). Permite escala geogrfica
http://wiki.postgresql.org/wiki/BDR_Project

Slony

Dos o ms nodos: uno Activo(RW), varios Pasivos

Permite tener diferentes versiones al tiempo
Replicacin de Datos basada en trigger
tabla a tabla
Overhead alto: ms del 10% en el Activo(RW)
Compleja de instalar/configurar y mantener

Distacia mxima entre nodos: todo el mundo

Soportado desde PostgreSQL 8.3

Slony (II)

Ventajas
Seleccionable para objetos de la base de datos
individuales
Posibilidad de replicacin en cualquier lugar del mundo
Posibilidad de mantener la disponibilidad a travs de
actualizaciones de software
No se necesitan requerimientos hardware adicionales

Inconvenientes
Prdida potencial de algunos datos (retardo)
Proporciona opciones de Alta Disponibilidad y
Recuperacin en caso de Desastres
La recuperacin de Errores Comunes es posible
mediante el uso de aplicacin diferida de cambios

Futuro
Se est considerando la replicacin por logs

Slony (III)
Maestro/Esclavo asncrono
Se puede usar para mejorar el rendimiento de usuarios
dispersos geogrficamente
Alta disponibilidad

Limitaciones importantes
No se detectan ni propagan cambios en DDL
Las tablas replicadas deben tener ndices nicos
No se replican BLOBs
No permite varios maestros
No se puede detectar un fallo de nodo

Bucardo

Dos maestros o maestro-esclavo(s)

Asncrona

Basado en replicacin va triggers. Escrito en PERL

Handler de conflictos estndar o a medida

Funciona desde PostgreSQL 8.1

Londiste
Similar a Slony, replicacin basada en triggers
maestro-esclavo(s)

Utiliza PgQ, un sistema de colas para PostgreSQL muy bueno

Parte del paquete skytools (al igual que PgQ), desarrollado y

usado por Microsoft (perdn, Skype)

Programado en Python

Postgres-XC

Clustering puro de bases de datos. Escala en escritura y lectura.

Soporta transacciones multi-nodo: es una base de datos global.

Permite tanto replicar tablas como distribuirlas (aumentar

fiabilidad o rendimiento).

Es un proyecto aparte de postgres, pero se expone con el mismo

interfaz que postgres. Es tambin software libre.

La arquitectura es compleja y escala hasta un nmero limitado

de nodos.

El rendimiento es bastante bueno

Postgres-XC (II)

http://www.linuxforu.com/2012/01/postgres-xc-database-clustering-solution/

Postgres-XC (III)

http://sourceforge.net/apps/mediawiki/postgres-xc/index.php?title=Scalability