Forums PostgreSQL.fr

bebert73

Membre

precautions a prendre en vue d'une future réplication des données

Bonjour,

Pour l'instant je n'en suis pas encore au stade de la réplication, par contre je me demande s'il y a des précautions à prendre (par exemple dans le choix des clés primaires) si on sait que dans le futur on veut répliquer des données.

Voilà ce que je souhaite faire.

Supposons une base comprenant notamment une gestion de contacts (une table des tiers, avec les téléphones, etc... etc... bref tout à fait classique). Comme clé primaire de ma table "tiers", j'ai choisi un SERIAL.

Il est possible qu'à l'avenir je veuille avoir une base "décentralisée" sur mon ordi portable, pour pouvoir continuer à travailler même sans connexion sur le serveur.

Quel est le meilleur outil pour gérer la réplication entre le serveur et le portable dans ce cas ? Notamment, je me pose des questions du genre : supposons qu'au moment de la synchronisation, le dernier SERIAL utilisé soit par exemple le n° 1234. Que se passe-t-il si je crée un nouveau tiers sur mon ordi portable (qui aura donc le n° 1235), et que pendant ce temps quelqu'un créé un autre tiers sur le serveur (qui aura donc aussi le n° 1235) ? Que va-t-il se passer lors de la réplication suivante ? Y-a-t-il des outils de réplication qui gèrent automatiquement ce cas de figure,  ou bien faut-il prendre d'ores et déjà des précautions dans le choix des clés primaires (par exemple avoir comme primary key une combinaison du serial et du username, ou un truc du genre...)

gleu

Administrateur

Re : precautions a prendre en vue d'une future réplication des données

Ce que vous essayez d'avoir, c'est deux serveurs en écriture. Très (très très) compliqué.

À mon avis, les deux seuls outils qui permettent ça sont bucardo et rubyrep. J'aurais plutôt tendance à considérer bucardo mais je vous préviens tout de suite, ça ne va pas être simple à mettre en place.

---

Guillaume.

bebert73

Membre

Re : precautions a prendre en vue d'une future réplication des données

Merci Guillaume, oui c'est ce qu'il me semblait, il faut gérer cela au niveau de l'application.

Par contre en faisant une recherche sur "bucardo" je suis tombé sur ce post http://forums.postgresql.fr/viewtopic.php?id=260 qui traite de la même problématique et dans lequel vous disiez carrément que

Non, ça n'existe pas, quelque soit le moteur de base de données...

Autre question, quel est l'apport d'un outil comme bucardo par rapport à une programmation purement manuelle ? Je veux dire, dans l'absolu ça doit pas être si compliqué que ça à faire manuellement, il suffit de faire des triggers ON INSERT/UPDATE/DELETE qui écrivent dans une table spécifiquement prévue à cet effet les clés primaires des données à répliquer lors de la prochaine synchro. Lors de la synchro il suffira ensuite de répliquer les données en question, en changeant éventuellement les valeurs des clés primaires dans certains cas (cas où la clé est une séquence). Ca me semble tout à fait faisable manuellement, quel serait l'apport d'un outil comme Bucardo et/ou Rubyrep dans ce cas ?

Dernière modification par bebert73 (15/06/2011 19:38:13)

gleu

Administrateur

Re : precautions a prendre en vue d'une future réplication des données

ça doit pas être si compliqué que ça à faire manuellement

Détrompez-vous, c'est un enfer. C'est pourquoi certains ont codé des outils utilisés par un très grand nombre : Slony, Londiste, Bucardo. L'avantage de Bucardo par rapport aux deux autres est qu'il permet le maître/maître.

quel serait l'apport d'un outil comme Bucardo et/ou Rubyrep dans ce cas ?

Le même que de ne pas recoder PostgreSQL. C'est un gros travail qui a déjà été fait par d'autres. Ils sont tombés dans des tas de problèmes qu'ils ont résolu dans le temps. Vous voulez le coder vous-même ? très bien, il n'y a aucune raison pour que vous n'y arriviez pas... avec beaucoup de temps et d'effort.

Le plus gros problème dans le cas du maître/maître est de gérer les conflits. Que doivent faire les moteurs lorsqu'ils se synchronisent si deux éléments ont le même identifiant ?

