réplication base multi-master

**pdelorme** · 15/06/2009, 15h58

bonjour,

J'ai une base de donnée qui est accédé de plusieurs endroits dans le monde. certain de ces endroits bénéficie d'une bande passante très faible, ce qui rend l'accès directe à la base impraticable.

Pour résoudre se problème de temps de réponse, j'imagine de répliquer ma base sur les différents lieux d'accès. Les accès seraient alors locaux et rapide.

La base doit être modifiable depuis toutes ses réplications et les changements doivent être synchronisés de sorte a ce que mes bases soient (a peut près) toujours les même à un temps t.

Je cherche donc un mécanisme de réplication postgres qui :
- supporte plusieurs bases maitre (2 pour l'instant).
- synchronise les données d'une base à l'autre.
- ne bloque pas les accès durant la synchronisation.
- ne soit pas nécessairement temps reél.
- ne "gache" pas la bande passante.

j'ai jeté un oeuil à pgCluster mais j'ai c'est pas très clair

des idées, du vécu?

merci

Patrice.

**scheu** · 15/06/2009, 17h32

Je ne pense pas que Postgresql, dans les versions actuelles, propose des outils pour faire ce genre d'architecture évoluée
Tu as éventuellement les dblinks mais ça voudrait dire que pour chaque insert/update/delete sur 1 maître, il faudrait un trigger qui le réplique via dblink ... Ca deviendrait vite une usine à gaz ...

C'est à mon avis en tout très difficile de faire du synchrone avec Postgresql

**SQLpro** · 16/06/2009, 15h31

Ce que vous recherchez c'est faire une réplication de fusion. Ce n'est peut être pas implémenté sous PG. Mais vous pouvez le faire à la main. Ceci dit cela représente beaucoup de travail pour réaliser une telle chose alors que certains SGBDR proposent cela en standard (MS SQL Server).
En effet il faut entre autre :
1) ajouter une colonne avec un GUID dans toutes les tables répliquées
2) prévoir 3 triggers (INSERT + UPDATE + DELETE) dans chacune des tables répliquées
3) centraliser les mises à jours distribuées dans une base (qui servira aussi pour la gestion des conflits)
4) prévoir que les clefs auto incrémentée ne se recoupent pas (gérer les auto incrément par plage ou modulo)
5) introduire une gestion des conflits de réplication (qui gagne en cas de MAJ des deux côtés).

Bref, quelques mois de développement au minimum pour réaliser tout cela et un bon DBA pour gérer les conflits et surveiller la charge.

A +

**pdelorme** · 17/06/2009, 10h11

SQLPro, savez vous ou je peux trouver de la documentation sur le sujet?
cette approche m'intéresse.

quelles sont les solutions pour la résolution des conflits?
je pense notamment aux contraintes d'unicités et aux intégrités référentielles mises à mal par une suppression d'un coté et un ajout de l'autre.

merci,

P.

**SQLpro** · 17/06/2009, 12h16

SQLPro, savez vous ou je peux trouver de la documentation sur le sujet?

Fouillez le net avec les mots clef MERGE REPLICATION.

quelles sont les solutions pour la résolution des conflits?

Il s'agit de régles métiers à implanter dans le SGBDR. malgré cela il faut un outil de gestion des conflits.

Exemple : règle métier = données la plus récente. Si data1.datatimeRefresh = data2.datatimeRefresh alors, faire tomber les tuples dans une base de gestion de conflit et demander au DBA comment il arbitre.

Compter 3 à 6 mois de développement pour un spécialiste SQL... Bon courage !

PS : ceci existe en standard dans SQL Server....

A +