Cluster Linux y PostgreSQL

K3rnelpanic · 9 Mayo 2016

Amigazos todos.

Me tiraron un desafío :zippy

, así que estoy montando en un pequeño lab para probar el método de réplica más eficiente para una BD PostgreSQL. Cabe mencionar que esta BD estará montada en un clúster en Linux con Centos7/RHEL7, mostrando el servicio en una IP Virtual y con alta disponibilidad.

DRBD parece que es LA opción en caso de clústeres de alta disponibilidad.

Ahora viene la pregunta. Ustedes, amigos capa9veros que usan la BD del elefante.

Qué sistema de replicación tienen?
Consideran seguro DRBD por sobre un sistema de réplica en base a log transaccional?

Soy medio neófito en este asunto, pero aprendo rapido. Espíritu capa9vero :zippy

Miguelwill · 9 Mayo 2016

por lo menos la replicacion DRBD te sirve para tener un Raid 1 por red entre 2 sistemas, pero normalmente es util si quieres tener un clon igual al primero en caso de que se caiga la maquina completa, y el secundario queda como pasivo sin poder usar los datos o visualizar las db en la particion que se esta sincronizando, por lo que si el cluster puede tener mas de 2 maquinas (3 o mas), podria considerar clonar el primario, y ademas tener otro que tenga una replicacion con los log transaccionales

K3rnelpanic · 9 Mayo 2016

miguelwill dijo:
por lo menos la replicacion DRBD te sirve para tener un Raid 1 por red entre 2 sistemas, pero normalmente es util si quieres tener un clon igual al primero en caso de que se caiga la maquina completa, y el secundario queda como pasivo sin poder usar los datos o visualizar las db en la particion que se esta sincronizando, por lo que si el cluster puede tener mas de 2 maquinas (3 o mas), podria considerar clonar el primario, y ademas tener otro que tenga una replicacion con los log transaccionales

En este caso, la idea que tengo es de sólo 2 nodos (presupuesto).
Un nodo activo A corriendo PostgreSQL, si llegase a morir, que la replicación DRBD haya hecho su pega manteniendo una imágen viva del disco replicado en nodo B, que pueda migrarse a primario, asumiendo el rol y utilizando la replicación de DRBD (que sería /var/lib/pgsql) y pueda continuar entregando el servicio sin pormenores. :zippy

Zuljin · 9 Mayo 2016

Hay que invocar al vikingo @unreal4u , que ha trabajado duro con Postgres.

Tienes entonces una solución de dos servidores que forman un cluster de linux, no? Es decir, ¿dos servidores que forman un único sistema operativo y sobre él hay una única instalación de Postgres?

¿Luego quieres generar una replicación transaccional de base de datos, no? Es decir, un servidor con un sistema operativo distinto y una instalación Postgresql distinta que vaya recibiendo "cambios" del origen y los vaya aplicando.

Voy a leer algo. No cacho de postgres al detalle pero entiendo los conceptos de replicación de base de datos.

K3rnelpanic · 9 Mayo 2016

Zuljin dijo:
Tienes entonces una solución de dos servidores que forman un cluster de linux, no? Es decir, ¿dos servidores que forman un único sistema operativo y sobre él hay una única instalación de Postgres?

No. Osea sí :zippysconf

Son 2 servidores (nodo01 y nodo02) identicos en hardware y sistema, que corren pacemaker para clusterizar servicios y que éstos trabajen como clúster.
Entonces tengo

nodo01......................nodo02
DRBD........................DRBD

Estos trabajan en modo failover, por lo que hay 1 nodo activo (nodo01) que mantiene los servicios arriba, y está el otro nodo.. el standby (nodo02) que tiene los mismos servicios, pero está en modo espera, en caso de que el nodo01 decida lanzarse (a lo Jefferson).
Entonces lo que hace DRBD es mantener sincronizada a nivel de bloques la información de X particion (/var/lib/pgsql) desde el nodo01 (primario) al nodo02 (standby).

Zuljin dijo:
¿Luego quieres generar una replicación transaccional de base de datos, no? Es decir, un servidor con un sistema operativo distinto y una instalación Postgresql distinta que vaya recibiendo "cambios" del origen y los vaya aplicando.

Mi pregunta iba más a qué tipo de sistema es más eficiente para mantener una replicacion de los datos

http://www.postgresql.org/docs/9.4/...ation-solutions.html#HIGH-AVAILABILITY-MATRIX

Zuljin · 9 Mayo 2016

VittokoX dijo:
Mi pregunta iba más a qué tipo de sistema es más eficiente para mantener una replicacion de los datos

http://www.postgresql.org/docs/9.4/...ation-solutions.html#HIGH-AVAILABILITY-MATRIX

Depende un poco de tus requerimientos de negocio.

¿Cuál es la pérdida máxima de datos que pueden tolerar?
¿Cuál es el tiempo máximo que pueden estar con el sistema abajo?
¿Te sería necesario que la base de datos destino esté también dando servicios para que tú la consultes, liberando recursos de la base de datos principal?

K3rnelpanic · 9 Mayo 2016

Zuljin dijo:
¿Cuál es la pérdida máxima de datos que pueden tolerar?

Ojalá Ninguna.

Zuljin dijo:
¿Cuál es el tiempo máximo que pueden estar con el sistema abajo?

