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
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
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.
ca sent la fin pour MySQL
de
DominiqueD.
, posté le 03 février 2010 à 11h58
Si la réplication continue est renforcée au sein de PostgreSQL, pourquoi continuer à se battre pour (la "libération" de) MySQL ?
IMHO MySQL va mourir petit à petit...
L'épopée de MySQL est un rude coup porté envers le dual licensing. Cela ne joue pas en sa faveur.
IMHO MySQL va mourir petit à petit...
L'épopée de MySQL est un rude coup porté envers le dual licensing. Cela ne joue pas en sa faveur.
à lire aussi
SUR LES MÊMES THÈMES 


nos newsletters
Abonnez-vous à Micro Hebdo : 4,90 €/mois
Abonnez-vous à l'Ordinateur Individuel : 3 €/mois
Abonnez-vous à la version digitale
Abonnez-vous à 01Business et Technologies : 19 €/mois












agrandir la photo





alerter le modérateur