repmgr est un outil pour mettre en place et administrer la réplication intégrée dans PostgreSQL à partir de la version 9.0

Il s'utilise très simplement en ligne de commande.

repmgr permet de:

• cloner un serveur Primaire pour en faire un serveur Standby
• basculer le serveur Primaire sur un standby et réaffecter le serveur Primaire pour les autres Standby (oui, oui, si vous avez plusieurs Standby la réplication n'a pas besoin d'être réinitialisée)

Et il y aussi repmgrd qui permet de vérifier le bon déroulement de la réplication. C'est un démon qui insère une nouvelle ligne sur le Primaire à intervalle régulier, depuis chaque serveur Standby. La table ainsi remplit est donc visible depuis chaque Standby ou sur le Primaire et permet de lire le lag actuel pour chaque serveur.

La nouveauté principale de la version 2.0 actuellement en beta est la gestion d'un fail-over automatique.

Le principe est assez simple. Chaque démon repmgrd en plus de ses requêtes régulières peut désormais déclencher un process interne pour accélérer les tentatives de connexions vers le serveur Primaire. Après un nombre déterminé d'échecs successifs, les démons vont demander les uns au autres l'état de leur réplication respective. Suite à un vote entre eux sur leur possibilité de se joindre les uns les autres, et sur leur lag respectif, le choix peut être pris de considérer le serveur Primaire comme mort et de trouver le meilleur candidat pour être le nouveau serveur Primaire.

Une fois ce stade atteint, deux hooks sont utilisés pour déclencher les actions à entreprendre. Un hook pour la promotion en serveur Primaire, un pour suivre le nouveau serveur Primaire. De sorte que le DBA est en charge d'écrire les scripts à utiliser. repmgr se contente de déterminer un état, l'administrateur est libre d'utiliser cet déclaration d'état comme il veut: modifier les configurations de PgBouncer, achever l'ancien serveur Primaire pour garantir qu'il ne vienne pas perturber le système, réaffecter les serveurs, …

Pour plus d'info:

• le site web de repmgr: http://repmgr.org/
• le dépot git de Greg Smith https://github.com/greg2ndQuadrant/repmgr
• le channel IRC: freenode#repmgr
• gestion de bugs: https://github.com/greg2ndQuadrant/repmgr/issues
• Mailling-List: http://groups.google.com/group/repmgr

J'ai aussi donné une conférence expliquant les principes du fail-over automatique au CHAR(11), les slides sont disponibles ici.

CHAR(11) a été une très bonne occasion de discuter réplication.

En particulier, Jan Wieck m'a convaincu de ne pas oublier Slony. Bien que j'ai activement participé au développement de la version 1.2 de slony-ctl et l'aie présenté au CHAR(10) j'utilise plus fréquemment les Skytools.

La réplication en streaming étant enfin présente avec PostgreSQL 9.0, les systèmes de réplications asynchrones par trigger (londiste, slony, …) perdent une grande part de leurs utilisateurs dont les besoins sont assez simple: obtenir un réplicat complet du serveur Principal. Avec l'utilisation de repmgr, la mise en place et l'administration est simplissime. Reste tous les utilisateurs qui ont un besoin plus complexe qu'une réplication binaire et complète (et synchrone avec PostgreSQL 9.1, et en cascade avec PostgreSQL 9.2).

Quelle place reste-il pour Slony ? Surtout avec les Skytools3 qui devraient bientôt sortir et réduisent le grand écart que Skype avait pris par rapport à Slony.

Et bien Slony n'est pas en reste et, d'après Jan, a aussi intégré des idées de Londiste (le système de réplication basé sur les Skytools).

Un reproche que l'on peut faire à Slony est d'avoir releasé un peu trop vite par le passé, avec des bugs importants. Skytools, c'est le contraire, il y a quelques releases correctives ou avec des améliorations mineures mais la release de la version 3 est dans le trunk depuis 2 ou 3 ans !!!

Comparer skytools 2 avec slony 1 est facile: quasiment le seul intéret de Slony est l'énorme simplicité de switchover que n'a pas Londiste (et la réplication en cascade…).

L'enjeu est donc de comparer slony 2 et skytools 3 chacun étant plus ou moins au niveau de l'autre: réécriture importante du code et ajout de nouvelles fonctionnalités.

Lire la suite dans le prochain numéro !

EDIT: Steve Singer, qui a pris une part active dans Slony depuis 1 ou 2 ans (depuis qu'il est chez Affilias donc), vient justement d'écrire un article au sujet de la version 2.1 new-features-in-slony-2-1