Avant de parler cette fonctionnalité, jetons d’abord un coup d’œil à l’histoire de l’architecture de réplication de MySQL. La réplication MySQL est divisée en quatre types :
Réplication ordinaire, asynchrone et synchrone. Elle est simple à construire et largement utilisée. Cette architecture est produite depuis la naissance de MySQL. Ses performances sont très bonnes et on peut dire qu'elle est très mature. Cependant, les données de cette architecture sont asynchrones, il existe donc un risque de perte de la base de données.
réplication semi-synchronisée, semi-synchronisée. Les performances et les fonctionnalités se situent entre asynchrone et entièrement synchrone. Il est né de MySQL5.5 pour compromettre les performances, les avantages et les inconvénients des deux architectures ci-dessus.
réplication synchronisée, synchronisation complète. Actuellement, la technologie officielle de synchronisation complète 5.7 basée sur la réplication de groupe est en version laboratoire et n'est pas loin d'une intégration formelle. La technologie de synchronisation complète apporte davantage de garanties de cohérence des données. Je pense qu’il s’agit d’une direction importante pour la future technologie de synchronisation et qu’elle mérite d’être attendue avec impatience.
cluster mysql. Basé sur le moteur NDB, il est simple à construire et relativement stable. Il s'agit de l'architecture la plus fiable pour la protection des données dans MySQL et c'est actuellement la seule architecture avec une synchronisation complète des données et aucune perte de données. Cependant, je suis pointilleux sur mon entreprise et j'ai de nombreuses restrictions.
Nous parlons aujourd'hui de la deuxième architecture. Nous savons que la réplication ordinaire, c'est-à-dire la réplication asynchrone de MySQL, s'appuie sur le journal binaire MySQL, c'est-à-dire le journal binaire, pour la réplication des données. Par exemple, il y a deux machines, l’une est le maître et l’autre l’esclave.
La réplication normale est : la transaction un (t1) est écrite dans le tampon binlog ; le thread dumper informe l'esclave qu'il y a une nouvelle transaction t1 ; le tampon binlog effectue le point de contrôle de l'esclave ; Le thread io reçoit t1 et écrit dans votre propre journal de relais ; le thread SQL de l'esclave écrit dans la base de données locale. A ce moment, le maître et l'esclave peuvent voir cette nouvelle transaction. Même si le maître décède, l'esclave peut être promu nouveau maître.
La copie anormale est : la transaction un (t1) est écrite dans le tampon binlog ; le thread dumper informe l'esclave qu'il y a une nouvelle transaction t1 ; le tampon binlog effectue un point de contrôle ; l'esclave n'a pas été disponible en raison d'un réseau instable. T1 reçu ; le maître est mort, l'esclave a été promu nouveau maître et t1 a été perdu.
Le gros problème est le suivant : les mises à jour des transactions maître et esclave ne sont pas synchronisées. Même s'il n'y a pas d'anomalies du réseau ou d'autres systèmes, lorsque les affaires sont simultanées, l'esclave doit exécuter le maître. séquentiellement. Transactions par lots, ce qui entraîne des retards importants.
Afin de combler les lacunes des scénarios ci-dessus, mysql a lancé la semi-synchronisation depuis la 5.5. Autrement dit, une fois que le thread dumper du maître a notifié l'esclave, un accusé de réception est ajouté, c'est-à-dire si le code d'indicateur de t1 a été reçu avec succès. C'est-à-dire qu'en plus d'envoyer t1 à l'esclave, le thread dumper est également responsable de la réception de l'accusé de réception de l'esclave. Si une exception se produit et qu'aucun accusé de réception n'est reçu, la réplication sera automatiquement rétrogradée en réplication ordinaire jusqu'à ce que l'exception soit réparée.
On peut voir les nouveaux problèmes apportés par la semi-synchronisation :
Si une exception se produit, elle sera rétrogradée en réplication normale. La probabilité d’incohérence des données sur la machine esclave sera alors réduite, mais pas complètement éliminée.
Le thread du dumper hôte demande plus de travail, ce qui réduira évidemment les performances de l'ensemble de la base de données.
Dans le mode Analyse approfondie de MySQL 5.7 : technologie de réplication semi-synchrone utilisé dans MySQL 5.5 et 5.6, c'est-à-dire si l'esclave ne reçoit pas la transaction, c'est-à-dire avant qu'elle ne soit écrite dans le journal du relais, et le réseau est anormal ou instable, lorsque le maître raccroche et que le système passe à l'esclave, les données des deux côtés seront incohérentes. Dans ce cas, l'esclave aura une donnée de transaction en moins.
Avec la sortie de MySQL 5.7, la technologie de réplication semi-synchrone a été mise à niveau vers une nouvelle architecture de réplication semi-synchrone sans perte, et sa maturité, sa cohérence des données et son efficacité d'exécution ont été considérablement amélioré.
Nouveau La version semi sync ajoute le paramètre rpl_semi_sync_master_wait_point pour contrôler la façon dont la base de données master valide les transactions avant de renvoyer avec succès la transaction de session en mode semi-sync.
Ce paramètre a deux valeurs :
AFTER_COMMIT (valeur par défaut 5,6)
Le maître écrit chaque transaction dans le binlog et la transmet à l'esclave pour l'actualisation sur le disque (journal de relais), et la base de données principale valide la transaction en même temps. Le maître attend le retour de l'esclave pour recevoir le journal du relais. Ce n'est qu'après avoir reçu l'ACK que le maître renvoie le résultat de validation OK au client.
AFTER_SYNC (par défaut dans 5.7, mais pas dans 5.6)
le maître écrit chaque transaction dans binlog, en passant Go à l'esclave et vider sur le disque (journal de relais). Une fois que le maître attend que l'esclave reçoive l'accusé de réception du journal de relais, il soumet la transaction et renvoie le résultat de validation OK au client. Même si la bibliothèque principale tombe en panne, toutes les transactions validées sur la bibliothèque principale sont garanties d'être synchronisées avec le journal de relais de l'esclave.
Par conséquent, la version 5.7 a introduit le mode Analyse approfondie de MySQL 5.7 : technologie de réplication semi-synchrone. Le principal avantage est de résoudre le problème d'incohérence des données entre le crash principal provoqué par Analyse approfondie de MySQL 5.7 : technologie de réplication semi-synchrone. Par conséquent, après l'introduction de Analyse approfondie de MySQL 5.7 : technologie de réplication semi-synchrone. mode, all commits Toutes les données ont été répliquées et la cohérence des données sera améliorée lors du basculement.
L'ancienne version de semi sync est limitée par le thread de dump en raison du dump Le Le thread effectue deux tâches différentes et très fréquentes : transmettre le binlog à l'esclave et attendre le retour de l'esclave. De plus, ces deux tâches sont en série. Le thread de dump doit attendre le retour de l'esclave avant de transmettre la prochaine transaction d'événements. Le thread de vidage est devenu le goulot d'étranglement pour améliorer les performances de l'ensemble de la semi-synchronisation. Dans les scénarios commerciaux à forte concurrence, un tel mécanisme affectera le TPS global de la base de données.
Afin de résoudre les problèmes ci-dessus, dans la version 5.7 du framework semi sync, un thread collecteur d'accusé de réception indépendant est créé, spécifiquement pour recevoir des informations de retour de l'esclave. De cette façon, il y a deux threads sur le maître qui fonctionnent indépendamment, qui peuvent envoyer un binlog à l'esclave et recevoir des commentaires de l'esclave en même temps.
MySQL 5.7 a ajouté le rpl_semi_sync_Analyse approfondie de MySQL 5.7 : technologie de réplication semi-synchrone paramètre, qui peut être utilisé pour contrôler le nombre de retours de réussite de transaction d'écriture esclave acceptés par la bibliothèque principale, offrant ainsi une flexibilité pour la commutation d'architecture à haute disponibilité.
Comme le montre la figure, lorsque la valeur de comptage est de 2, le maître doit attendre les accusés de réception de deux esclaves.
L'ancienne version de la réplication semi-synchrone ajoutera un verrou mutex au binlog dans la session d'écriture du binlog de soumission principale et le thread de vidage lisant le binlog En conséquence, la lecture et l'écriture des fichiers binlog sont sérialisées et il existe un problème de concurrence.
MySQL 5.7 a optimisé le verrouillage du journal binaire dans les deux aspects suivants :
1. Suppression du verrouillage mutex du thread de vidage sur le journal binaire
2. sécurité
MySQL 5.7 introduit une nouvelle variable slave-parallel-type, ses valeurs configurables sont :
1. DATABASE (valeur par défaut avant 5.7), méthode de réplication parallèle basée sur la bibliothèque ;
2. LOGICAL_CLOCK (nouvelle valeur en 5.7), méthode de réplication parallèle basée sur la soumission de groupe ; la version 5.6 prend également en charge la réplication dite parallèle, mais son parallélisme est uniquement basé sur DATABASE, c'est-à-dire basé sur des bibliothèques. S'il y a plusieurs BASES DE DONNÉES dans l'instance de base de données MySQL de l'utilisateur, cela peut en effet être d'une grande aide pour la vitesse de réplication esclave. Si l'instance utilisateur n'a qu'une seule base de données, la lecture parallèle ne peut pas être réalisée et les performances seront encore pires. le fil unique d'origine.
MySQL 5.7 ajoute un nouveau mode parallèle : les transactions qui entrent dans la phase COMMIT en même temps se voient attribuer le même numéro de séquence. Ces transactions avec le même numéro de séquence peuvent être exécutées simultanément dans la base de données de secours.
MySQL 5.7 implémente véritablement la réplication parallèle. La raison principale en est que la lecture du serveur esclave est cohérente avec celle de l'hôte, c'est-à-dire que la lecture parallèle est effectuée sur l'esclave tout comme elle est exécutée sur celui-ci. en parallèle sur le serveur maître. Il n'y a plus de restrictions sur la réplication parallèle basée sur la bibliothèque, et il n'y a pas d'exigences particulières pour le format de journal binaire (il n'y a pas non plus d'exigences pour la réplication parallèle basée sur la bibliothèque).
Par conséquent, la séquence qui peut être concurrente dans la séquence suivante est (le premier numéro est last_commit et le numéro suivant est séquence_number) :
Règles parallèles de la base de données de secours : lors de la distribution d'un transaction , dont le numéro de séquence last_commit est inférieur au numéro de séquence minimum de la transaction en cours d'exécution, l'exécution est autorisée. Par conséquent :trx1 1…..2 trx2 1………….3 trx3 1…………………….4 trx4 2……………………….5 trx5 3…………………………..6 trx6 3………………………………7 trx7 6………………………………..8
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!
mysql modifier le nom de la table de données
MySQL crée une procédure stockée
La différence entre MongoDB et MySQL
Comment vérifier si le mot de passe MySQL est oublié
mysql créer une base de données
niveau d'isolement des transactions par défaut de MySQL
La différence entre sqlserver et mysql
mysqlmot de passe oublié
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