Un par de minutos, asumo.

Zuljin dijo:
¿Te sería necesario que la base de datos destino esté también dando servicios para que tú la consultes, liberando recursos de la base de datos principal?

No necesariamente, no tendrá gran carga.

A todo esto, es para implementación de un DTE. El que está corriendo stand alone, actualmente tiene un moco de carga y cerca de 90 MB en BD. Más que nada es para pasar esa plataforma a una solución que permita tener disponibilidad en caso de que cague un nodo.

Saludos don Zuljin :idolo

Cosme · 9 Mayo 2016

No le tengo mucha confianza a DRBD para este caso, encuentro que el sistema de recuperación (en caso de que falle mas de un nodo) le falta para ser "solido como roca".

K3rnelpanic · 9 Mayo 2016

Cosme dijo:
No le tengo mucha confianza a DRBD para este caso, encuentro que el sistema de recuperación (en caso de que falle mas de un nodo) le falta para ser "solido como roca".

Claro, pero viendo la malla y la $ no quieren soltar mas recursos para habilitar 3 máquinas en el clúster de BD,
A esto le sumamos que se realizan respaldos diarios de / y de /var/lib/pgsql en dataprotector así que en cierta manera se pueden reconstruir ambos nodos en caso de que caguen. Estilo Hiroshima en santiago :zippy

Zuljin · 9 Mayo 2016

Ya, estoy leyendo y en mi opinión el método más seguro es Transaction Log Shipping. Esto lo hace directamente la base de datos enviando los cambios que se realizaron en el origen.

Igual lo estoy tirando en el aire, nunca he probado estas replicaciones en Postgres así que no tengo experiencia.

K3rnelpanic · 9 Mayo 2016

Invocamos al Vikingo :idolo

Harima · 9 Mayo 2016

Me suscribo, nunca he usado cluster en postgres (si con MSSQL)

unreal4u · 9 Mayo 2016

pta los voi a decepcionar: no llegué a tanto con pgsql, pero el otro día leyendo sobre MySQL di con ProxySQL (10 SEGUNDOS de downtime + cambiar un slave por master si caga el master), y di con pg-pool II: http://www.pgpool.net/mediawiki/index.php/Main_Page que parece hacer la misma pega.

Sin embargo, no he trabajado con él así que ni idea...

Más info acá y acá.

Saludos.

Miguelwill · 9 Mayo 2016

El otro día cschureando paquetes en debían 8 pille uno que hablaba de gestionar aincronizacion de máster a máster en mysql, pero aún no e tenido tiempo para cachurear

Enviado desde mi XT1058 mediante Tapatalk

unreal4u · 9 Mayo 2016

hay hartas herramientas, Orchestrator o Percona lo hacen realmente simple.

Saludos.

K3rnelpanic · 10 Mayo 2016

Me quedo con DRBD, un par de días en prueba y ver si opera bien. Sino me voy con WAL :zippy

Miguelwill · 10 Mayo 2016

VittokoX dijo:
Me quedo con DRBD, un par de días en prueba y ver si opera bien. Sino me voy con WAL

consulta consultona: la sincronizacion de DRBD la correras sobre la misma interface de red que recibira las consultas a la DB ?
o los equipos tienen mas de una y sincronizaras de forma directa entre ellos con interfaces dedicadas ?

un split-brain en DRBD con muchas diferencias te podria obligar a hacer una full sincronizacion, y aunque el disco este vacio, te va a copiar todos los bloques de la partición :lezippy3

K3rnelpanic · 10 Mayo 2016

miguelwill dijo:
consulta consultona: la sincronizacion de DRBD la correras sobre la misma interface de red que recibira las consultas a la DB ?
o los equipos tienen mas de una y sincronizaras de forma directa entre ellos con interfaces dedicadas ?

un split-brain en DRBD con muchas diferencias te podria obligar a hacer una full sincronizacion, y aunque el disco este vacio, te va a copiar todos los bloques de la partición

Se hará a través de una interfaz independiente. Como una conexión directa entre los nodos.
Claro, pero esta topoogía no trabajará con ese sistema. El pacemaker mantendrá montado el /var/lib/pgsql sólo en un nodo. :zippy

K3rnelpanic · 24 Mayo 2016

miguelwill dijo:
consulta consultona: la sincronizacion de DRBD la correras sobre la misma interface de red que recibira las consultas a la DB ?
o los equipos tienen mas de una y sincronizaras de forma directa entre ellos con interfaces dedicadas ?

un split-brain en DRBD con muchas diferencias te podria obligar a hacer una full sincronizacion, y aunque el disco este vacio, te va a copiar todos los bloques de la partición

UPDATE

Pasé mis pruebas y el cluster anda LA ZORRA :zippyte

Ahora un par de juegos con pgbench pero la replicación de DRBD es a toda nalga

Zuljin · 24 Mayo 2016

Oye pero cuenta poh Vitoco, ¿cómo lo hiciste? ¿Qué método utilizaste?

Cluster Linux y PostgreSQL

non serviam

I am online

non serviam

Fundador

non serviam

Fundador

non serviam

Gold Member

non serviam

Fundador

non serviam

Pegao al tarro

I solve problems.

I am online

I solve problems.

non serviam

I am online

non serviam

non serviam

Fundador