Discussion :

[dany_dane]

Bonjour,

Je cherche un moyen de synchroniser deux base de données dans un environnement réseau.
C'est à dire que je dispose d'une base A qui doit synchroniser une base B tous les jours.
Avez vous des pistes pour réaliser cette opération sur des base de données Postgresql par exemple.
Le cas échéant, quel autre SGBD me permettra de faire cela aisement.

Merci d'avance.

[kain_tn]

Bonsoir.


Ta réplication se fait une fois par jour uniquement? Elle est donc asynchrone?
La base B doit-elle être disponible en lecture ou est-ce seulement une sauvegarde?

[dany_dane]

Oui disons que une fois par jour sera suffisant. ça ne sera pas une réplication sur toute la base de donnés, mais seulement sur des tables bien ciblées et la base B est effectivement utilisée en lecture aussi.
Juste un exemple de cas concret pour lequel j'articule mon besoin fonctionnel :
J'ai des commerciale qui sont en déplacement et vendent des produits, et il enregistre tout ça en local sur leur pc portable(information sur le client entre autre), ils doivent donc disposer d'une base de donnés sur leur postes, et donc à la fin de la journée ils doivent transférer tout leur donné dans la base de donnée central de la boite.

=>Techniquement quel est le moyen le plus simple de mettre cela en œuvre avec Postgresql? Le cas echeant, si c'est trop compliquer avec pgsql, y a t-il d'autre sgbd ou concept permettant de faire cela aisément?

[scheu]

Je pense que le plus simple est encore de faire un export/import des tables que tu veux répliquer, en utilisant la commande pg_dump
Ca c'est si ton besoin est juste de copier/écraser quotidiennement les tables de la base A vers la base B

Après si par "synchronisation" tu entends intégrer dans la base B les données de la base A qui n'y sont pas ou qui ont été modifiées (insert ou update), tu peux utiliser les dblinks et les triggers sur insert/update/delete, mais ça va vite devenir une usine à gaz ...

[SQLpro]

Oui disons que une fois par jour sera suffisant. ça ne sera pas une réplication sur toute la base de donnés, mais seulement sur des tables bien ciblées et la base B est effectivement utilisée en lecture aussi.
Juste un exemple de cas concret pour lequel j'articule mon besoin fonctionnel :
J'ai des commerciale qui sont en déplacement et vendent des produits, et il enregistre tout ça en local sur leur pc portable(information sur le client entre autre), ils doivent donc disposer d'une base de donnés sur leur postes, et donc à la fin de la journée ils doivent transférer tout leur donné dans la base de donnée central de la boite.

=>Techniquement quel est le moyen le plus simple de mettre cela en œuvre avec Postgresql? Le cas echeant, si c'est trop compliquer avec pgsql, y a t-il d'autre sgbd ou concept permettant de faire cela aisément?

Ce que tu demande c'est de la réplication et dans ton cas elle est à flux multiples, voir full duplex. Faire des imports exports est hautement casse gueule...

Il faut un flux descendant du serveur central vers les portables pour les nouveaux produits et les modif de tarif, et un flux montant pour les clients et commandes.

Il existe différentes techniques pour ce faire :
1) capturer les transactions qui ont lieu sur le portable et les reproduire sur le central (c'est le moyen le plus sûr). Mais c'est complexe car il faut un outil de lecture du journla des transactions.
2) effectuer des clichés des données (photocopie des données des tables) et les appliquer en retour aux abonnés (en général cela se fait de manière binaire avec des outils spécifiques).
3) utiliser les déclencheur placés dans chacune des tables à répliquer, afin capturer les données qui évoluent (INSERT, UPDATE et DELETE) et alimenter des tables tampon qui vont aller ensuite modifier le contenu de la cible. C'est le principe, de réplication par fusion.
Dans ce dernier cas il y a des possibilité de conflits de réplicationj, si la réplication est bilatérale (FULL DUPLEX). Il faudra donc un moniteur de réplication pour gérer les conflits.

Sans outils spécifique cela est à la fois complexe et couteux en terme de développement.

