Replicación y Alta Disponibilidad en PostgreSQL
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Replicación y Alta Disponibilidad en PostgreSQL

on

  • 1,376 views

Charla de marzo de 2014 del grupo de PostgreSQL España (http://www.meetup.com/PostgreSQL-Espana/). ...

Charla de marzo de 2014 del grupo de PostgreSQL España (http://www.meetup.com/PostgreSQL-Espana/).

Se describen todos los mecanismos de alta disponibilidad (high availability) y replicación de que dispone PostgreSQL, tanto en el core (WAL shipping, streaming replication) como herramientas externas (pgpool, Slony, bucardo, londiste).

Statistics

Views

Total Views
1,376
Views on SlideShare
1,308
Embed Views
68

Actions

Likes
2
Downloads
51
Comments
0

2 Embeds 68

http://www.slideee.com 63
https://twitter.com 5

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Replicación y Alta Disponibilidad en PostgreSQL Presentation Transcript

  • 1. Mecanismos de Replicación y Alta Disponibidad en PostgreSQL Álvaro Hernández Tortosa <aht@Nosys.es>
  • 2. Acerca de mí ● Álvaro Hernández Tortosa <aht@Nosys.es> ● 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/
  • 3. 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)
  • 4. 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
  • 5. Alta disponibilidad http://www.xtium.com/blog/on-cloud-9-but-how-many-nines-do-i-need
  • 6. 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.
  • 7. 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
  • 8. 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
  • 9. HA: disco en red compartido (SAN)
  • 10. 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
  • 11. HA: DRBD
  • 12. 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)
  • 13. 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
  • 14. 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
  • 15. 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.
  • 16. 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.
  • 17. Replicación http://www.flickr.com/photos/86624586@N00/10177597/
  • 18. ● 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
  • 19. Replicación
  • 20. ● 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 triggers
  • 21. ● 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) Replicación basada en WAL
  • 22. ● 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. Trigger vs. WAL
  • 23. ● 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. Hot standby
  • 24. ● 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
  • 25. ● 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 WAL shipping (II)
  • 26. ● 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. Configuración de hot standby
  • 27. 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 [...] WAL shipping + hot standby: logs en el esclavo
  • 28. ● 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 pérdida de datos. ➔ Requiere interacción 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 (según se produzcan, no cuando rote el fichero) a las bases de datos esclavas a través de la red (streaming). ● El overhead es muy bajo: los esclavos se comportan como una conexión más a la base de datos para obtener los WAL. Streaming Replication
  • 29. ● Por defecto, SR es asíncrono (el COMMIT en el maestro no espera a que los esclavos hayan recibido los registros WAL). ● Normalmente, la latencia de replicación (que determina la máxima pérdida de datos) es muy baja (inferior al segundo) ● Desde 9.1 se soporta también modo síncrono (el COMMIT en maestro sólo se produce cuando todos los esclavos han recibido -no necesariamente replicado- los registros de WAL). El modo síncrono se puede seleccionar por cada tx. En modo síncrono no hay nunca pérdida de datos. ● Desde 9.3 se soporta replicación en cascada (un esclavo puede servir de “maestro” de envío de registros de WAL). Streaming Replication (II)
  • 30. ● Si la sincronización 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 podrán enviar). En este caso, es necesario comenzar de nuevo (backup base). ● SR es compatible con WAL shipping (y es la configuración 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 podrán seguir aplicando de ficheros archivados sin que se desconecte el esclavo. Streaming Replication (III)
  • 31. ● Realizar un backup base del maestro al esclavo. ● Opcionalmente, configurar archivado continuo. [postgresql.conf maestro] wal_level = hot_standby max_wal_senders = X # número máx esclavos wal_keep_segments = Y # número de segmentos WAL a # conservar (desconexiones) [postgresql.conf esclavo] hot_standby = on max_standby_streaming_delay = 30s hot_standby_feedback = on # previene conflictos Configuración SR asíncrono
  • 32. [recovery.conf] primary_conninfo = “host=ip port=5432 user=...” standby_mode = on ● La replicación 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). ● Además, hace falta una entrada específica en pg_hba, con conexiones a la base de datos llamada replication: [pg_hba.conf] host replication user ip/mask trust/md5 Configuración SR asíncrono (II)
  • 33. ● Se puede consultar en cada máquina cuál 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; Monitorización básica SR asíncrono
  • 34. ● Replication slots: permite segmentar la replicación 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 replicación. Esto permite recuperar fácilmente errores humanos (borrados accidentales, por ejemplo). http://www.depesz.com/2013/12/20/waiting-for-9-4-allow-t ime-delayed-standbys-and-recovery/ SR en 9.4
  • 35. ● Replicación lógica, pero no basada en triggers, sino en decoding del WAL. ● Incluida en el core de postgres en 9.5 ó 10. Las características básicas internas van a estar ya en 9.4. ● Además, 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 geográfica http://wiki.postgresql.org/wiki/BDR_Project BDR en 9.5/10
  • 36. ● Dos o más nodos: uno Activo(RW), varios Pasivos  Permite tener diferentes versiones al tiempo ● Replicación de Datos basada en trigger  tabla a tabla  Overhead alto: más del 10% en el Activo(RW)  Compleja de instalar/configurar y mantener ● Distacia máxima entre nodos: todo el mundo ● Soportado desde PostgreSQL 8.3 Slony
  • 37. ● Ventajas  Seleccionable para objetos de la base de datos individuales  Posibilidad de replicación en cualquier lugar del mundo  Posibilidad de mantener la disponibilidad a través de actualizaciones de software  No se necesitan requerimientos hardware adicionales ● Inconvenientes  Pérdida potencial de algunos datos (retardo)  Proporciona opciones de Alta Disponibilidad y Recuperación en caso de Desastres  La recuperación de Errores Comunes es posible mediante el uso de aplicación diferida de cambios ● Futuro  Se está considerando la replicación por logs Slony (II)
  • 38. ● Maestro/Esclavo asíncrono  Se puede usar para mejorar el rendimiento de usuarios dispersos geográficamente  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 Slony (III)
  • 39. ● Dos maestros o maestro-esclavo(s) ● Asíncrona ● Basado en replicación vía triggers. Escrito en PERL ● Handler de conflictos estándar o a medida ● Funciona desde PostgreSQL 8.1 Bucardo
  • 40. ● Similar a Slony, replicación 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 (perdón, Skype) ● Programado en Python Londiste
  • 41. ● 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 también software libre. ● La arquitectura es compleja y escala hasta un número limitado de nodos. ● El rendimiento es bastante bueno Postgres-XC
  • 42. Postgres-XC (II) http://www.linuxforu.com/2012/01/postgres-xc-database-clustering-solution/
  • 43. Postgres-XC (III) http://sourceforge.net/apps/mediawiki/postgres-xc/index.php?title=Scalability