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

Programas como slony [0] tienen la granularidad (para replicar) de una tabla. Bien podes tener una replica en el sentido "server -> tiendas", en convivencia con otra "tienda -> server". El chiste es que este ultimo caso no es, tecnicamente, replicacion, sino que mas bien es un conglomerado de datos, donde todos los datos de las tiendas se acumulan en el server central.

Si usas el mecanismo de "particionado" [1], podes particionar por el campo "tienda_id". Luego lo que vas a replicar son cada particion (hacia la particion correspondiente en el master). De este modo podes usar slony sin demasiados problemas.

HTH
Gerardo

[0] http://slony.info/
[1] http://www.postgresql.org/docs/current/static/ddl-partitioning.html
----- Mensaje original -----
> De: "Ruben Fitó" <r(dot)fito(at)ubiquat(dot)com>
> Para: "Horacio Miranda" <hmiranda(at)gmail(dot)com>
> CC: pgsql-es-ayuda(at)postgresql(dot)org
> Enviados: Jueves, 18 de Febrero 2016 6:01:22
> Asunto: Re: [pgsql-es-ayuda] 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
> Ubiquat Technologies, SL
> r.fito @ub iquat.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.

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripcin:
http://www.postgresql.org/mailpref/pgsql-es-ayuda