Streaming Replication est une nouvelle fonctionnalité qui a été introduite avec la version 4.0 de Galera Cluster. Galera utilise la réplication de manière synchrone sur l'ensemble du cluster, mais avant cette version, les jeux d'écriture supérieurs à 2 Go n'étaient pas pris en charge. La réplication en continu vous permet désormais de répliquer de grands ensembles d'écritures, ce qui est parfait pour les insertions en bloc ou le chargement de données dans votre base de données.
Dans un blog précédent, nous avons écrit sur la gestion des transactions volumineuses avec la réplication en continu et MariaDB 10.4, mais au moment de la rédaction de ce blog, Codership n'avait pas encore publié sa version du nouveau cluster Galera. Percona a cependant publié sa version binaire expérimentale de Percona XtraDB Cluster 8.0 qui met en évidence les fonctionnalités suivantes...
-
Réplication en continu prenant en charge les transactions volumineuses
-
Les fonctions de synchronisation permettent la coordination des actions (wsrep_last_seen_gtid, wsrep_last_written_gtid, wsrep_sync_wait_upto_gtid)
-
Journalisation des erreurs plus granulaire et améliorée. wsrep_debug est maintenant une variable à plusieurs valeurs pour aider à contrôler la journalisation, et les messages de journalisation ont été considérablement améliorés.
-
Certaines erreurs DML et DDL sur un nœud de réplication peuvent être ignorées ou supprimées. Utilisez la variable wsrep_ignore_apply_errors pour configurer.
-
Plusieurs tables système permettent d'en savoir plus sur l'état du cluster.
-
L'infrastructure wsrep de Galera 4 est plus robuste que celle de Galera 3. Elle offre une exécution plus rapide du code avec une meilleure gestion des états, une prévisibilité améliorée et une gestion des erreurs.
Quoi de neuf avec Galera Cluster 4.0 ?
La nouvelle fonctionnalité de réplication en continu
Avec la réplication en continu, les transactions sont répliquées progressivement en petits fragments pendant le traitement des transactions (c'est-à-dire qu'avant la validation réelle, nous répliquons un certain nombre de fragments de petite taille). Les fragments répliqués sont ensuite appliqués dans les threads esclaves, préservant l'état de la transaction dans tous les nœuds du cluster. Les fragments détiennent des verrous dans tous les nœuds et ne peuvent pas être en conflit ultérieurement.
Tables système Galera
Les administrateurs de base de données et les clients ayant accès à la base de données MySQL peuvent lire ces tables, mais ils ne peuvent pas les modifier car la base de données elle-même apportera les modifications nécessaires. Si votre serveur ne dispose pas de ces tables, il se peut que votre serveur utilise une ancienne version de Galera Cluster.
#> show tables from mysql like 'wsrep%';
+--------------------------+
| Tables_in_mysql (wsrep%) |
+--------------------------+
| wsrep_cluster |
| wsrep_cluster_members |
| wsrep_streaming_log |
+--------------------------+
3 rows in set (0.12 sec)Nouvelles fonctions de synchronisation
Cette version introduit une série de fonctions SQL à utiliser dans les opérations de synchronisation wsrep. Vous pouvez les utiliser pour obtenir l'ID de transaction global qui est basé sur la dernière transaction d'écriture ou la dernière transaction vue. Vous pouvez également configurer le nœud pour qu'il attende qu'un GTID spécifique soit répliqué et appliqué avant de lancer la transaction suivante.
Sélection intelligente des donneurs
Certaines fonctionnalités discrètes présentes depuis Galera 3.x incluent la sélection intelligente des donneurs et la récupération en cas de panne de cluster. Celles-ci étaient initialement prévues pour Galera 4, mais ont été intégrées aux versions précédentes en grande partie en raison des exigences des clients. En ce qui concerne la sélection du nœud donneur dans Galera 3, le donneur State Snapshot Transfer (SST) a été sélectionné au hasard. Cependant, avec Galera 4, vous obtenez un choix beaucoup plus intelligent lorsqu'il s'agit de choisir un donneur, car il favorisera un donneur qui peut fournir un transfert d'état incrémentiel (IST), ou choisir un donneur dans le même segment. En tant qu'administrateur de base de données, vous pouvez forcer cela via le paramètre wsrep_sst_donor.
Pourquoi utiliser la réplication en continu du cluster MySQL Galera ?
Transactions de longue durée
Les problèmes et les limites de Galera tournaient toujours autour de la façon dont il gérait les transactions de longue durée et provoquaient souvent le ralentissement de l'ensemble du cluster en raison de la réplication de grands jeux d'écriture. Son contrôle de flux est souvent élevé, ce qui ralentit les écritures ou même met fin au processus afin de ramener le cluster à son état normal. Il s'agit d'un problème assez courant avec les versions précédentes de Galera Cluster.
Codership conseille d'utiliser la réplication en continu pour vos transactions de longue durée afin d'atténuer ces situations. Une fois que le nœud réplique et certifie un fragment, il n'est plus possible pour d'autres transactions de l'abandonner.
Transactions importantes
Ceci est très utile lors du chargement de données dans votre rapport ou vos analyses. La création d'insertions en bloc, de suppressions, de mises à jour ou l'utilisation de l'instruction LOAD DATA pour charger une grande quantité de données peuvent tomber dans cette catégorie. Bien que cela dépende de la façon dont vous gérez vos données pour la récupération ou le stockage. Vous devez tenir compte du fait que Streaming Replication a ses limites, de sorte que les clés de certification sont générées à partir des verrous d'enregistrement.
Sans Streaming Replication, la mise à jour d'un grand nombre d'enregistrements entraînerait un conflit et toute la transaction devrait être annulée. Les esclaves qui répliquent également des transactions volumineuses sont soumis au contrôle de flux lorsqu'il atteint le seuil et commence à ralentir l'ensemble du cluster pour traiter toutes les écritures car ils ont tendance à se détendre en recevant les transactions entrantes de la réplication synchrone. Galera assouplit la réplication jusqu'à ce que le jeu d'écriture soit gérable car il permet de continuer la réplication à nouveau. Consultez ce blog externe de Percona pour vous aider à mieux comprendre le contrôle de flux dans Galera.
Avec Streaming Replication, le nœud commence à répliquer les données avec chaque fragment de transaction, plutôt que d'attendre la validation. Cela signifie qu'il n'y a aucun moyen pour les transactions en conflit en cours d'exécution dans les autres nœuds d'abandonner, car cela confirme simplement que le cluster a certifié le jeu d'écriture pour ce fragment particulier. Il est libre d'appliquer et de valider d'autres transactions simultanées sans bloquer et de traiter des transactions volumineuses avec un impact minimal sur le cluster.
Enregistrements actifs/points actifs
Les enregistrements ou lignes actifs sont les lignes de votre table qui sont constamment mises à jour. Ces données pourraient être les plus visitées et obtenir le trafic de l'ensemble de votre base de données (par exemple, les flux d'actualités, un compteur tel que le nombre de visites ou les journaux). Avec Streaming Replication, vous pouvez imposer des mises à jour critiques à l'ensemble du cluster.
Comme noté par l'équipe Galera de Codership
"L'exécution d'une transaction de cette manière verrouille efficacement l'enregistrement à chaud sur tous les nœuds, empêchant les autres transactions de modifier la ligne. Cela augmente également les chances que la transaction soit validée avec succès et que le client reçoive à son tour le résultat souhaité. »
Cela s'accompagne de limitations car il se peut que vous n'ayez pas des commits réussis de manière persistante et cohérente. Sans utiliser Streaming Replication, vous vous retrouverez avec de grandes chances ou des retours en arrière et cela pourrait ajouter des frais généraux à l'utilisateur final lorsqu'il rencontre ce problème dans la perspective de l'application.
Éléments à prendre en compte lors de l'utilisation de la réplication en continu
- Les clés de certification sont générées à partir des verrous d'enregistrement. Par conséquent, elles ne couvrent pas les verrous d'espace ou les verrous de clé suivants. Si la transaction prend un verrou d'espacement, il est possible qu'une transaction, qui est exécutée sur un autre nœud, applique un jeu d'écriture qui rencontre le journal d'espacement et interrompe la transaction de streaming.
- Lors de l'activation de la réplication en continu, les journaux d'ensemble d'écriture sont écrits dans la table wsrep_streaming_log trouvée dans la base de données système mysql pour préserver la persistance en cas de panne, de sorte que cette table sert lors de la récupération. En cas de journalisation excessive et de surcharge de réplication élevée, la réplication en continu entraînera une dégradation du débit des transactions. Cela pourrait être un goulot d'étranglement des performances lorsque la charge de pointe élevée est atteinte. En tant que tel, il est recommandé de n'activer la réplication en continu qu'au niveau de la session, et uniquement pour les transactions qui ne s'exécuteraient pas correctement sans elle.
- Le meilleur cas d'utilisation consiste à utiliser la réplication en continu pour réduire les transactions volumineuses
- Définir la taille des fragments sur ~10 000 lignes
- Les variables de fragment sont des variables de session et peuvent être définies dynamiquement
- Une application intelligente peut activer/désactiver la réplication en continu en fonction des besoins
Conclusion
Merci d'avoir lu, dans la deuxième partie, nous verrons comment activer Galera Cluster Streaming Replication et à quoi pourraient ressembler les résultats pour votre configuration.