---

Guillaume.

bebert73

Membre

Re : precautions a prendre en vue d'une future réplication des données

Le plus gros problème dans le cas du maître/maître est de gérer les conflits. Que doivent faire les moteurs lorsqu'ils se synchronisent si deux éléments ont le même identifiant ?

Justement, c'est dans ce sens que je pensais qu'il serait peut-être plus simple de le faire manuellement... Comment un outil "généraliste" tel que bucardo peut-il régler les conflits ? A priori, la résolution des conflits ne peut se faire qu'au cas par cas, en fonction de la logique applicative, non ?

Par contre j'ai un autre cas de figure pour lequel il pourrait ne pas y avoir de conflits si les tables sont correctement conçues, je voulais avoir votre opinion pour savoir quel serait l'outil le plus approprié dans ce cas précis :
Une ONG qui travaille dans les pays en voie de développement possède une trentaine de sites répartis dans le pays (appelons les P1 à P30) sur lesquels ils saisissent diverses données (données météorologiques, agricoles, etc...). A ce jour ces sites sont raccordés par une liaison satellite à un site central (appelons le P0) où se situe la base de données. Tout cela fonctionne bien, mais les 30 liaisons satellites sont coûteuses. Ils souhaiteraient effectuer une refonte du système d'information, dans le but essentiellement de faire des économies en terme de télécoms. L'une des pistes envisagées est de conserver les liaisons par satellite, mais au lieu d'avoir 30 liaisons permanentes, de n'en conserver plus qu'une seule qui "balayerait" à tour de rôle chacun des sites distants (on aurait donc tour à tour des liaisons P0-P1, puis P0-P2, puis P0-P3, etc., les liaisons étant à chaque fois établies le temps que la synchronisation puisse se faire)

On aurait donc un serveur sur chaque site, qui devrait se synchroniser avec le serveur central P0 à chaque fois que la connexion est établie. L'objectif est non seulement que P0 centralise les données de tous les autres sites (donc de P1 à P30), mais aussi que sur chaque site ils aient les données des autres, mais bien sur uniquement en lecture seule. Mon idée serait de regrouper les données de chaque site dans un schéma à part (on aurait donc autant de schéma que de sites). Appelons ces schémas de S1 à S30. Le serveur P1 ne peut écrire que dans le schéma S1, le serveur P2 dans le schéma S2, etc...

Donc, lorsque par exemple la liaison P1-P0 est établi, le schéma S1 est mis à jour de P1 vers P0, et les schéma S2 à S30 sont mis à jour de P0 vers P1.
Puis s'établit la liaison P2-P0, le schéma S2 est mis à jour de P2 vers P0, et les schémas S1 et S3 à S30 sont mis à jour de P0 vers P2.
Puis s'établit la liaison P3-P0, le schéma S3 est mis à jour de P3 vers P0, et les schémas S1, S2 et S4 à S30 sont mis à jour de P0 vers P3.
Et ainsi de suites...

On se retrouve toujours encore dans une configuration maîtres-maîtres, vu que lors de chaque établissement de connexion des données sont écrites dans les deux sens, par contre il ne peut pas y avoir de conflits d'écriture, dans la mesure où pour chaque schéma il y a un seul serveur autorisé à écrire dedans.

Pensez-vous qu'une telle architecture est envisageable ? Et si oui, quel est l'outil le plus adapté pour cela ?

Dernière modification par bebert73 (15/06/2011 22:07:16)

gleu

Administrateur

Re : precautions a prendre en vue d'une future réplication des données

A priori, la résolution des conflits ne peut se faire qu'au cas par cas, en fonction de la logique applicative, non ?

Oui, tout à fait. C'est pour ça que bucardo propose trois méthodes : soit on privilégie toujours le serveur 1, soit on privilégie toujours le serveur 2, soit il exécute une fonction utilisateur qui aura le dur travail de choisir laquelle privilégier.

autre cas de figure

Si ce sont des vrais schémas différents, même un système de réplication maître/esclave fonctionnerait.

