Introduction détaillée aux nouvelles fonctionnalités de réplication de MySQL 8.0.2

Traducteur : équipe Zhishutang Xingyao

Nouvelles fonctionnalités de la réplication MySQL 8.0.2

MySQL 8 s'améliore de plus en plus, et cela est également dû à notre équipe R&D de réplication MySQL. recrudescence. Nous avons travaillé dur pour améliorer la réplication MySQL à tous les niveaux, en introduisant de nouvelles fonctionnalités intéressantes. De plus, nous écoutons les suggestions et les commentaires de la communauté. Par conséquent, nous sommes honorés d’assister avec vous à la sortie marquante de la dernière version (MySQL 8.0.2), et nous avons résumé certains des changements notables. Suivez notre blog ci-dessous pour partager quelques informations sur ces nouvelles fonctionnalités.

Nous avons renforcé la réplication du groupe MySQL, principalement dans les aspects suivants :

• Ne pas autoriser les modifications des membres qui quittent le groupe : chaque fois qu'un membre du groupe quitte le groupe. Groupe , les membres qui quittent définiront automatiquement super_read_only, cela peut empêcher les modifications inattendues causées par l'administrateur de base de données, les utilisateurs ou les routeurs/proxy/équilibreurs de charge, etc. En plus de la valeur par défaut selon laquelle les membres qui quittent la réplication de groupe ne peuvent pas être modifiés, l'écriture peut également être interdite à partir du moment où ils rejoignent le groupe. Nous pouvons également définir le paramètre super_read_only au démarrage du serveur et démarrer le plug-in de réplication de groupe. Une fois l'opération de réplication de groupe réussie, elle ajustera automatiquement la valeur de super_read_only. En mode multi-maître, tous les nœuds ne définiront pas le paramètre super_read_only ; en mode mono-maître, à l'exception du nœud maître, tous les autres nœuds définiront super_read_only sur ON. Si malheureusement votre réplication de groupe ne démarre pas, le paramètre super_read_only ne sera pas défini et aucune opération d'écriture ne sera possible. Ces dernières modifications s'appliquent également à MySQL 5.7.19 et MySQL 8.0.2. Une grande partie de tout cela est due au fait que nous avons écouté les commentaires de la communauté, puis les avons développés et améliorés. --Ici Merci à Kenny Gryp

• Vous pouvez afficher plus d'informations dans Performance Schema : Dans les tableaux existants de Performance Schema, la lisibilité des informations statistiques associées a été améliorée. Les tables "replication_group_members" et "replication_group_member_stats" ont également été étendues. Vous pouvez désormais voir clairement les informations sur le rôle des membres du groupe, les versions des membres du groupe et les compteurs de transactions (local/distant)

• Réussi. Attribuez des poids pour spécifier l'élection de la base de données maître : les utilisateurs peuvent contrôler l'élection de la base de données maître en spécifiant les poids des membres du groupe. Lorsque le nœud maître existant quitte la réplication de groupe, le nœud avec le poids le plus élevé sera promu au rang de nœud maître. .

• Ajout de quelques éléments de réglage fin au mécanisme de contrôle de flux : les utilisateurs peuvent désormais affiner les composants de contrôle de flux. Vous pouvez définir des quotas minimum pour chaque membre, des quotas minimum de validation pour l'ensemble du groupe, des fenêtres de contrôle de processus, etc.

MySQL 8.0.1 a ajouté de nombreuses fonctionnalités intéressantes au framework principal de réplication MySQL. MySQL 8.0.2 a apporté de grandes améliorations sur cette base, principalement comme suit :

• Améliorer la gestion du thread récepteur (IO), même si le disque est plein : Cette fonctionnalité améliore Améliore l'efficacité de la coordination interne entre le récepteur et les autres threads et réduit les conflits entre eux. Pour les utilisateurs finaux, cela signifie que si le disque est plein et que le thread récepteur se bloque, il ne bloque plus les opérations de surveillance telles que SHOW SLAVE STATUS. Il introduit également un nouvel état de thread (le thread récepteur attend des ressources d'espace disque). De plus, lorsque le disque est plein et que vous ne pouvez pas libérer de l'espace disque pour permettre au thread récepteur de continuer son travail inachevé, cette fois vous pouvez). arrêtez-le manuellement et il n'y aura généralement aucun problème. Mais si une transaction d'écriture est effacée à ce moment-là et que le journal de relais n'est pas dans un état cohérent, vous devez faire particulièrement attention lorsque le thread récepteur interroge le journal de relais et attend que de l'espace disque soit disponible.

