Replicacion de BD PostgreSQL

1. REPLICACIÓN DE DATOS EN POSTGRESQL
Algunos conceptos:
Nodo: Base de datos que se encuentra envuelta en el proceso de replicación entre los
principales tenemos: nodo origen y nodo suscriptor.
Replicación: Proceso por el cual se desea mantener y copiar los datos de una base de datos de
manera que estos datos son transportados y son almacenados.
Replicación maestro: Se encarga de transferir las modificaciones de forma asíncrona a los
nodos suscriptores.
Maestro/Esclavo:
Maestro: recibe consultas de lectura/escritura
Esclavo: solo consultas de lectura
Generalmente cambios asincrónicos (no simultaneo)
Multi-Maestro:
Solo Maestros
Generalmente con sincronismo entre servidores
Sin sincronismo: resolución o prevención de conflictos
En que consiste un sistema de replicación
La replicación es el proceso de intercambiar datos de transacciones para asegurar la
consistencia entre nodos de bases de datos redundantes. Es el proceso de copiar y mantener
los elementos de una base de datos en múltiples bases de datos que forman un sistema de
bases de datos distribuido.
En concreto es mantener una segunda base de datos alterna con la data idéntica a la principal.
Entre las distintas ventajas que ofrece este proceso encontramos:
➢ Alta disponibilidad (high availability): Se puede incrementar la disponibilidad de una base
de datos mediante la replicación en un sistema distribuido. Si una de las máquinas del sistema
falla, las otras podrán satisfacer las necesidades del cliente.
➢ Balance de carga (load balancing): La replicación se puede utilizar para hacer un balance
de carga. Ésta es una técnica usada para compartir el trabajo a realizar entre varias
computadoras.
➢ Soporte para aplicaciones de alto consumo: Se puede satisfacer las necesidades de ciertos
clientes que requieren un alto consumo en consultas, que sería muy costo en rendimiento, o
hasta imposible, en una base de datos sin replicación.
➢ Confiabilidad: Debido a que existen varias copias de los datos disponibles en el sistema, se
cuenta con un mecanismo confiable de recuperación de datos ante fallos en algún nodo.
Modelos de Replicación de Datos
Shared Disk Failover
Este método evita el sobrecargo de sincronización utilizando una sola copia de la base de
datos. Usa un arreglo de disco simple que es compartido por múltiples servidores. Si el
servidor principal de la base de datos falla, el servidor standby es capaz de montarse y
empezar la base de datos como si se tratase de una recuperación de una caída de la base de
datos. Esto permite una recuperación rápida y sin pérdida de datos.
File System Replication
Una versión modificada de la funcionalidad del hardware compartido es la replicación del
sistema de archivos, donde todos los cambios de dicho sistema están duplicados en el sistema
de archivos de otra computadora. La única restricción es que la duplicación debe ser hecha de
manera tal que se asegure que el servidor standby tiene una copia consistente del sistema de