Je vois deux possibilités en fait :
* soit des tables différentes,
* soit des une numérotation différente de la séquence (de 1 à 100000 pour le site 1, de 100001 à 200000 pour le site 2, etc).

Je ne voudrais pas avoir l'air d'insister mais, même là, Bucardo me semble un bon choix. Si tant est qu'il existe un bon choix...

---

Guillaume.

bebert73

Membre

Re : precautions a prendre en vue d'une future réplication des données

Si ce sont des vrais schémas différents, même un système de réplication maître/esclave fonctionnerait.

Ok oui à ce moment là ce serait comme si lors de la réplication, chaque serveur serait à la fois maître et esclave de l'autre, en fonction des tables. Maîtres pour certaines tables, esclave pour d'autres. On serait donc bien dans ce qu'on appelle la réplication maître/esclave, et non pas maître/maître. C'est bien ça ?

Je vois deux possibilités en fait :
* soit des tables différentes,
* soit des une numérotation différente de la séquence (de 1 à 100000 pour le site 1, de 100001 à 200000 pour le site 2, etc).

Oui je pensais vraiment à des schémas différents (donc des tables différentes).

Je ne voudrais pas avoir l'air d'insister mais, même là, Bucardo me semble un bon choix. Si tant est qu'il existe un bon choix...

