Comparaison entre les réplications PostgreSQL et MariaDB (MySQL)
La réplication (fonctionnalité très appréciée dans les SGBDR) est utilisée pour faire de la reprise d’activité après sinistre (PRA/PCA), ou pour délester des traitements « lourds » sur une instance secondaire dédiée à cet effet.
On peut aussi utiliser des instances esclaves en lecture seule pour faire de la scalabilité horizontale par redirection des requêtes de lecture (instruction SELECT).
Voici les caractéristiques générales de PostgreSQL et MariaDB (MySQL) concernant la réplication de données dans une architecture « shared nothing ».
Comparaison entre les réplications PostgreSQL et MariaDB : quelles sont les différences ?
1 – La réplication PostgreSQL
- Un serveur maître vers 1 ou plusieurs esclaves
- Réplication basée sur le journal des transactions effectuées sur le maître en temps quasi réel (moins d’une seconde)
- Prise en charge du mode asynchrone (préférable dans beaucoup de cas) et synchrone
- Réplication de toutes les bases de données au niveau de l’instance maître
Les journaux de transaction xlog / WAL
La réplication de PostgreSQL est basée sur le transfert du journal des transactions, appelé archivage WAL (write ahead Log), dans lequel le serveur maître continue à écrire les transactions, vers chaque serveur esclave ou en cascade (d’un serveur esclave vers un autre pour ne pas pénaliser les performances du maître).
L’esclave applique ensuite le journal WAL en réécrivant directement les données de la table sur le disque, ce qui est beaucoup plus rapide que la réplication basée sur des instructions.
La transmission du journal des transactions est provoquée par anticipation sur validation annulation de la transaction, remplissage du tampon WAL, atteinte d’un timeout.
Granularité des données répliquées
La réplication en continu (streaming) de PostgreSQL ou la réplication par archive réplique toutes les bases de données de l’instance.
Depuis la version 9.4, PostgreSQL peut répliquer les bases de données et les tables que vous sélectionnez en utilisant le décodage logique et le slot de réplication.
Réplication mode synchrone (multi-maître)
PostgreSQL ne propose pas nativement de réplication multi-maîtres, ni de solution basée sur le commit à deux phases (mode synchrone). Mais, on peut utiliser les offres Bucardo et PgPool pour répondre à ce besoin.
2 – La réplication MariaDB (MySQL)
La réplication asynchrone est la principale fonctionnalité utilisée pour créer des architectures évolutives, des serveurs de secours, des instances en lecture seule, etc.
Les différentes topologies de réplication MariaDB prises en charge incluent:
- Un serveur maître vers 1 ou plusieurs esclaves
- Réplication circulaire (de A vers B, puis vers C et retour à A)
- Réplication multi-sources (différent de la réplication multi-maîtres)
- Réplication multi-maître (RW sur chaque noeud)
Les journaux de transaction binary log
La réplication est basée sur un log binaire qui contient les transactions exécutées sur le maître qui peut être +/- équivalent aux fichiers WAL de PostgreSQL en fonction des paramètres utilisés.
Nous pouvons utiliser un mode synchrone, semi-synchrone et asynchrone qui va permettre de définir comment est validée chaque transaction émise sur le maître et répliquée sur l’esclave.
Granularité des données répliquées
La réplication peut avoir une granularité au niveau de toutes les bases de données, d’une base de données, ou d’une table.
Réplication mode synchrone
L’envoi des données de réplication en mode asynchrone fonctionne de la manière suivante :
- Le thread binlog_dump du maître envoie un journal binaire chaque fois qu’une transaction est validée.
- Le thread d’E/S de l’esclave reçoit le journal de relais et le thread SQL exécute la commande SQL reçue ou en appliquant l’événement qui va modifier les tuples.
Réplication mode semi-synchrone
L’envoi des données de réplication en mode semi-synchrone fonctionne de la manière suivante :
- L’esclave accuse réception des événements de la transaction après que les événements soient écrits dans le journal de relais et vidés.
- Si l’esclave ne reconnaît pas la transaction avant un certain temps (paramètre à configurer), le maître passe en réplication asynchrone.
- Lorsqu’au moins un esclave semi-synchrone a rattrapé son retard, la réplication semi-synchrone reprend.
Réplication mode synchrone (multi-maître)
L’envoi des données de réplication en mode synchrone fonctionne de la manière suivante :
- Le début d’une transaction est initialisé sur tous les nœuds synchrones (multi-maître) à l’aide de processus de communication en temps réel.
- La transaction passe ensuite une étape de commit en deux phases dans laquelle elle sera validée par tous les maîtres, ou bien annulée. Ceci garantit que si des modifications sont apportées sur un nœud du cluster (un maître), elles se produisent sur d’autres nœuds « de manière synchrone » ou simultanément.
PostgreSQL et MariaDB : En résumé
PostgreSQL et MariaDB ne disposent pas directement des mêmes fonctionnalités , avec des méthodes parfois différentes pour remplir un même objectif. En fonction de votre besoin, de vos usages, des outils que vous utilisez déjà, le choix peut être différent. Syloé peut vous accompagner dans votre réflexion et pour atteindre votre objectif. Contactez-nous pour plus d’informations.