Nous avons déjà blogué sur les nouveautés de MySQL Galera Cluster 4.0, la gestion des transactions volumineuses avec la réplication en continu et MariaDB 10.4 et présenté quelques guides sur l'utilisation de la nouvelle fonctionnalité de réplication en continu dans une série de parties 1 et 2.
Transférer votre technologie de base de données de MySQL Replication vers MySQL Galera Cluster nécessite que vous ayez les bonnes compétences et une compréhension de ce que vous faites pour réussir. Dans ce blog, nous partagerons quelques conseils pour migrer d'une configuration de réplication MySQL vers MySQL Galera Cluster 4.0.
Les différences entre la réplication MySQL et le cluster Galera
Si vous n'êtes pas encore familier avec Galera, nous vous suggérons de parcourir notre tutoriel Galera Cluster for MySQL. Galera Cluster utilise un tout autre niveau de réplication basé sur la réplication synchrone, contrairement à la réplication MySQL qui utilise la réplication asynchrone (mais peut également être configurée pour réaliser une réplication semi-synchrone).
Galera Cluster prend également en charge la réplication multimaître. Il est capable d'appliquer en parallèle sans contrainte (c'est-à-dire de « réplication parallèle »), de réplication multidiffusion et de provisionnement automatique des nœuds.
L'objectif principal de Galera Cluster est la cohérence des données, alors qu'avec la réplication MySQL, il est sujet à l'incohérence des données (ce qui peut être évité avec les meilleures pratiques et une configuration appropriée telle que l'application de la lecture seule sur les esclaves pour éviter écritures indésirables dans les esclaves).
Bien que les transactions reçues par Galera soient appliquées à chaque nœud ou pas du tout, chacun de ces nœuds certifie le jeu d'écritures répliqué dans la file d'attente de l'applicateur (commits de transaction) qui inclut également des informations sur tous les nœuds. verrous détenus par la base de données lors de la transaction. Ces jeux d'écriture, une fois qu'aucun verrou conflictuel n'est identifié, sont appliqués. Jusqu'à ce point, les transactions sont considérées comme validées et continuent de l'appliquer à l'espace de table. Contrairement à la réplication asynchrone, cette approche est également appelée réplication virtuellement synchrone, car les écritures et les validations se produisent dans un mode synchrone logique, mais l'écriture et la validation réelles dans l'espace de table se produisent indépendamment et deviennent asynchrones sur chaque nœud.
Contrairement à la réplication MySQL, un cluster Galera est un véritable esclave multi-maître et multi-thread, un pur secours à chaud, sans besoin de basculement maître ou de séparation lecture-écriture. Cependant, migrer vers Galera Cluster ne signifie pas une réponse automatique à vos problèmes. Galera Cluster ne prend en charge qu'InnoDB, il peut donc y avoir des modifications de conception si vous utilisez des moteurs de stockage MyISAM ou Memory.
Convertir des tables non InnoDB en InnoDB
Galera Cluster vous permet d'utiliser MyISAM, mais ce n'est pas pour cela que Galera Cluster a été conçu. Galera Cluster est conçu pour implémenter strictement la cohérence des données dans tous les nœuds du cluster, ce qui nécessite un puissant moteur de base de données conforme à ACID. InnoDB est un moteur qui possède ces fortes capacités dans ce domaine et il est recommandé d'utiliser InnoDB ; surtout lorsqu'il s'agit de transactions.
Si vous utilisez ClusterControl, vous pouvez facilement déterminer votre ou vos instances de base de données pour toutes les tables MyISAM fournies par Performance Advisors. Vous pouvez le trouver sous l'onglet Performances → Conseillers. Par exemple,
Si vous avez besoin des tables MyISAM et MEMORY, vous pouvez toujours l'utiliser mais assurez-vous Assurez-vous que vos données n'ont pas besoin d'être répliquées. Vous pouvez utiliser vos données stockées en lecture seule et utiliser "START TRANSACTION READONLY" le cas échéant.
Ajouter des clés primaires à vos tables InnoDB
Étant donné que Galera Cluster ne prend en charge qu'InnoDB, il est très important que toutes vos tables aient un index clusterisé (également appelé clé primaire ou clé unique). Pour obtenir les meilleures performances des requêtes, insertions et autres opérations de base de données, il est très important que vous définissiez chaque table avec une ou plusieurs clés uniques, car InnoDB utilise l'index clusterisé pour optimiser les opérations de recherche et DML les plus courantes pour chaque table. . Cela permet d'éviter les longues requêtes au sein du cluster et peut éventuellement ralentir les opérations d'écriture/lecture dans le cluster.
Dans ClusterControl, il y a des conseillers qui peuvent vous en informer. Par exemple, dans votre cluster maître/esclave MySQL Replication, vous recevrez une alarme de la ou une vue de la liste des conseillers. L'exemple de capture d'écran ci-dessous révèle que vous n'avez aucune table sans clé primaire :
Identifier un nœud maître (ou éditeur actif)
Galera Cluster est purement une véritable réplication multi-maître. Cependant, cela ne signifie pas que vous êtes tous libres d'écrire le nœud que vous souhaitez cibler. Une chose à identifier est que lorsque vous écrivez sur un nœud différent et qu'une transaction en conflit sera détectée, vous vous retrouverez dans un problème de blocage comme ci-dessous :
2019-11-14T21:14:03.797546Z 12 [Note] [MY-011825] [InnoDB] *** Priority TRANSACTION:
TRANSACTION 728431, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
MySQL thread id 12, OS thread handle 140504401893120, query id 1414279 Applying batch of row changes (update)
2019-11-14T21:14:03.797696Z 12 [Note] [MY-011825] [InnoDB] *** Victim TRANSACTION:
TRANSACTION 728426, ACTIVE 3 sec updating or deleting
mysql tables in use 1, locked 1
, undo log entries 11409
MySQL thread id 57, OS thread handle 140504353195776, query id 1414228 localhost root updating
update sbtest1_success set k=k+1 where id > 1000 and id < 100000
2019-11-14T21:14:03.797709Z 12 [Note] [MY-011825] [InnoDB] *** WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1663 page no 11 n bits 144 index PRIMARY of table `sbtest`.`sbtest1_success` trx id 728426 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;Le problème avec plusieurs nœuds écrivant sans identifier un nœud d'écriture actif actuel, vous vous retrouverez avec ces problèmes qui sont des problèmes très courants que j'ai rencontrés lors de l'utilisation de Galera Cluster lors de l'écriture sur plusieurs nœuds à le même temps. Pour éviter cela, vous pouvez utiliser une approche de configuration à maître unique :
D'après la documentation,
Pour assouplir le contrôle de flux, vous pouvez utiliser les paramètres ci-dessous :
wsrep_provider_options = "gcs.fc_limit = 256; gcs.fc_factor = 0.99; gcs.fc_master_slave = YES"Ce qui précède nécessite un redémarrage du serveur puisque fc_master_slave n'est pas dynamique.
Activer le mode de débogage pour les conflits de journalisation ou les blocages
Les problèmes de débogage ou de traçage avec votre cluster Galera sont très importants. Les verrous dans Galera sont implémentés différemment par rapport à la réplication MySQL. Il utilise un verrouillage optimiste lorsqu'il s'agit de transactions à l'échelle du cluster. Contrairement à la réplication MySQL, il n'a qu'un verrouillage pessimiste qui ne sait pas si une transaction identique ou conflictuelle est exécutée dans un co-maître sur une configuration multi-maître. Galera utilise toujours le verrouillage pessimiste mais sur le nœud local car il est géré par InnoDB, qui est le moteur de stockage pris en charge. Galera utilise le verrouillage optimiste lorsqu'il va vers d'autres nœuds. Cela signifie qu'aucune vérification n'est effectuée avec les autres nœuds du cluster lorsque les verrous locaux sont atteints (verrouillage pessimiste). Galera suppose qu'une fois que la transaction passe la phase de validation dans le moteur de stockage et que les autres nœuds sont informés, tout ira bien et aucun conflit ne surviendra.
En pratique, il est préférable d'activer wsrep_logs_conflicts. Cela enregistrera les détails des MDL en conflit ainsi que des verrous InnoDB dans le cluster. L'activation de cette variable peut être définie dynamiquement, mais attention une fois qu'elle est activée. Il remplira de manière détaillée votre fichier journal d'erreurs et pourra remplir votre disque une fois que la taille de votre fichier journal d'erreurs sera trop grande.
Soyez prudent avec vos requêtes DDL
Contrairement à la réplication MySQL, l'exécution d'une instruction ALTER ne peut affecter que les connexions entrantes qui nécessitent d'accéder ou de référencer cette table ciblée par votre instruction ALTER. Cela peut également affecter les esclaves si la table est grande et peut entraîner un décalage des esclaves. Cependant, les écritures sur votre maître ne seront pas bloquées tant que vos requêtes n'entrent pas en conflit avec l'ALTER actuel. Cependant, ce n'est pas du tout le cas lors de l'exécution de vos instructions DDL telles que ALTER avec Galera Cluster. Les instructions ALTER peuvent entraîner des problèmes tels que Galera Cluster bloqué en raison d'un verrouillage à l'échelle du cluster ou du démarrage du contrôle de flux pour assouplir la réplication pendant que certains nœuds récupèrent après des écritures volumineuses.
Dans certaines situations, vous pourriez finir par avoir un temps d'arrêt sur votre cluster Galera si cette table est trop volumineuse et est une table principale et vitale pour votre application. Cependant, cela peut être réalisé sans temps d'arrêt. Comme Rick James l'a souligné dans son blog, vous pouvez suivre les recommandations ci-dessous :
RSU contre TOI
- Rolling Schema Upgrade =effectuer manuellement un nœud (hors ligne) à la fois
- Total Order Isolation =Galera se synchronise pour que cela soit fait en même temps (dans la séquence de réplication) sur tous les nœuds. RSU et TOI
Attention :étant donné qu'il n'existe aucun moyen de synchroniser les clients avec le DDL, vous devez vous assurer que les clients sont satisfaits de l'ancien ou du nouveau schéma. Sinon, vous devrez probablement supprimer l'ensemble du cluster tout en basculant simultanément le schéma et le code client.
Un DDL "rapide" peut aussi être fait via TOI. Ceci est une liste provisoire de tels :
- CRÉER/supprimer/renommer la base de données/table
- ALTER pour changer DEFAULT
- ALTER pour modifier la définition de ENUM ou SET (voir les mises en garde dans le manuel)
- Certains PARTITION ALTERs rapides.
- DROP INDEX (autre que PRIMARY KEY)
- AJOUTER UN INDEX ?
- Autres ALTER sur les "petites" tables.
- Avec 5.6 et surtout 5.7 ayant beaucoup de cas ALTER ALGORITHM=INPLACE, vérifiez quels ALTER doivent être faits de quelle manière.
Sinon, utilisez RSU. Procédez comme suit séparément pour chaque nœud :
SET GLOBAL wsrep_OSU_method='RSU';Cela retire également le nœud du cluster.
ALTER TABLE
SET GLOBAL wsrep_OSU_method='TOI';Remet en place, conduisant à une resynchronisation (espérons-le un IST rapide, pas un SST lent)
Préservez la cohérence de votre cluster
Galera Cluster ne prend pas en charge les filtres de réplication tels que binlog_do_db ou binlog_ignore_db car Galera ne s'appuie pas sur la journalisation binaire. Il s'appuie sur le fichier de tampon en anneau, également appelé GCache, qui stocke les jeux d'écriture répliqués le long du cluster. Vous ne pouvez pas appliquer de comportement ou d'état incohérent à ces nœuds de base de données.
Galera, d'autre part, implémente strictement la cohérence des données au sein du cluster. Il est toujours possible qu'il y ait des incohérences là où des lignes ou des enregistrements sont introuvables. Par exemple, la définition de votre variable wsrep_OSU_method sur RSU ou TOI pour vos instructions DDL ALTER peut entraîner un comportement incohérent. Consultez ce blog externe de Percona discutant de l'incohérence avec Galera avec TOI vs RSU.
Définir wsrep_on=OFF et ensuite exécuter des requêtes DML ou DDL peut être dangereux pour votre cluster. Vous devez également passer en revue vos procédures stockées, déclencheurs, fonctions, événements ou vues si les résultats ne dépendent pas de l'état ou de l'environnement d'un nœud. Lorsqu'un ou plusieurs nœuds peuvent être incohérents, cela peut potentiellement entraîner l'arrêt de l'ensemble du cluster. Une fois que Galera détecte un comportement incohérent, Galera tentera de quitter le cluster et de terminer ce nœud. Par conséquent, il est possible que tous les nœuds soient incohérents, vous laissant dans un état de dilemme.
Si un nœud Galera Cluster subit également un plantage, en particulier lors d'une période de trafic élevé, il est préférable de ne pas démarrer le nœud tout de suite. Au lieu de cela, effectuez un SST complet ou apportez une nouvelle instance dès que possible ou une fois que le trafic diminue. Il est possible que le nœud apporte un comportement incohérent qui pourrait avoir des données corrompues.
Séparer les transactions volumineuses et déterminer s'il convient d'utiliser la réplication en continu
Allons droit au but. L'une des fonctionnalités les plus importantes, en particulier sur Galera Cluster 4.0, est la réplication en continu. Dans les versions antérieures de Galera Cluster 4.0, il limite les transactions <2 Go, ce qui est généralement contrôlé par les variables wsrep_max_ws_rows et wsrep_max_ws_size. Depuis Galera Cluster 4.0, vous pouvez envoyer> 2 Go de transactions, mais vous devez déterminer la taille des fragments à traiter lors de la réplication. Il doit être défini par session et les seules variables dont vous devez prendre soin sont wsrep_trx_fragment_unit et wsrep_trx_fragment_size. La désactivation de la réplication en continu est simple car la définition de wsrep_trx_fragment_size = 0 le fera. Notez que la réplication d'une transaction volumineuse entraîne également une surcharge sur les nœuds esclaves (nœuds qui se répliquent par rapport au nœud écrivain actif/maître actuel) puisque les journaux seront écrits dans la table wsrep_streaming_log de la base de données MySQL.
Une autre chose à ajouter, puisque vous avez affaire à une transaction importante, il est considérable que votre transaction puisse prendre un certain temps pour se terminer, il faut donc prendre en compte la valeur élevée de la variable innodb_lock_wait_timeout. Définissez ceci via la session en fonction du temps que vous estimez mais plus grand que le temps que vous estimez pour terminer, sinon augmentez un délai d'attente.
Nous vous recommandons de lire ce blog précédent sur la réplication en continu en action.
Répliquer les instructions GRANT
Si vous utilisez GRANT et les opérations associées, agissez sur les tables MyISAM/Aria dans la base de données `mysql`. Les instructions GRANT seront répliquées, mais pas les tables sous-jacentes. Cela signifie donc que INSERT INTO mysql.user ... ne sera pas répliqué car la table est MyISAM.
Cependant, ce qui précède peut ne plus être vrai depuis Percona XtraDB Cluster (PXC) 8.0 (actuellement expérimental) car les tables de schéma mysql ont été converties en InnoDB, tandis que dans MariaDB 10.4, certaines des tables sont encore au format Aria mais d'autres sont au format CSV ou InnoDB. Vous devez déterminer la version et le fournisseur de Galera dont vous disposez, mais mieux vaut éviter d'utiliser des instructions DML faisant référence au schéma mysql. Sinon, vous risquez d'obtenir des résultats inattendus, sauf si vous êtes sûr qu'il s'agit de PXC 8.0.
Les transactions XA, LOCK/UNLOCK TABLES, GET_LOCK/RELEASE_LOCK ne sont pas pris en charge
Galera Cluster ne prend pas en charge les transactions XA puisque XA Transactions gère la restauration et les validations différemment. Les instructions LOCK/UNLOCK ou GET_LOCK/RELEASE_LOCK sont dangereuses à appliquer ou à utiliser avec Galera. Vous pourriez rencontrer un crash ou des verrous qui ne peuvent pas être tués et rester verrouillés. Par exemple,
---TRANSACTION 728448, ACTIVE (PREPARED) 13356 sec
mysql tables in use 2, locked 2
3 lock struct(s), heap size 1136, 5 row lock(s), undo log entries 5
MySQL thread id 67, OS thread handle 140504353195776, query id 1798932 localhost root wsrep: write set replicated and certified (13)
insert into sbtest1(k,c,pad) select k,c,pad from sbtest1_success limit 5Cette transaction a déjà été débloquée et même supprimée mais en vain. Nous vous suggérons de reconcevoir votre client d'application et de vous débarrasser de ces fonctions lors de la migration vers Galera Cluster.
La stabilité du réseau est un MUST !!!
Galera Cluster peut fonctionner même avec une topologie inter-WAN ou une topologie inter-geo sans aucun problème (consultez ce blog sur la mise en œuvre de la topologie inter-geo avec Galera). Cependant, si votre connectivité réseau entre chaque nœud n'est pas stable ou s'arrête par intermittence pendant une durée insoupçonnée, cela peut être problématique pour le cluster. Il est préférable d'avoir un cluster exécuté dans un réseau privé et local où chacun de ces nœuds est connecté. Lors de la conception d'un nœud en tant que reprise après sinistre, prévoyez de créer un cluster s'il se trouve dans une région ou une zone géographique différente. Vous pouvez commencer à lire notre blog précédent, Utilisation de la réplication de cluster MySQL Galera pour créer un cluster géo-distribué :première partie, car cela pourrait vous aider à mieux décider de la topologie de votre cluster Galera.
Une autre chose à ajouter concernant l'investissement de votre matériel réseau, il serait problématique que votre taux de transfert réseau vous fournisse une vitesse inférieure lors de la reconstruction d'une instance pendant IST ou pire à SST, surtout si votre ensemble de données est massif . Cela peut prendre de longues heures de transfert réseau et cela peut affecter la stabilité de votre cluster, surtout si vous avez un cluster à 3 nœuds alors que 2 nœuds ne sont pas disponibles où ces 2 sont un donneur et un jointeur. Notez que, pendant la phase SST, les nœuds DONOR/JOINER ne peuvent pas être utilisés tant qu'ils ne sont pas enfin capables de se synchroniser avec le cluster principal.
Dans la version précédente de Galera, en ce qui concerne la sélection du nœud donneur, le donneur State Snapshot Transfer (SST) était sélectionné au hasard. Dans Glera 4, il s'est beaucoup plus amélioré et a la capacité de choisir le bon donateur au sein du cluster, car il favorisera un donateur qui peut fournir un transfert d'état incrémentiel (IST) ou choisir un donateur dans le même segment. Alternativement, vous pouvez définir la variable wsrep_sst_donor sur le bon donneur que vous souhaitez toujours choisir.
Sauvegardez vos données et effectuez des tests rigoureux pendant la migration et avant la production
Une fois que vous êtes prêt et que vous avez décidé d'essayer de migrer vos données vers Galera Cluster 4.0, assurez-vous de toujours préparer votre sauvegarde. Si vous avez essayé ClusterControl, il sera plus facile d'effectuer des sauvegardes.
Assurez-vous que vous migrez vers la bonne version d'InnoDB et n'oubliez pas de toujours appliquer et exécuter mysql_upgrade avant de faire le test. Assurez-vous que tous vos tests réussissent le résultat souhaité à partir duquel la réplication MySQL peut vous offrir. Très probablement, il n'y a aucune différence entre le moteur de stockage InnoDB que vous utilisez dans un cluster de réplication MySQL et le cluster MySQL Galera tant que les recommandations et les conseils ont été appliqués et préparés au préalable.
Conclusion
La migration vers Galera Cluster 4.0 n'est peut-être pas la solution technologique de base de données souhaitée. Cependant, cela ne vous empêche pas d'utiliser Galera Cluster 4.0 tant que ses exigences spécifiques peuvent être préparées, configurées et fournies. Galera Cluster 4.0 est désormais devenu un choix et une option viable très puissant, en particulier sur une plate-forme et une solution hautement disponibles. Nous vous suggérons également de lire ces blogs externes sur Galera Caveats ou les limitations de Galera Cluster ou ce manuel de MariaDB.
