Lelarge Guillaume

Il existe en gros trois façons de répliquer une base de données : répliquer les changements des fichiers (c'est ce que propose le Log Shipping, ainsi que DRBD), répliquer les instructions (c'est ce que propose pgpool) et répliquer les changements de données. Ce dernier cas est proposé par trois outils, dont Slony.

Ce hors-série nous a permis de présenter un certain nombre de solutions de pooling de connexions, de réplication... bref, de la haute disponibilité sur PostgreSQL. Cet article va faire le tour de tous les systèmes de pooling et de réplication que nous connaissons.

Toutes les données modifiées dans PostgreSQL sont tout d'abord stockées dans les journaux de transactions. Une solution particulièrement simple pour la réplication revient donc à archiver les journaux de transactions et à les rejouer sur un serveur distant.

Ce projet a réellement débuté en 1996 quand Bruce Momjian et Marc Fournier ont repris un certain nombre de patchs qui traînaient pour les intégrer dans ce qui s'appelait alors Postgres95. Leur collaboration a permis de mettre en place une plateforme (web, cvs, listes de discussion) et de s'assurer de la sortie de versions officielles.

pgBouncer est un autre pooler de connexions. Contrairement à pgPool-II, il se contente d'être ça. Par contre, il va proposer des options uniques, comme une option permettant de préciser le moment où on souhaite changer de connexions. Cela ne sera pas forcément une connexion unique pour une session. Cela pourra être une connexion unique par transaction ou par instruction. Une option unique en son genre, mais qui a ses propres limitations.

Les programmes de pooling de connexions ont un but simple : supprimer le temps de connexion pour améliorer la rapidité des programmes se connectant très souvent et n'exécutant que peu de requêtes pendant une même connexion. C'est principalement le cas des applications web. Une page PHP va généralement exécuter peu de requêtes tout en étant fréquemment sollicitée. Dans ce cas, le temps de la connexion devient un facteur limitant, surtout pour les applications web devant gérer un très grand nombre d'utilisateurs (et donc de connexions). PostgreSQL dispose de deux solutions. La première est pgPool-II.

Après la première édition l'année dernière à Prato, en Italie, le PGDay européen se tiendra cette année à Paris, les vendredi 6 et samedi 7 novembre 2009.

Nous allons construire une petite base et voir quelques rudiments : création d'une base, création de quelques tables, insertion de données, sauvegarde. Le minimum pour savoir comment débuter.

Plus d'un an après la sortie de la version 8.3, les développeurs de PostgreSQL ont sorti la version 8.4. Très exactement le 1er juillet. Les plus attentifs remarqueront que le planning initial a été largement débordé, de quatre mois au minimum. Ceci est dû à l'attente de deux patchs ajoutant des fonctionnalités très intéressantes à la réplication de PostgreSQL (esclave en lecture seule, réplication à la transaction près). Ces derniers n'étant manifestement pas prêts, il a été jugé préférable de les repousser à une prochaine version. Néanmoins, que cela ne vous refroidisse pas trop. La version 8.4 apporte un très grand nombre de nouvelles fonctionnalités, et des performances encore améliorées. Même si elles ont souvent pour cible l'administrateur, les utilisateurs et les développeurs y trouveront aussi leur compte.