2. archivos.
Transaction Log Shipping
Los servidores warm standby y hot standby pueden mantenerse actualizados leyendo un flujo
de registros de WAL (write-ahead log). Si el servidor principal falla, el servidor standby
contiene casi todos los datos del servidor pincipal, y puede ser rápidamente convertido en el
nuevo servidor master. Este modelo puede ser sincrónico o asincrónico, y sólo puede ser
implementado para el servidor de base de datos completo.
Trigger-Based Master-Standby Replication
Este tipo de replicación envía todas las consultas de modificación de datos al servidor master.
El servidor master envía asincrónicamente las modificaciones de los datos al servidor standby.
Éste último puede responder consultas de sólo lectura mientras el servidor master esta
corriendo.
Statement-Based Replication Middleware
Con este tipo de replicación, un programa intercepta todas las consultas SQL y las envía a uno
o todos los servidores. Cada servidor opera independientemente. Las consultas de lectura-
escritura deben ser enviadas a todos los servidores, así todos los servidores reciben cualquier
cambio efectuado. Pero las consultas de sólo lectura pueden ser enviadas a un único servidor,
permitiendo la distribución de carga de trabajo de lectura a través de los servidores
disponibles.
Asynchronous Multimaster Replication
Para los servidores que no están conectados regularmente, mantener los datos consistentes a
través de estos es un gran desafío. Usando este tipo de replicación, cada servidor trabaja de
manera independiente y periódicamente se comunica con los otros servidores para identificar
las transacciones conflictivas. Estos conflictos pueden ser resueltos por el usuario o por reglas
de resolución de conflictos.
Synchronous Multimaster Replication
En este tipo de replicación, cada servidor puede aceptar solicitudes de escritura y los datos
modificados son transmitidos desde el servidor original al resto de los servidores antes de que
cada transacción sea confirmada. Una fuerte actividad de escritura puede causar un bloqueo
excesivo,causando un bajo rendimiento. Las solicitudes de lectura pueden ser enviadas a
cualquier servidor.
Replicación nativa en PostgreSQL
A partir de la versión 8.3 de PostgreSQL, se incluye la función de enviar en forma periódica
archivos de un servidor master a un servidor standby. El modelo que implementa es Warm
Standby, los servidores standby no puede responder consultas sobre el.
A partir de la versión 9.0 de PostgreSQL, se incluye la función de replicación como parte de
su núcleo. El modelo que se implementa es el Transaction Log Shipping, conocido como:
Streaming Replication con la opción Hot Standby, que permite que el/los servidores standby
puedan responder consultas de sólo lectura.
Ficheros WAL
Los ficheros WAL (Write Ahead Log) son utilizados por PostgreSQL para guardar toda la
información sobre las transacciones y cambios realizados en la base de datos. Son utilizados
para garantizar la integridad de los datos almacenados en la base de datos. También se utilizan
para reparar automáticamente posibles inconsistencias en la base de datos después de una
caída del servidor. Estos ficheros tienen un nombre único y un tamaño por defecto de 16 Mb.
Cada vez que ocurre una transacción en la base de datos, se escribe en uno de estos archivos,
así, si hay algún problema, se puede recurrir a los archivos WAL para recuperar dicha
transacción.

3. PostgeSQL nativamente empezo a incluir replicaciones:
PostgreSQL 8.3 → Warm Standby
PostgreSQL 9.0 → Hot Standby / Streaming Replication
PostgreSQL 9.1 → Replicación sincrónica ( Master → Slave)
.
Warm StandBy/Log Shipping
Esta solución viene implementada nativamente desde la versión 8.3. Se basa en él envió
periódico al servidor secundario de archivos WAL. Los archivos WAL o Write Ahead Logging
son similares a los archivos Redo Log de otras bases de datos. Cada vez que una transacción
se efectúa en la base de datos se escribe en un archivo, de esta forma si hay algún percance
con la base de datos puede recurrirse a los archivos WAL para recuperarla.
Ventajas
• Muy sencillo de implementar, modificando apenas 6 líneas en los archivos de
configuración lo tenemos listo.
• Todo lo que se haga en el servidor principal, incluyendo sentencias DLL, se replica en
el secundario (esto a veces es una desventaja, por ejemplo, si tan solo queremos
replicar una base de datos o tener distintos de índices).
Desventajas
• El Warm StandBy Server no puede usarse para aligerar carga del principal, ya que no
pueden efectuarse consultas sobre él.

