La réplication continue renforce PostgreSQL
Cette fonction de réplication en streaming affine le mécanisme traditionnel de mise en redondance des données de la base. PostgreSQL passera ainsi directement de la version 8.4 à 9.0.
Streaming réplication ou, en bon français, réplication en continu, ou encore réplication au fil de l'eau : cette fonction qui faisait jusqu'ici cruellement défaut à la base de données open source, est concurrente de MySQL. Pour marquer ce pas important, PostgreSQL passera directement de la version 8.4 à la version 9.0 dans les prochaines semaines.
Accompagnée d'une fonction de hot standby – permettant que les nœuds de secours de la base acceptent les requêtes en lecture seule – cette fonction de réplication en continu qui copie les données en streaming (en flux, et non par blocs), propulse PostgreSQL au rang de base de données définitivement taillée pour les besoins actuels des administrateurs : c'est-à-dire une base dotée d'un système de réplication intégré complet, et riche de plusieurs options.
Accompagnée d'une fonction de hot standby – permettant que les nœuds de secours de la base acceptent les requêtes en lecture seule – cette fonction de réplication en continu qui copie les données en streaming (en flux, et non par blocs), propulse PostgreSQL au rang de base de données définitivement taillée pour les besoins actuels des administrateurs : c'est-à-dire une base dotée d'un système de réplication intégré complet, et riche de plusieurs options.
Une redondance mieux synchronisée
agrandir la photo
Concrètement, cette fonction résout le problème causé par le mécanisme de redondance de la base, quand il s'appuie sur les journaux de transaction (que l'on nomme xlogs ou WAL). En effet, lorsque ces journaux, d'une taille de 16 mégaoctets, étaient copiés avec le mécanisme jusqu'ici en usage, un décalage entre le serveur principal et le serveur secondaire pouvait se produire, se traduisant en cas d'incident par une perte de données. Avec la réplication continue,ces dernières sont répliquées transaction par transaction. Cela améliore considérablement la synchronisation entre les nœuds, et limite la perte de données en cas d'incident aux seules dernières opérations.
Il existait déjà une fonction de ce type dans PostgreSQL,le Warm Standby, mais elle n'est pas aussi réactive. Ce mécanisme interne consiste à exporter les journaux de transaction de PostgreSQL sur un serveur secondaire qui rejoue ces journaux au fur et à mesure.
Il existait déjà une fonction de ce type dans PostgreSQL,le Warm Standby, mais elle n'est pas aussi réactive. Ce mécanisme interne consiste à exporter les journaux de transaction de PostgreSQL sur un serveur secondaire qui rejoue ces journaux au fur et à mesure.
Une autre alternative : Slony
agrandir la photo
Par ailleurs, un logiciel à part entière existait également, qui autorisait la réplication entre un maître et plusieurs esclaves. Mais ce logiciel, Slony, nécessite d'être installé, configuré et maintenu en plus de PostgreSQL.
Pour en savoir plus sur la réplication dans PostgreSQL, lire la présentation de Jean-Paul Argudo, sous licence Creative Commons.
Pour en savoir plus sur la réplication dans PostgreSQL, lire la présentation de Jean-Paul Argudo, sous licence Creative Commons.
à lire aussi
SUR LES MÊMES THÈMES 


nos newsletters
Lisez 01Business pour 6,54 € / n°















