Re: Replicacion asincrona de base de datos en vez de cluster

From: Ruben Fitó <r(dot)fito(at)ubiquat(dot)com>
To: Ernesto Quiñones <ernestoq(at)gmail(dot)com>
Cc: jaime(dot)soler(at)gmail(dot)com, "pgsql-es-ayuda(at)postgresql(dot)org" <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: Replicacion asincrona de base de datos en vez de cluster
Date: 2016-02-17 09:31:57
Message-ID: CANiYpQz+uXw=zBAgGOMo_sP5MF=vPFwwkC3UcTFu+qQ1kutfgg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Gracias lista por sus aportaciones,

Para resolver dudas, os explico qué queremos:

Tenemos un gran grupo de tiendas(TPV, POS,...) que han de ser instaladas i
configuradas para que funcionen.

Nuestro principal objetivo es que esa configuración se pueda modificar de
manera centralizada, por ejemplo des de una WEB de gestión. Al mismo tiempo
deseamos que haya una "sincronización real-time", para no tener que crear
un proceso batch que vaya sincronizando cada x tiempo.

Montando un "streaming replication" por cada tienda obtendríamos ese
resultado, haciendo que haya un cluster master(en el servidor) i una read
only(en la tienda) por cada tienda. Pero claro, esto es un dolor de cabeza,
si tenemos 50 tiendas, deberíamos montar 50 clústers en el servidor.

Y ahora me preguntaréis, porqué tantos clústers?? La respuesta es que se
desea que cada tienda sólo tenga una única configuiración, desean que todo
vaya por separado. En caso contrario, montaríamos un solo master y tantos
esclavos como hicieran falta.

Con streaming replication seria una faena tediosa, configuración de
clústers, etc. A parte de que la WEb de gestión tendría que acceder a
todos los clústers, bla, bla bla.

En resumen, hemos pensado que estaria bien tener un único master, y
sincronizar con la base de datos de la tienda, pero sólo de su
configuración(su propia BBDD, o tabla, o ...).

Lo que nos entusiasma de "Streaming Replication" es la estabilidad,
efectividad i gran confianza que nos da, pero no sabemos si existe algun
proceso de sincronización parecido sólo para base de datos, tablas, etc..

No sé si he podido expicarme mejor.

Un saludo

2016-02-16 17:23 GMT+01:00 Ernesto Quiñones <ernestoq(at)gmail(dot)com>:

> yo no usaría DBLinks para generar réplicas de datos, sería muy lento,
> mejor es irse a replicación Asíncrona, Síncrona podría hacer tu sistema
> lento.
>
> saludos
>
> El 16 de febrero de 2016, 9:41, jaime soler <jaime(dot)soler(at)gmail(dot)com>
> escribió:
>
>> El mar, 16-02-2016 a las 14:02 +0100, Ruben Fitó escribió:
>>
>> Buenos dia lista,
>>
>> Para empezar, tenemos un sistema de replicación "Streaming replication"
>> con postgresql 9.3.
>>
>> Hemos comprovado que este sistema es estable y que aguanta caídas de
>> varias horas (segun hemos configurado).
>>
>> Ahora tenemos intención de hacer algo parecido pero no por clúster sino
>> por diferentes bases de datos por un mismo cluster.
>>
>> Hemos estado buscando en la documentación y hemos visto que existen
>> diferentes módulos de sincronización como dblink o pg_fwd, pero no hemos
>> podido comprovar su eficacia.
>>
>>
>> Conocéis algun sistema de sincronización parecido al que necesitamos??
>>
>>
>> Si te refieres a replicar de determinadas bases de datos, y no todo el
>> cluster. Streaming replication no es una opción y tendrás principalmente
>> dos opciones:
>> - replicación asíncrona basada en mecanismos de triggers:
>> * maestro- esclavo tipo slony, XDB replication server de EDB,
>> symmetricds
>> * multimaestro: bucardo
>> - replicación lógica de manera asincrona
>> * maestro-esclavo, si es en una dirección puedes usar UDR o pglogical
>> * multi-maestro: BDR
>>
>> un saludo
>>
>>
>> Un saludo
>>
>> --
>> *Ruben Fitó *
>> Software Engineer
>> r(dot)fito(at)ubiquat(dot)com <j(dot)catarineu(at)ubiquat(dot)com>
>> www.ubiquat.com
>> Tota la informació continguda en aquest document i arxius adjunts és
>> CONFIDENCIAL protegida per llei de secret comercial. Si l'ha rebut per
>> error, si us plau elimini'l i posi's en contacte amb l'emissor.
>>
>> All information contained in this document and any attachments are
>> CONFIDENTIAL and protected under trade secret laws. If you receive this
>> message by mistake, please delete it and notify it immediately to the
>> sender.
>>
>>
>
>
> --
> ----------------------------------------------------------
> Visita : http://www.eqsoft.net
> ----------------------------------------------------------
> mi Twitter : http://www.twitter.com/ernestoq
> mi Blog : http://www.eqsoft.net/blog2
> mi LinkedIn: https://pe.linkedin.com/in/ernestoq
>

--
*Ruben Fitó *
Software Engineer
[image: Ubiquat Technologies, SL]
r(dot)fito(at)ubiquat(dot)com <j(dot)catarineu(at)ubiquat(dot)com>
www.ubiquat.com
Tota la informació continguda en aquest document i arxius adjunts és
CONFIDENCIAL protegida per llei de secret comercial. Si l'ha rebut per
error, si us plau elimini'l i posi's en contacte amb l'emissor.

All information contained in this document and any attachments are
CONFIDENTIAL and protected under trade secret laws. If you receive this
message by mistake, please delete it and notify it immediately to the
sender.

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Eduardo Morras 2016-02-17 09:46:13 Re: Replicacion asincrona de base de datos en vez de cluster
Previous Message lodopidolo 2016-02-17 08:50:11 Re: OT: Diseño de Venta de Productos para market