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

On Wed, 17 Feb 2016 11:22:46 +0100
Ruben Fitó <r(dot)fito(at)ubiquat(dot)com> wrote:

> Gracias eduardo,
>
> Entonces, por lo que entiendo, fdw permite reestablecer conexión en
> caso de pérdida de comunicacion, sin necesidad de gestionar-lo
> nosotros??

A ver, fdw no es para tener HA ni backups ni nada similar de forma estable. fdw permite conectar un servidor postgresql con una fuente de datos, sea esta un postgres, un servidor ldap, sqlserver, odbc, archivo csv... lo que sea. Para cada fuente de datos necesitas un modulo fdw que implemente la lectura, escritura o ambas.

En el caso de postgres_fdw que te he mencionado, te permite, desde un servidor postgres (tu servidor central), ejecutar consultas en otro servidor postgres (cada una de las tiendas), ya sean de lectura (selects) o escritura (update, delete, insert).

En lugar de tener un streaming replication funcionando continuamente en todas las tiendas hacia el servidor central, la sugerencia que te he hecho es, conectar mediante postgres_fdw tu servidor central con cada una de las tiendas, lanzar las queries que necesites (1)(2) y actualizar la BD Central con los resultados de dichas queries. Ventaja, no necesitas estar continuamente conectado ni dependes de no perder un solo archivo de Wal, pudiendo abrir/cerrar la conexion cuando quieras. Desventaja, no guardas la ultima version de los datos de cada tienda, solo hasta la ultima vez que te conectaste. Puedes abrir/consultar/cerrar cada 5 minutos por ejemplo o una vez al dia.

(1) SELECT * FROM compras_realizadas AS c WHERE c.compra_id > Ultima_compra_id_en_Servidor_Central; Obtener la lista de las compras realizadas desde la ultima comprobacion. Puedes incluirlo en un INSERT en la BD de central para tener copia de dichos datos.

(2) UPDATE precios SET precio_clientes_vip = precio_clientes_vip*0.95; Baja los precios de las ofertas un 5% para clientes Vip en la tienda donde hacemos la consulta.

> Si es asi, entonces fdw es una gran opción.
>
> Sin embargo, surgen otras dudas:
>
>
> - El hecho de crear una especie de "Read Only" en la tienda no es
> posible. Creemos que podemos solucionarlo con roles y/o permisos.
> Es correcto?

Hasta donde yo se, si. No obstante cualquier persona con acceso a la maquina y con cuenta de usuario postgres o root puede cambiar eso.

> - La experiencia nos dice que las tiendas tienen un máximo de
> desconexión de pocas horas. Durante este tiempo podemos tener
> varios cambios en las configuraciones de tiendas de la BD
> centralizada, cómo soluciona esto fdw?? Claro, el "Streaming
> Replication" va acumulando estos cambios hasta poder aplicarlos a la
> BD réplica. (Esos maravillosos WAL, jejej)

Intentando reconectar de forma automatica hasta tener "señal", aplicar los cambios e intercambiar datos.

> - Por lo que hemos visto, añadir/quitar/modificar, nombres de
> tablas, columnas, funciones, etc... Con fdw también es algo que
> debemos hacer manualmente para todas las BD de las tiendas. Es
> correcto?

Completamente automatizable, bien por funciones en pl u otro lenguaje en el servidor.

> Perdonen tantas preguntas, su experiencia es la mejor de las
> documentaciones.
>
> PD: Aun estamos estudiando las otras opciones: -> XDB replication
> server de EDB, symmetricds , UDR, BDR, pglogical....

Como te he dicho arriba, fdw NO equivale a un backup o ha. Es una herramienta completamente ortogonal a ambas y actua a nivel distinto.

> Un saludo

Saludos

--- ---
Eduardo Morras <emorrasg(at)yahoo(dot)es>

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