Lelarge Guillaume
Consultant - Dalibo
Guillaume Lelarge est un contributeur majeur de PostgreSQL. Il dirige la traduction du manuel officiel, et maintient différents outils pour PostgreSQL. Il est un contributeur régulier des revues GNU/Linux Magazine France et Linux Pratique, ainsi que l'auteur du livre "PostgreSQL, Architecture et notions avancées", aux éditions D-BooKer.
En parallèle, Guillaume travaille depuis plus de treize ans en tant que consultant chez Dalibo.
Londiste, la réplication vue par Skype
Londiste est un autre système de réplication asynchrone basé sur les triggers. Son installation est un peu particulière, mais pas désagréable du tout. Elle est même bien plus simple que l'installation de Slony. Créé par Skype en Python pour ses besoins propres, il est disponible depuis peu de temps, mais progresse bien et mérite sa place dans ce hors-série.
Rapide configuration de PostgreSQL
PostgreSQL et son fichier de configuration de 17 Ko sur 503 lignes : rien de moins que 180 et quelques paramètres. Cela n'aide clairement pas un débutant à se lancer. Pourtant, il faut savoir que seule une grosse dizaine de paramètres sont essentiels à configurer. Le reste n'a pour cible que les cas très particuliers.
Installation de PostgreSQL
Installer PostgreSQL n'est pas compliqué. Que ce soit par les sources ou par un paquet, c'est généralement une question d'une dizaine de minutes. Nous allons voir comment l'installer à partir des sources, à partir du paquet Debian et à partir d'un paquet RPM.
pgPool-II, la réplication par duplication des requêtes
Un moyen extrêmement simple, voire simpliste diront certains, de faire de la réplication est d'envoyer toutes les requêtes à tous les serveurs en réplication. Évidemment, cela donnera lieu à des limitations assez fortes, mais le résultat peut être intéressant.
Slony, réplication des données par trigger
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.
Une synthèse, et en route vers le futur
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.
La réplication par les journaux de transactions
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.
Le projet PostgreSQL
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.