• Enregistrez plus d'informations sur les métadonnées dans le journal binaire : ajoutez la longueur des transactions aux événements du journal des transactions global. Cela peut être d'une grande aide pour nos futurs travaux d'optimisation et améliore également la lisibilité du journal binaire.

Si vous étudiez le fonctionnement interne de la réplication MySQL, nous serions heureux de vous annoncer que nous avons effectué un nettoyage et ajouté un ajout intéressant à nos services de composants de base :

• Les événements d'adhésion à un groupe peuvent être propagés à d'autres composants à l'intérieur. En tirant parti de la nouvelle architecture de service sous-jacente, le plug-in de réplication de groupe peut désormais informer les autres composants du serveur des événements associés aux membres. Par exemple, informer les membres du groupe d'un changement de rôle, d'une perte d'arbitrage, etc. D'autres composants peuvent répondre à ces informations, et les utilisateurs peuvent également développer leurs propres composants pour enregistrer et détecter ces événements.

• Supprimer les informations redondantes sur les nœuds de la structure interne de XCom (une implémentation standard de Paxos qui peut strictement garantir l'exactitude) : Nous avons supprimé certaines informations redondantes de la structure de XCom, ce qui en fait plus simple, moins sujet aux erreurs et plus facile à surveiller quels nœuds rejoignent ou quittent le cluster, tout en conservant les informations précédentes dans le système.

• Plusieurs améliorations du noyau XCom et un nouveau style de codage : Nous avons corrigé plusieurs bugs dans En tant que développeur, et en regardant le code source de notre implémentation Paxos, vous constaterez que le code révisé sera plus facile à lire et à comprendre.

• Suppression de certains codes sources pour la conversion des journaux binaires des anciennes versions : dans ce travail de nettoyage, nous avons effacé certains journaux binaires produits par l'ancienne version de Ma base de données et les avons convertis en ceux qui peuvent être reconnu par la nouvelle version du Code (actuellement ne prend en charge que MySQL5.0 et supérieur).

Encore une chose intéressante, nous avons modifié les paramètres de réplication par défaut suivants dans MySQL 8.0.2 :

• Les informations sur les métadonnées répliquées sont stockées dans le système INNODB. tables par défaut : cela rendra la fonction de réplication MySQL plus puissante. Lorsque la réplication plante et récupère automatiquement, les caractéristiques des transactions INNODB peuvent être utilisées pour garantir l'exactitude de la récupération à l'emplacement spécifié. De plus, les nouvelles fonctionnalités nécessitent également que les métadonnées soient stockées sous forme de tables (telles que la réplication de groupe et la réplication multi-source), ce qui est cohérent avec le nouveau dictionnaire de données de MySQL 8.

• L'analyse de hachage basée sur les données de ligne est activée par défaut : ce n'est peut-être pas une approche largement reconnue, mais lorsque la base de données esclave comporte des tables sans contraintes de clé primaire, les performances seront améliorées améliorer. Dans ce cas, cette modification minimisera la pénalité de performances lors de l'utilisation de la réplication basée sur les lignes, car elle réduira le nombre d'analyses de table requises pour mettre à jour toutes les lignes (le paramètre slave_rows_search_algorithms est par défaut TABLE_SCAN, INDEX_SCAN, HASH_SCAN).

• Le paramètre transaction-write-set-extraction est activé par défaut : utilisez l'extraction du jeu d'écriture, démarrez la réplication de groupe pour les utilisateurs ou utilisez les dépendances basées sur WRITESET sur le serveur maître pour suivre le maître.

• Le journal binaire est activé par défaut Délai d'expiration : expire-logs-days est défini sur 30 (30 jours) par défaut

Comme vous sais, nous avons été très occupés. En fait, MySQL 8.0.2 Milestone Release a été publié. Du côté de la réplication, nous sommes vraiment ravis de voir de nombreuses fonctionnalités intéressantes ajoutées.

Il y aura un blog dédié pour présenter et expliquer ces fonctions. Vous pouvez également le télécharger vous-même pour le tester (adresse de téléchargement). Ce à quoi nous devons faire attention, c'est la version MySQL 8.0.2 ou DMR. Il n'y a pas de GA. Utilisez-le à vos propres risques. Et n’oubliez pas, nous apprécions et apprécions vos commentaires. Vous pouvez nous faire part de vos commentaires via des rapports de bogues, des rapports de fonctionnalités, copier la liste de diffusion ou simplement laisser un commentaire sur cet article de blog (ou ultérieur). MySQL 8 sera de mieux en mieux et de plus en plus excitant.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!