4. • Podemos especificar el periodo o ‘timeout’ con el que se mandan los archivos WAL,
pero si este es muy bajo podemos saturar el servidor o la red. Por lo tanto,
dependiendo del nivel de transacciones que tengamos, en caso de una emergencia, es
posible que perdamos alguna.
• Las dos máquinas deben tener arquitecturas (32 or 64 bits) y versiones similares de
PostgreSQL.
Hot Standby/Streaming Replication
Similar a la replicación Warm StandBy. Pero reduce la sincronización de las base de datos por
debajo de 1 segundo ya que se envían registros WAL en vez de los ficheros completos.
Además podemos efectuar consultas sobre el servidor secundario si lo deseamos para aligerar
la carga del primario.
Ventajas
• Sencillo de implementar.
• Todo lo que se haga en el servidor principal, incluyendo sentencias DLL, se replica en
el secundario.
• Puede usarse para aligerar la carga del servidor principal.
Desventajas
• No se pueden especificar que bases de datos o tablas queremos replicar.
• No se pueden hacer cambios en el esquema en el servidor esclavo (por ejemplo, una
indexación distinta).
• Las dos máquinas deben tener arquitecturas (32 o 64 bits) y versiones similares de
PostgreSQL.
A partir de la versión 9.0, PostgreSql soporta replicación en flujo, lo que permite a los
servidores en espera estar más actualizados que con los métodos anteriores de tranferencia de
archivos. Los servidores secundarios se conectan al primario, que envía los registros de WAL
cuando son generados, sin esperar a que los archivos de WAL se llenen.
Básicamente SR (Streaming Replication) permite que exista un proceso “sender”en el master
que envíe a procesos “receiver” en el/los nodos secundarios porciones de WAL (Write-Ahead
Log), es decir, de transacciones “comiteadas” recientemente. Antes (PostgreSQL 8.4 y
anteriores) los WAL se podían archivar a otro nodo una vez se hayan completado 16 MB de
transacciones (por defecto), con lo cual si se tenía una BD que “cambie poco”, 16 MB podían
representar un lapso de tiempo físico importante. A partir de ahora, el lapso de tiempo se
reduce a unos pocos segundos de diferencia en el master y la/las réplicas (dependiendo el
enlace, la carga del master, etc.), con lo cual es una mejora substancial en las capacidades y

5. posibilidades de PostgreSQL.
Hay que resaltar que este proceso es asincrónico. Combinado con otra de las novedades de
9.0 que es la posibilidad de usar un nodo secundario (recibiendo WALs mediante SR o el
método tradicional) como Sólo Lectura (característica llamada “Hot Standby“), 9.0 dio un
paso muy adelante con respecto a versiones anteriores.
Las versiones más recientes de PostgreSql soportan varios modos de archivamiento (respaldo
continuo) y servidores en espera (standby con recupero continuo)
Replicación sincrónica
A partir de la versión 9.1 PostgreSql soporta la replicación sincrónica para clústeres,
permitiendo alta disponibilidad con consistencia a través de múltiples nodos, mediante la
implementación de clústeres de servidores PostgreSQL usando replicación sincrónica. La
replicación síncrónica soporta "2-safe replication" que asegura que las transacciones han sido
confirmadas por una réplica del servidor maestro, limitando grandemente la posibilidad de
perdida de datos. Solo PostgreSQL soporta replicación sincrónica a nivel de transacciones,
permitiendo a los usuarios escoger, para sus transacciones, entre tiempo de respuesta y
seguridad de sus datos.
Resumen de Modos de Operación:
Continuous Archiving(online backup): archivamiento continuo (respaldos de los segmentos
de WAL)
Point-In-Time Recovery (PITR): recuperación en el tiempo (disaster recovery)
Warm-standby: archivamiento + recuperación continua (high availability)
Hot-standby: archivamiento + recuperación continua + consultas de solo lectura
Herramientas de replicación para PostgreSQL
Herramientas Método replicación Sincronización
PgCluster Master – Master sincronico
Slony-I Master - Esclavo asincronico
PyReplica Master – Master; Master - Esclavo asincronico
PgPool Statement Based Middleware sincronico
Bucardo Master – Master; Master - Esclavo asincronico
RubyRep Master – Master; Master - Esclavo asincronico
Replicación en PostgreSQL con Slony-I
Slony-I es un sistema de replicación asíncrona para PostgreSQL del tipo Master → Multi
Slave. Realiza las actualizaciones a través de disparadores o triggers. Algunas de las
características de Slony-I son:
Puede replicar datos entre diferentes versiones de PostgreSQL.
Puede replicar datos entre servidores con distinto hardware o sistemas operativos.
Permite seleccionar qué tablas replicar.
Permite elegir en qué servidor esclavo se replicarán las tablas. Slony-I también está disponible
para versiones de PostgreSQL inferiores a la 9.0.Esta solución, al estar basada en triggers
presenta ciertas restricciones. Entre las limitaciones de Slony-I tenemos que no puede replicar
automáticamente:
Cambios realizados por una consulta DDL.