A vrai dire je ne me suis jamais intéressé en profondeur à ce sujet, mais je n'ai jamais entendu parler de Bucardo avant. J'avais cru comprendre qu'il y avait un outil de réplication plus ou moins "officiel" de PG, qui s'appelle Slony, et que depuis la version 9 PG intègre même en natif une réplication (je crois même avoir lu quelque part que c'était la raison principale pourquoi ils ont changé de version majeure et sont passés de 8.x à 9). Donc même dans le cas d'une réplication maître/esclave, vous me conseilleriez Bucardo ? Et pas Slony, ni la réplication intégrée à PG ?

Dernière modification par bebert73 (15/06/2011 23:28:46)

gleu

Administrateur

Re : precautions a prendre en vue d'une future réplication des données

On serait donc bien dans ce qu'on appelle la réplication maître/esclave, et non pas maître/maître. C'est bien ça ?

Oui. L'outil habituellement cité pour ça est Slony.

Donc même dans le cas d'une réplication maître/esclave, vous me conseilleriez Bucardo ? Et pas Slony, ni la réplication intégrée à PG ?

La réplication interne de PG ne vous conviendra pas. Les esclaves sont en lecture seule, quelque soit les opérations à faire. Slony peut être un bon candidat. Le problème est le blocage de la synchronisation pendant une longue période, très fréquemment. Il n'est pas prévu pour ça. Ce que j'ai entendu dire de Bucardo me fait dire qu'il semble mieux prévu pour ça. Donc j'aurais plutôt tendance à tester Bucardo, puis Slony.

Dans tous les cas, vous voulez faire qqc de complexe. Attendez-vous à y passer du temps.

---

Guillaume.

bebert73

Membre

Re : precautions a prendre en vue d'une future réplication des données

ok merci pour ces infos, à+

SQLpro

Membre

Re : precautions a prendre en vue d'une future réplication des données

...Par contre en faisant une recherche sur "bucardo" je suis tombé sur ce post http://forums.postgresql.fr/viewtopic.php?id=260 qui traite de la même problématique et dans lequel vous disiez carrément que

Non, ça n'existe pas, quelque soit le moteur de base de données...

...

Erreur, cela existe depuis plus de 13 ans dans SQL Server. C'est la réplication de fusion (MERGE).
A lire : http://msdn.microsoft.com/fr-fr/library/ms152746.aspx

La seule chose à penser elle qu'elle induit fatalement des conflits, que vous pouvez résoudre manuellement ou automatiquement.
En gros comment faire si la même ligne a été mise à jour par deux serveur différents ?
La solution consiste à rajouter des règles, si possible sans équivoque.
Exemple de règle équivoque : prendre la ligne la plus récente (que faire si exactement la même dateheure ?)
Exemple de règle non équivoque : le serveur central gagne toujours.

Si vous voulez des détails sur l'implémentation d'une telle solution, faites le moi savoir.

A +

---

Frédéric Brouard, alias SQLpro,  ARCHITECTE DE DONNÉES,  Expert langage SQL
Le site sur les SGBD relationnel et langage SQL   : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * *  Enseignant CNAM PACA, ISEN Toulon,  CESI Aix en Provence  * * * * *

arthurr

Membre

Re : precautions a prendre en vue d'une future réplication des données

Concernant Bucardo (que j'utilise avec bonheur en version 4.4), il y a un article sur la version 5.0 (en dev) avec des exemples :
http://blog.endpoint.com/2011/06/bucard … resql.html

Dernière modification par arthurr (16/06/2011 14:30:06)

bebert73

Membre

Re : precautions a prendre en vue d'une future réplication des données

ok merci pour ces infos complémentaires

concernant la remarque de SQLPro, il semble que ce soit aussi ce que fait aussi Bucardo, c'est ce qu'a dit Guillaume plus haut :

bucardo propose trois méthodes : soit on privilégie toujours le serveur 1, soit on privilégie toujours le serveur 2, soit il exécute une fonction utilisateur qui aura le dur travail de choisir laquelle privilégier.

C'est cette fonction utilisateur qui pourrait décider par exemple de choisir l'enregistrement le plus récent

Par contre, Guillaume, un truc qui m'échappe encore :

La réplication interne de PG ne vous conviendra pas. Les esclaves sont en lecture seule, quelque soit les opérations à faire.

Je comprend cette phrase comme "la réplication internet de PG ne convient pas CAR dans cette réplication les esclaves sont en lecture seule". Si c'est bien ce que vous vouliez dire, dans ce cas je ne comprends plus, ça veut dire que dans un outil comme Slony les esclaves ne sont PAS en lecture seule ? D'après ce que j'avais compris, un maître est un serveur dans lequel on peut insérer des données, et un esclave est un serveur qui reçoit ses données exclusivement d'un (ou plusieurs) maîtres, mais dans lequel on ne peut en aucun cas entrer des données directement. Autrement dit, j'avais compris qu'un esclave, par définition, est forcément en lecture seule. C'est ça, ou il y a un truc qui m'échappe ?

gleu

Administrateur

Re : precautions a prendre en vue d'une future réplication des données

Par définition, les esclaves sont en lecture seule. Mais il y a plusieurs niveaux. Avec Slony, le verrouillage se fait table par table, base de données par base de données. Donc on peut très bien avoir les tables t1 et t2 qui sont en lecture/écriture sur s1 et lecture seulement sur s2. Mais on peut toujours créer d'autres tables dans s2, ajouter des données dans les tables existantes de s2 (sauf t1 et t2), voire même ajouter un index sur t1 et/ou t2. Avec la réplication interne de PostgreSQL, ce n'est pas possible car c'est l'instance complète qui est en lecture seule.

Dans ce que vous demandez, s1 et s2 doivent pouvoir écrire. Donc soit vous utilisez bucardo pour avoir du maître/maître, soit vous utilisez Slony pour avoir du maître/esclave (le premier étant maître d'un ensemble de tables, et le deuxième d'un autre ensemble de tables, ces ensembles ne se recoupant pas).

---

Guillaume.

bebert73

Membre

Re : precautions a prendre en vue d'une future réplication des données

ok merci c'est clair

la difficulté c'est de choisir le bon outil, il y en a tellement...

Si je résume un peu la grille de choix d'un outil de réplication pour PG (du moins ce que j'en ai compris) :

- si on veut une réplication maître-maître, le choix est Bucardo ou Rubyrep

- si on veut une réplication maître-esclaves avec des esclaves dont l'instance complète est en lecture seule, le choix est la réplication interne de PG

- si on veut une réplication maître-esclaves mais avec uniquement un groupe de table en lecture seule, les autres tables pouvant être en écriture (et pouvant même servir de tables maîtresses pour d'autres réplications), on choisira plutôt Slony (ou Londiste aussi à ce que j'ai lu)

Et par contre même dans ce dernier cas, vous semblez privilégier Bucardo

Slony peut être un bon candidat. Le problème est le blocage de la synchronisation pendant une longue période, très fréquemment. Il n'est pas prévu pour ça. Ce que j'ai entendu dire de Bucardo me fait dire qu'il semble mieux prévu pour ça. Donc j'aurais plutôt tendance à tester Bucardo, puis Slony.

Finalement, y-a-t-il un cas où vous pensez que Slony serait plus adapté que Bucardo ?

gleu

Administrateur

Re : precautions a prendre en vue d'une future réplication des données

Finalement, y-a-t-il un cas où vous pensez que Slony serait plus adapté que Bucardo ?

S'il n'y a pas de déconnexions entre les serveurs (du moins des déconnexions fréquentes), ce qui est généralement le cas, je choisirais Slony. Et sous Windows, il n'y a pas le choix (Bucardo ne fonctionne pas sous Windows). Et pour les anciennes versions de PostgreSQL (je ne sais plus si c'est 8.1 ou 8.3).

