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

Buenos dias,

Gracias Horacio por tu respuesta,

Efectivamente necesitamos un sistema "OFFLINE" en la tiendas.

La arquitectura inicial que habíamos planteado con "Streaming Replication"
era:

*BBDD* *SERVER* *TIENDA*
Configuración RW -> RO
Transacciones RO <- RW

Según este esquema tenemos que, por cada TIENDA, necesitamos 2 BBDD con sus
réplicas para 2 objetivos distintos: Configuración i Transacciones.

En caso de la BBDD de configuración, la RW se encuentra en nuestro server i
la réplica en la tienda. Esto nos permite:

- Configurar la tienda de manera centralizada.
- Des de la BBDD de la tienda nunca se podran modificar los datos.
- Siempre tendremos una sincronización "real-time" de ese modo evitamos
procesos batch, triggers, entre otros, que tengan que actualizar la BBDD de
la tienda.

En caso de las transacciones pasa lo mismo pero des de la otra dirección:

- La tienda va apuntando las transacciones i en "real-time" se
sincroniza con el la BBDD del server.
- Des del server no se podran hacer manipulaciones de transacciones.
Algo muy interesante en nuestro mundillo.
- El server recibe, de forma centralizada, todos los datos de todas las
tiendas.

En realidad, esta arquitectura son todo ventajas, exceptuando la gran
complejidad de configurar i mantener 2 clústeres en server i 2 en tienda,
por cada tienda.

Por parte de la tienda, una vez creados los 2 clústeres, ya no hay que
hacer mucho mas, pero por el lado del servidor, gestionar, configurar,
acceder i mantener 2 clústeres por las 56 tiendas que tiene la empresa es
una barbaridad de trabajo y recursos.

Lo ideal seria que sólo haya un único cluster en el servidor i uno en cada
tienda.

Por ello, estamos buscando alternativas al "Streaming Replication" que
puedan darnos las mismas garantias:

- Sincronización Asíncrona. (Qué rara esta frase, jejejeje)
- Que se sincronizen todos los cambios hechos, no sólo por cada conexión.
- Que sean BBDD RO.
- Gestión cero, por nuestra parte, para restablecer conexión.
- Garantizar la integridad de datos, concurrencia, etc..
- Evitar deadlocks.
- Y más...

Entendemos que un "Streaming Replication" es como una copia en
binario(archivos WAL) de todo lo sucedido en la base de datos, y que no es
posible hacer una replicación por un subconjunto de datos diferentes.

Por este motivo, os pedimos consejo, ya que las alternativas(fdw, dblink)
por ahora analizadas, no cumplen con nuestros requisitos.

Gracias.

Un saludo

2016-02-18 5:10 GMT+01:00 Horacio Miranda <hmiranda(at)gmail(dot)com>:

> On 2/17/2016 2:02 AM, Ruben Fitó wrote:
>
>> 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.
>>
>>
> Estoy un poco confundido, quieres replicar parcialmente de una base de
> datos a otra ?
>
> 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 comprobar su eficacia.
>>
>>
> Según los otros email creo que lo que necesitas es tener dos bases de
> datos ( una replicada ) y otra local. Los cambios se hacen en la base de
> datos local y la base de datos local tiene permisos read_only hacia la base
> de datos que quieres replicar.
>
>
>> Conocéis algún sistema de sincronización parecido al que necesitamos??
>>
>
> Creo que streams desde la base de datos central hacia las tiendas ( creo
> que quieres tener la capacidad de vender offline ).
>
> Y cuando la tienda se vuelva a conectar tener un proceso de consolidación
> que empuje los cambios o ventas de la tienda hacia el repositorio central (
> trata de tener la menos cantidad de tablas posible en la segunda base de
> datos ).
>
> Yo haría crearía tablas con una estructura como ( ventas_POS01,
> detalle_venta_POS01) en el punto de venta POS01.
>
> Este es el objetivo que quieres alcanzar, la capacidad de poder vender
> cuando los enlaces se caigan ?
>
> PS: Las sucursales que están cerca las puedes radio enlazar si tienen
> linea vista. Hay antenas que llegan a 45 kilómetros, en lo persona solo eh
> probado antenas a menos de 3KM.

--
*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.