Une réplication au coeur de PostgreSQL

La nouvelle a fait grand bruit sur la liste pgsql-hackers. Tom Lane a annoncé le 29 mai 2008 que la « core team » veut ajouter la réplication directement dans le moteur de PostgreSQL. Évidemment, cela change du discours habituel (« no "one size fits all" replication solution »). En fait, ce changement est survenu après la conférence d'Andrew lors de pgcon 2008. Les développeurs PostgreSQL attendaient un retour des développeurs de modules de réplication. Ce retour ne venant pas, ils ont décidé d'intégrer une solution de réplication dans PostgreSQL. Le but n'est évidemment pas d'empêcher l'existence des autres solutions, mais d'en proposer une par défaut et facile à installer.

Il existe déjà un bout de réplication dans PostgreSQL. Il est possible de faire envoyer les journaux de transactions sur un deuxième serveur et de faire en sorte que ce serveur restaure en continue les données contenues dans les journaux de transactions. Donc, on se retrouve avec un deuxième serveur, en restauration continue, prêt à prendre la main en cas de problème sur le serveur principal. C'est ce qu'on appelle le « Warm Standby » ou encore « Log Shipping ». Néanmoins, la solution n'est pas parfaite :

  • vous devez répliquer l'instance complète (pas de choix des objets à répliquer comme avec Slony par exemple) ;
  • l'esclave n'est pas disponible (alors qu'il est en lecture seule sur la plupart des autres outils de réplication, Slony par exemple) ;
  • vous pouvez perdre l'équivalent en données d'un journal de transaction (à modérer avec le paramètre « archive_timeout » qui permet justement d'avoir un délai maximum avant de forcer l'utilisation d'un nouveau journal de transaction... ce qui a un prix en terme de bande passante, surtout si votre esclave dépend d'une ligne peu rapide) ;
  • la réplication est asynchrone (ce qui peut-être parfaitement acceptable dans certains cas et intolérable dans d'autres).

Le but est de répondre aux deux derniers points pour offrir une réplication, asynchrone et/ou synchrone, sans délai. Pour cela, il faut bien comprendre ce qu'est un journal de transactions. Un journal est une aggrégation de pages disques qui ont été modifiées. Il contient aussi d'autres types d'enregistrement comme les CHECKPOINT, mais il est principalement composé de pages disques. Chacune de ces pages disques (de 8 Ko) représente une modification sur une partie d'un fichier représentant une table ou un index. Plutôt que d'envoyer ces pages disques regroupées en bloc de 16 Mo (donc au maximum 2048 pages disques stockées), les développeurs de PostgreSQL voudraient les envoyer grouper par transaction. En effet, suivant la transaction SQL exécutée, une ou plusieurs pages disques seront ajoutées au journal de transaction pour indiquer les modifications entreprises. Plutôt que d'envoyer un journal de transaction (qui peut contenir des transactions validées et/ou annulées, plusieurs transactions ou une partie d'une transaction), il est préférable de récupérer toutes celles qui correspondent à une transaction et à envoyer tout d'un coup après COMMIT et/ou ROLLBACK. De cette façon, la réplication est en temps réel.

La question du type de réplication s'est aussi posée : sera-t-elle asynchrone (comme le LogShipping ou comme Slony) ou synchrone (comme... euh... bin, rien que je connaisse pour être franc) ? et la réponse de Tom Lane n'a pas tardé : « les deux, suivant la configuration ». Là aussi, c'est très bien joué. Plutôt que d'imposer le type de réplication, on laisse le choix à l'administrateur. Avoir une réplication synchrone n'est pas que du bonheur, ça a un impact sur les performances. Tous les esclaves devront renvoyer un message pour indiquer qu'ils ont bien reçu (et enregistré sur disque) la transaction avant que le serveur maître puisse dire au client que les données sont enregistrées. Donc, pour les cas où une réplication synchrone est inutile, la désactiver permettra de gagner en performances.

Il est prévu malgré tout de travailler sur l'utilisation des esclaves en lecture seule. Le travail reste important. D'après Simon Riggs, il sera difficile d'intégrer ça dans la version 8.4. Il est plus probable que l'on verra ça seulement en 8.5. Tout dépend en fait de la façon dont NTT va communiquer sur ce sujet. NTT est une entreprise asiatique qui a déjà développé ce type de réplication (avec un composant de haute-disponibilité utilisant Heartbeat). Eux-aussi ont réalisé une présentation de ces travaux lors de pgcon2008. Les slides permettent de bien comprendre leur travaux, ne surtout pas hésiter à les lire.

Pour terminer, ce que cette réplication ne fera pas :

  • répliquer à un niveau plus fin que l'instance même.
  • pas de possibilité de mettre à jour vers une nouvelle version majeure de PostgreSQL (je dis bien majeure, car les mineures seraient possibles d'après Simon Riggs).
  • pas de failover automatique.

Voilà, un post un peu long sur une fonctionnalité très attendue et très prometteuse. La version 8.4 semble décidément très alléchante.

Ajouter un commentaire

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.

Fil des commentaires de ce billet