La replicación en streaming fue una de las funcionalidades más importantes que se introdujeron en PostgreSQL en los últimos años. La ides es usar el log de transacciones de PostgreSQL (WAL) para sincronizar un número arbitrario de servicios y replicar los datos dentro de un cluster. En PostgreSQL, se puede hacer una replicación sincrónica y asincrónica. Usted puede decidir qué método es más beneficioso acorde a sus necesidades.

Replicación asincrónica en PostgreSQL

En el caso de una falla grave del servidor, es una buena idea tener un servidor standby (réplica) del primario (master) a mano. Afortunadamente, PostgreSQL ofrece los medios para alcanzar exactamente eso. Los administradores pueden crear réplicas de sólo lectura de un servidor primario de una manera sencilla y utilizar replicas standby para varios propósitos, tales como:

  • Backups continuos
  • Failovers automáticos
  • Escalamiento de tareas de trabajo read-only
  • Alcanzar geo-redundancias

La replicación asincrónica es el método estándar en PostgreSQL y ofrece una manera rápida y confiable de distribuir datos y hacer sus sistemas más robustos ante fallas.

La mayor ventaja de la replicación asincrónia es un overhead bajo, simplicidad y roboustez. Como resultado, la replicación asincrónica es la solución ideal para la replicación automática y para redundancias a nivel empresa.

¿Cómo funciona la replicación asincrónica?

Si está corriendo una replicación asincrónica, los datos pueden arribar al servidor standby DESPUÉS de que la transacción haya sido confirmada (commited) en el servidor principal. Normalmente existe una pequeña demora en la replicación, lo que puede causar (normalmente) una pérdida de datos menor en el caso de una falla grave.

Replicación sincrónica y asincrónica en PostgreSQL

En muchos casos, esto está totalmente aceptado, porque la replicación asincrónica promete poco sobrecoste (overhead) y no impacta en la performance del servidor primario.

Replicación en cascada

En PostgreSQL también existe la alternativa de hacer réplicas a varios servidores standby o incluso usar los standby para replicar hacia otros servidores secundarios (replicación en cascada). La replicación en cascada es útil si está buscando una replicación PostgreSQL geográficamente distribuida.

Un ejemplo

Su base de datos principal está en Nueva York, EEUU y se quieren generar réplicas en Frankfurt, Stuttgart, Berlin y Múnich. Si todas las réplicas están directamente ligadas a la base de datos principal en Nueva York, la información será enviada a través del atlántico cuatro veces. En este caso, la replicación en cascada podría ser una buena alternativa, ya que podría hacer que Frankfurt sea la única réplica directamente ligada a la base de datos primaria en Nueva York y que dicha réplica alimente a todas las demás que están dentro de Alemania.

Replicación sincrónica en PostgreSQL

Si no está en condiciones de correr el riesgo de perder un solo COMMIT, debería considerar la replicación sincrónica. En PostgreSQL, se pueden replicar sincrónicamente todos los servidores standby que se deseen. En dicho caso, un COMMIT es sólo valido si fue confirmado por todos los servidores PostgreSQL utilizados.

La replicación sincrónica asegura la máxima seguridad posible para sus transacciones porque si un servidor falla no puede ocasionar pérdida de datos.

¿Cómo funciona la replicación sincrónica?

Se asegura que no se pierdan datos.

Replicación sincrónica y asincrónica en PostgreSQL

Una transacción puede volver sólo si hay una cantidad suficiente de servidores standby que hayan confirmado la escritura en sus discos.

Funcionalidades avanzadas: quorum COMMIT

Con la introducción de PostgreSQL 10.0, incluso los métodos de COMMIT más sofisticados son soportados. Uno de los más notables, es el «quorum commit»

FIRST num_sync (standby_name [, …]) ANY num_sync (standby_name [, …])

La idea es otorgar a desarrolladores y administradores un un mayor control a la hora de configurar réplicas.

Ayuda profesional

Contáctenos hoy para recibir su oferta personal de CYBERTEC. Ofrecemos entregas a tiempo, tratamiento profesional y 20 años de experiencia en PostgreSQL.

Contáctenos