6. Cambios realizados a usuarios y roles.
Cambios en BLOB (Binary Large OBject – Objeto grande binario)
Ventajas frente a la replicación nativa
• Interfaz visual que permite configurarlo de manera más intuitiva.
• Independiente de la plataforma de los nodos.
• Permite seleccionar qué bases de datos se replicarán.
• Permite seleccionar qué tablas de la base de datos se replicarán.
Desventajas frente a la replicación nativa
• No replica cambios efectuados por consultas DDL.
• No replica cambios en los usuarios ni en los roles.
• No puede repicar automáticamente cambios a BLOBs.
• Es necesario instalar software adicional.
Replicación en PostgreSQL con RubyRep
RubyRep es una herramienta de replicación asincrónica, basada en Ruby que permite crear
sistemasde replicación de tipo Master → Master y Master → Slave.
RubyRep tiene soporte tanto para PostgreSQL como para MySQL, es independiente de las
versiones de las bases de datos y de la plataforma. Estas características hacen de Ruby Rep
una herramienta muy flexible que permite la integración de distintos sistemas. Es fácil de
instalar, configurar y monitorear. También es independiente del diseño que tengan las tablas a
replicar, es decir, permite tablas con claves primarias simples, combinadas, o incluso sin
claves primarias (en este último caso es necesario que exista al menos una columna
Unique).Además puede procesar con éxito textos multi-byte y tipos de datos grandes: en
PostgreSQL con bytea y text, en MySQL funciona con los BLOB y text.
Puede encontrar nuevas tablas añadidas en uno de los nodos y automáticamente sincronizar su
contenido. También puede configurar de manera automática disparadores o triggers, tablas de
log, etc.
Algunas de sus limitaciones son que no permite realizar un balance de carga, no admite lo que
seconoce como Connection Pooling (agrupamiento de conexiones), y no puede realizar
particionamiento de consultas.
Ventajas frente a la replicación nativa
Independiente de plataformas y de versiones de bases de datos.
Puede ser usado en PostgreSQL y en MySQL.
Permite la replicación Multi Master.
Desventajas frente a la replicación nativa
Es necesario instalar software adicional.
Menor rendimiento.
Conclusiones
La replicación de una BD sirve para:
• Para tener un sistema tolerable a fallas.
• Para balancear la carga de trabajo en diversos servidores.
• Para aplicaciones de alto consumo en consultas (BI)

7. • Para tener un ambiente de pruebas o desarrollo lo más parecido al ambiente de
producción.
Un sistema de replicación es muy importante para una organización que cuenta con
información sensible, para aquellas que manejan grandes volúmenes de datos, o para las que
utilizan acceso remoto a la información.
Contar con un sistema de replicación apropiado va a depender de muchos factores, por lo que
es necesario definirlos previamente y que la persona que se va a encargar de implementarlo
esté bien informado sobre todas las soluciones que ofrece el mercado.
Bibliografia
http://www.themagicnumber.es/replication-in-postgresql-i
http://www.themagicnumber.es/replication-in-postgresql-ii-hot-standbystreaming-replication?
lang=es
https://es.scribd.com/doc/217803010/El-Sistema-de-Replicacion-de-Base-de-Datos-de-
Postgresql-9-0
http://tecneca.com/como-replicar-bases-de-datos-postgresql-con-bucardo/
http://www.postgresql.org.ar/trac/wiki/StreamingReplication
http://www.postgresql.org.ar/trac/wiki/RespaldoContinuo
http://es.scribd.com/doc/124248224/Replicacion-PostgreSQL#scribd