REPLICACIN DE DATOS EN POSTGRESQL

Algunos conceptos:
Nodo: Base de datos que se encuentra envuelta en el proceso de replicacin entre los
principales tenemos: nodo origen y nodo suscriptor.
Replicacin: 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.
Replicacin maestro: Se encarga de transferir las modificaciones de forma asncrona a los
nodos suscriptores.

Maestro/Esclavo:
Maestro: recibe consultas de lectura/escritura
Esclavo: solo consultas de lectura
Generalmente cambios asincrnicos (no simultaneo)

Multi-Maestro:
Solo Maestros
Generalmente con sincronismo entre servidores
Sin sincronismo: resolucin o prevencin de conflictos

En que consiste un sistema de replicacin

La replicacin 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 mltiples 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 idntica 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 replicacin en un sistema distribuido. Si una de las mquinas del sistema
falla, las otras podrn satisfacer las necesidades del cliente.
Balance de carga (load balancing): La replicacin se puede utilizar para hacer un balance
de carga. sta es una tcnica 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 sera muy costo en rendimiento, o
hasta imposible, en una base de datos sin replicacin.
Confiabilidad: Debido a que existen varias copias de los datos disponibles en el sistema, se
cuenta con un mecanismo confiable de recuperacin de datos ante fallos en algn nodo.

Modelos de Replicacin de Datos

Shared Disk Failover
Este mtodo evita el sobrecargo de sincronizacin utilizando una sola copia de la base de
datos. Usa un arreglo de disco simple que es compartido por mltiples 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 recuperacin de una cada de la base de
datos. Esto permite una recuperacin rpida y sin prdida de datos.
File System Replication
Una versin modificada de la funcionalidad del hardware compartido es la replicacin del
sistema de archivos, donde todos los cambios de dicho sistema estn duplicados en el sistema
de archivos de otra computadora. La nica restriccin es que la duplicacin debe ser hecha de
manera tal que se asegure que el servidor standby tiene una copia consistente del sistema de
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 rpidamente convertido en el
nuevo servidor master. Este modelo puede ser sincrnico o asincrnico, y slo puede ser
implementado para el servidor de base de datos completo.
Trigger-Based Master-Standby Replication
Este tipo de replicacin enva todas las consultas de modificacin de datos al servidor master.
El servidor master enva asincrnicamente las modificaciones de los datos al servidor standby.
ste ltimo puede responder consultas de slo lectura mientras el servidor master esta
corriendo.
Statement-Based Replication Middleware
Con este tipo de replicacin, un programa intercepta todas las consultas SQL y las enva 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 slo lectura pueden ser enviadas a un nico servidor,
permitiendo la distribucin de carga de trabajo de lectura a travs de los servidores
disponibles.
Asynchronous Multimaster Replication
Para los servidores que no estn conectados regularmente, mantener los datos consistentes a
travs de estos es un gran desafo. Usando este tipo de replicacin, cada servidor trabaja de
manera independiente y peridicamente se comunica con los otros servidores para identificar
las transacciones conflictivas. Estos conflictos pueden ser resueltos por el usuario o por reglas
de resolucin de conflictos.
Synchronous Multimaster Replication
En este tipo de replicacin, 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 transaccin 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.

Replicacin nativa en PostgreSQL

A partir de la versin 8.3 de PostgreSQL, se incluye la funcin de enviar en forma peridica
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 versin 9.0 de PostgreSQL, se incluye la funcin de replicacin como parte de
su ncleo. El modelo que se implementa es el Transaction Log Shipping, conocido como:
Streaming Replication con la opcin Hot Standby, que permite que el/los servidores standby
puedan responder consultas de slo lectura.
Ficheros WAL
Los ficheros WAL (Write Ahead Log) son utilizados por PostgreSQL para guardar toda la
informacin 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. Tambin se utilizan
para reparar automticamente posibles inconsistencias en la base de datos despus de una
cada del servidor. Estos ficheros tienen un nombre nico y un tamao por defecto de 16 Mb.
Cada vez que ocurre una transaccin en la base de datos, se escribe en uno de estos archivos,
as, si hay algn problema, se puede recurrir a los archivos WAL para recuperar dicha
transaccin.
PostgeSQL nativamente empezo a incluir replicaciones:
PostgreSQL 8.3 Warm Standby
PostgreSQL 9.0 Hot Standby / Streaming Replication
PostgreSQL 9.1 Replicacin sincrnica ( Master Slave)
.
Warm StandBy/Log Shipping
Esta solucin viene implementada nativamente desde la versin 8.3. Se basa en l envi
peridico 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 transaccin
se efecta en la base de datos se escribe en un archivo, de esta forma si hay algn percance
con la base de datos puede recurrirse a los archivos WAL para recuperarla.

Ventajas
Muy sencillo de implementar, modificando apenas 6 lneas en los archivos de
configuracin 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.
 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 mquinas deben tener arquitecturas (32 or 64 bits) y versiones similares de
PostgreSQL.

Hot Standby/Streaming Replication