Il existe des SGBDR qui incorprorent tous ces outils ainsi qui divers assistants pour mettre en place de telles choses, comme Oracle ou plus simplement SQL Server...

A +

[dany_dane]

Après si par "synchronisation" tu entends intégrer dans la base B les données de la base A qui n'y sont pas ou qui ont été modifiées (insert ou update), tu peux utiliser les dblinks et les triggers sur insert/update/delete, mais ça va vite devenir une usine à gaz ...

Oui c'est exactement cela dont j'ai besoin, uniquement de prendre en compte les nouvelles données de la base A vers le central.
Vriament pas mal les triggers, j'y avais pensé mais je me suis dit qu'éffectivement ça allait devenir vite complexe... et je prefere etre sûr avant d'adopter cette solution, il ne doit pas y avoir de risque possible.

"Il faut un flux descendant du serveur central vers les portables pour les nouveaux produits et les modif de tarif, et un flux montant pour les clients et commandes."

Oui effectivement, ce cas est à prendre en compte, mais l'autre est plus préocupant car le besoin est quotidien.
J'abdandonen tes 2 premieres options que je ne capte pas très bien. + 1 pour ta 3 eme solution qui rejoint celui de scheu...

Il existe des SGBDR qui incorprorent tous ces outils ainsi qui divers assistants pour mettre en place de telles choses, comme Oracle ou plus simplement SQL Server...

Sinon c'est intéressant ce que tu dis apr rapport aux autres sgbd, je ne savais pas que sql server permettait de faire cela, en effet j'ai aussi la possibilité d'utiliser ce SGBD, peut-tu m'en dire un peu plus? Existe t-il des tuto sur le site qui en parle?

[scheu]

Je rejoins SQLPro en te conseillant d'utiliser les fonctionnalités des SGBDs qui le permettent en natif (Postgresql n'en fait pas partie à ma connaissance), plutôt que de développer ta propre usine à gaz avec dblinks, triggers, etc ... qui sera long, coûteux et difficile à maintenir

[SQLpro]

J'abdandonen tes 2 premieres options que je ne capte pas très bien. + 1 pour ta 3 eme solution qui rejoint celui de scheu...

Entre nous le 3e mode (réplication de fusion avec des déclencheurs) est le pire dans tous les sens du terme :
1) aucune garantit de conservation de l'intégrité de la base
2) conflit de réplication possible indécidable
3) administration lourde
4) importantes ressources à prévoir tant sur le serveur que les postes client.

le mieux est la réplication transactionnelle qui ne possède aucun des inconvénients cités, mais interdit les flux full duplex, ce qui n'est pas le cas a priori dans ton modèle.

Sinon c'est intéressant ce que tu dis apr rapport aux autres sgbd, je ne savais pas que sql server permettait de faire cela, en effet j'ai aussi la possibilité d'utiliser ce SGBD, peut-tu m'en dire un peu plus? Existe t-il des tuto sur le site qui en parle?

présentation générale :
http://msdn.microsoft.com/fr-fr/library/ms151198.aspx

Ressources diverses :
http://technet.microsoft.com/fr-fr/l...SQL.90%29.aspx

En particulier dans ton cas :
http://technet.microsoft.com/fr-fr/l...SQL.90%29.aspx

je te conseille cependant de bien étudier ton scénario et de faire une maquette, et enfin de TOUT scripter à la fin, car retirer une réplication ou la reporter sur une autre machine en cas de panne est très complexe !
Investir aussi dans l'ouvrage sur la réplication aux éditions Apress.

A +

[dany_dane]

Ok merci pour vos réponses, je pense me trourner vers sql serveur alors
Il me semble que Mysql est capable de le faire : http://dev.mysql.com/doc/refman/5.0/fr/replication.html
Bizarre que Mysql fait de la réplication et pas pgsql qui est réputé plus robuste, non?

[scheu]

Apparemment si ça existe aussi sous Postgresql, c'est possible avec Bucardo, que je n'ai jamais testé personnellement. Il semble que tu puisses faire de la réplication maître/maître