En gros, pour du maître/esclave avec un besoin de pouvoir modifier l'esclave (en dehors des tables répliquées), j'aurais tendance à choisir Slony. Par contre, en cas de déconnexions fréquentes ou de vouloir synchroniser qu'à la demande, Bucardo semble mieux pourvu pour ça.

---

Guillaume.

arthurr

Membre

Re : precautions a prendre en vue d'une future réplication des données

Bucardo => à partir de la 8.1

bebert73

Membre

Re : precautions a prendre en vue d'une future réplication des données

Donc en résumé :

- réplication maître-maître : Bucardo (ou Rubyrep)

- réplication maître-esclaves de l'instance complète : la réplication interne de PG

- réplication maître-esclaves de certaines bases ou tables seulement, avec pas ou peu de déconnexions : Slony (ou Londiste)

- réplication maître-esclaves de certaines bases ou tables seulement, avec déconnexions fréquentes et/ou synchros à la demande : Bucardo

Là j'y vois plus clair

Merci !

SAS

Membre

Re : precautions a prendre en vue d'une future réplication des données

Bonjour,

Il est possible qu'à l'avenir je veuille avoir une base "décentralisée" sur mon ordi portable, pour pouvoir continuer à travailler même sans connexion sur le serveur.

Quel est le meilleur outil pour gérer la réplication entre le serveur et le portable dans ce cas ? Notamment, je me pose des questions du genre : supposons qu'au moment de la synchronisation, le dernier SERIAL utilisé soit par exemple le n° 1234. Que se passe-t-il si je crée un nouveau tiers sur mon ordi portable (qui aura donc le n° 1235), et que pendant ce temps quelqu'un créé un autre tiers sur le serveur (qui aura donc aussi le n° 1235) ? Que va-t-il se passer lors de la réplication suivante ? Y-a-t-il des outils de réplication qui gèrent automatiquement ce cas de figure,  ou bien faut-il prendre d'ores et déjà des précautions dans le choix des clés primaires (par exemple avoir comme primary key une combinaison du serial et du username, ou un truc du genre...)

Bonjour,

A partir du moment où l'ensemble des nœuds n'est pas disponible en continu, il devient ardu de gérer une réplication de type Slony ou réplication interne.

La meilleure solution dans votre cas reste de définir une clé composite, composée de la clé primaire de votre table (séquence), et d'un identifiant du client (idc=1 pour le serveur, idc=2 pour le portable...), et d'associer à vos enregistrements une estampille temporelle de modification.
Ainsi, chaque enregistrement peut être identifié par l'identifiant de ligne et l'identifiant de client, et un groupe date-heure qui vous permet de gérer aisément les conflits avec une règle de type « le dernier qui a parlé a raison », par exemple.

---

Stéphane Schildknecht
Conseil, formations et support PostgreSQL
http://www.loxodata.com

bebert73

Membre

Re : precautions a prendre en vue d'une future réplication des données

ok merci, oui, c'est plus ou moins ce que je comptais faire : en fait je comptais mettre dans la clé primaire le USER (les USERS qui utiliseront un ordi portable avec une base décentralisée devront donc penser à faire la synchro avant de retourner bosser sur le serveur central).

et comme outil pour faire ça, d'après ce que j'ai compris, BUCARDO est le mieux adapté