Similar a la replicacin Warm StandBy. Pero reduce la sincronizacin de las base de datos por
debajo de 1 segundo ya que se envan registros WAL en vez de los ficheros completos.
Adems 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
indexacin distinta).
Las dos mquinas deben tener arquitecturas (32 o 64 bits) y versiones similares de
PostgreSQL.

A partir de la versin 9.0, PostgreSql soporta replicacin en flujo, lo que permite a los
servidores en espera estar ms actualizados que con los mtodos anteriores de tranferencia de
archivos. Los servidores secundarios se conectan al primario, que enva los registros de WAL
cuando son generados, sin esperar a que los archivos de WAL se llenen.

Bsicamente SR (Streaming Replication) permite que exista un proceso senderen el master

que enve 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 podan archivar a otro nodo una vez se hayan completado 16 MB de
transacciones (por defecto), con lo cual si se tena una BD que cambie poco, 16 MB podan
representar un lapso de tiempo fsico importante. A partir de ahora, el lapso de tiempo se
reduce a unos pocos segundos de diferencia en el master y la/las rplicas (dependiendo el
enlace, la carga del master, etc.), con lo cual es una mejora substancial en las capacidades y
posibilidades de PostgreSQL.
Hay que resaltar que este proceso es asincrnico. Combinado con otra de las novedades de
9.0 que es la posibilidad de usar un nodo secundario (recibiendo WALs mediante SR o el
mtodo tradicional) como Slo Lectura (caracterstica llamada Hot Standby), 9.0 dio un
paso muy adelante con respecto a versiones anteriores.
Las versiones ms recientes de PostgreSql soportan varios modos de archivamiento (respaldo
continuo) y servidores en espera (standby con recupero continuo)

Replicacin sincrnica
A partir de la versin 9.1 PostgreSql soporta la replicacin sincrnica para clsteres,
permitiendo alta disponibilidad con consistencia a travs de mltiples nodos, mediante la
implementacin de clsteres de servidores PostgreSQL usando replicacin sincrnica. La
replicacin sncrnica soporta "2-safe replication" que asegura que las transacciones han sido
confirmadas por una rplica del servidor maestro, limitando grandemente la posibilidad de
perdida de datos. Solo PostgreSQL soporta replicacin sincrnica 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 Operacin:

Continuous Archiving(online backup): archivamiento continuo (respaldos de los segmentos
de WAL)
Point-In-Time Recovery (PITR): recuperacin en el tiempo (disaster recovery)
Warm-standby: archivamiento + recuperacin continua (high availability)
Hot-standby: archivamiento + recuperacin continua + consultas de solo lectura

Herramientas de replicacin para PostgreSQL

Herramientas Mtodo replicacin Sincronizacin

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

Replicacin en PostgreSQL con Slony-I

Slony-I es un sistema de replicacin asncrona para PostgreSQL del tipo Master Multi
Slave. Realiza las actualizaciones a travs de disparadores o triggers. Algunas de las
caractersticas 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 replicarn las tablas. Slony-I tambin est disponible
para versiones de PostgreSQL inferiores a la 9.0.Esta solucin, al estar basada en triggers
presenta ciertas restricciones. Entre las limitaciones de Slony-I tenemos que no puede replicar
automticamente:
Cambios realizados por una consulta DDL.
Cambios realizados a usuarios y roles.
Cambios en BLOB (Binary Large OBject Objeto grande binario)

Ventajas frente a la replicacin nativa

Interfaz visual que permite configurarlo de manera ms intuitiva.
Independiente de la plataforma de los nodos.
Permite seleccionar qu bases de datos se replicarn.
Permite seleccionar qu tablas de la base de datos se replicarn.

Desventajas frente a la replicacin nativa

No replica cambios efectuados por consultas DDL.
No replica cambios en los usuarios ni en los roles.
No puede repicar automticamente cambios a BLOBs.
Es necesario instalar software adicional.

Replicacin en PostgreSQL con RubyRep

RubyRep es una herramienta de replicacin asincrnica, basada en Ruby que permite crear
sistemasde replicacin 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 caractersticas hacen de Ruby Rep
una herramienta muy flexible que permite la integracin de distintos sistemas. Es fcil de
instalar, configurar y monitorear. Tambin es independiente del diseo 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).Adems 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 aadidas en uno de los nodos y automticamente sincronizar su
contenido. Tambin puede configurar de manera automtica 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 replicacin nativa

Independiente de plataformas y de versiones de bases de datos.
Puede ser usado en PostgreSQL y en MySQL.
Permite la replicacin Multi Master.

Desventajas frente a la replicacin nativa

Es necesario instalar software adicional.
Menor rendimiento.

Conclusiones
La replicacin 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)
 Para tener un ambiente de pruebas o desarrollo lo ms parecido al ambiente de
produccin.

Un sistema de replicacin es muy importante para una organizacin que cuenta con
informacin sensible, para aquellas que manejan grandes volmenes de datos, o para las que
utilizan acceso remoto a la informacin.

Contar con un sistema de replicacin 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