Lelarge Guillaume

Lors du précédent article, nous avons vu comment mettre en place un serveur maître et son serveur esclave. Nous allons aller un peu plus loin dans cet article, en proposant maintenant une réplication beaucoup plus synchronisée (mais toujours pas synchrone).Nous allons aussi passer en revue un certain nombre de points importants à connaître pour administrer au mieux ses serveurs en réplication. Tout d'abord, le problème posé par les requêtes en lecture seule. Ces dernières posent des verrous et, aussi peu gênants soient-ils dans une utilisation normale, ils peuvent poser quelques soucis majeurs pour un serveur esclave. Nous verrons aussi comment effectuer une bascule dans deux cas : la bascule volontaire (« switchover ») et la bascule forcée (« failover »). Enfin, nous verrons comment surveiller l'état de la réplication et des deux serveurs concernés.

L'évolution majeure qu'apporte la version 9.0 de PostgreSQL est la réplication. Évidemment, ce n'est pas la seule nouveauté intéressante de cette version, mais c'est certainement celle qui fera le plus parler de cette version, celle aussi qui aidera à une adoption plus massive de cet excellent système de gestion de bases de données.

DRBD est un outil capable de répliquer le contenu d'un périphérique bloc. En ce sens, ce n'est pas un outil spécialisé pour PostgreSQL, contrairement aux autres outils vus dans le hors-série 44 sur PostgreSQL. Il peut très bien servir à répliquer des serveurs de fichiers ou de mails. Il réplique les données en temps réel et de façon transparente, pendant que les applications modifient leurs fichiers sur un périphérique. Il peut fonctionner de façon synchrone ou asynchrone. Tout ça en fait donc un outil intéressant pour répliquer le répertoire des données de PostgreSQL.

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.