Nous recherchons également

nextamp/ = 5 Mai, 2006 - 10:44

Nous recherchons également à mettre en place d'un serveur multi-site collectant les données de sites distant via une mise à jour automatiquement (batch de nuit dans un 1er temps). Les sites distant ont des architectures strictement identiques mais gère des données locales (donc différentes). Si possible, on veut que les échanges réalisés soient limités en taille et donc éviter de tout rapatrier à chaque fois.
Nous avons naturellement été attiré par l'archivage WAL (PITR). Mais après une étude assez poussée, il s'est avéré que cette technique est ectuellement difficilement applicable à notre problème (configuration de multiples restaurations sur un meme base impossible, segments WAL assez gros...).
Quelle est la méthode que vous avez finalement mis en place?
Vu le peu de doc sur le sujet, nous sommes intéressé par toutes les expériences même si le contrat des échanges limités n'est pas respecté.
Merci
Hugues

Puisque tu mets une base de d

sparky/ = 5 Mai, 2006 - 16:10

Puisque tu mets une base de données à jour avec 4 bases de données, chaque table qui sera modifiée ou recevra de nouveau record devrait avoir un trigger pour mettre à jour une table d'échange, ce sont ces tables d'échanges qui synchroniseront le server principal. Il n'y a pour l'instant aucun autre moyen à moins de bricoler qq'chose dans Slony (1 Master vers plusieurs slaves) et de faire l'inverse (Plusieurs Master pour 1 slave)

Bonjour, Ce que nous met

Jean-Paul Argudo/ = 7 Mai, 2006 - 11:24

Bonjour,

Ce que nous mettons en place pour l'un de nos clients est effectivement basé sur Slony-I, nous n'avons pas trouvé de meilleure alternative. La solution ne peut pas être basée sur les WALs, étant donné qu'ils ne sont pas différentiables d'un serveur à un autre.

Il s'agit dans bien des cas de ce que j'appelle le principe d'"infocentre", qu'on peut adapter à plusieurs solutions, et qui consiste à avoir chaque base de données de production en maître et un unique esclave, qui est la base "infocentre":

• chaque "base de production" doit avoir le même schéma
• une base de données centrale, dite "infocentre", contient dans son schéma public, un ensemble de vues (en UNION) vers les différentes tables homonymes des schémas de production répliqués en local vers les autres schémas (une vue de public "toto" = select de toutes les tables "toto" en union de chaque schéma...)
• chaque base dite de "production" existe dans un schéma au nom de la machine (hostname), sur chaque machine de production
• grâce à Slony-I, chaque schéma de production est répliqué vers un schéma du même nom dans la base de l'infocentre

Ainsi chaque base de données de production est un maitre Slony-I, et la base dite "infocentre" est l'unique esclave du réseau...
Par contre, pour des raisons techniques, il convient de répliquer des schémas de nom identiques. Je pense que vous comprendrez pourquoi en lisant la doc de Slony-I.

Enfin, parmis les avantages de la solution, on peut dire qu'en cas de crash de l'une des bases de production, on peut la restaurer par dump du schéma de production correspondant dans la base "infocentre". Il n'est en effet pas vraiment souhaitable d'élire la base "infocentre" en maître ;-)

--
Jean-Paul ARGUDO
www.dalibo.com