Que sont les journaux MySQL Binlog et la réplication maître-esclave ?

1. Introduction au journal Binlog

Binlog est l'abréviation de Binary log, c'est-à-dire journal binaire. Les trois fonctions principales de Binlog incluent la conversion des E/S aléatoires en E/S séquentielles pour la persistance, la réalisation de la réplication maître-esclave et la prise en charge de la récupération des données. Cet article se concentre sur les problèmes liés à la réplication maître-esclave.

Le journal Binlog se compose d'un fichier d'index et de nombreux fichiers journaux. Chaque fichier journal se compose d'un nombre magique et d'un événement. Chaque fichier journal se termine par un événement de type Rotate.

Pour chaque événement, il peut être divisé en deux parties : l'en-tête de l'événement et le corps de l'événement :

La structure de l'en-tête de l'événement est la suivante :

La structure du corps de l'événement comprend une taille fixe et une taille amovible. Changez la taille en deux parties.

En ce qui concerne le format des journaux Binlog, il vous suffit d'avoir une compréhension simple. Les étudiants intéressés peuvent apprendre en profondeur.

2. Réplication maître-esclave

2.1 Le processus de réplication maître-esclave

Le processus de réplication maître-esclave MySQL est à peu près le suivant :

• La bibliothèque maître synchronise son propre journal Binlog à la bibliothèque esclave

• Slave Le thread IO de la bibliothèque écrit le contenu du journal Binlog dans le journal de relais

• Le thread SQL de la bibliothèque prend le journal de relais et le lit dans la base de données

2.2 GTID

GTID fait référence à l'indicateur de transaction global, utilisé pour marquer la situation de synchronisation maître-esclave.

Lorsque le nœud maître valide une transaction, le GTID sera généré et enregistré dans le journal Binlog. Lorsque le thread IO de la bibliothèque esclave lit le journal Binlog, il le stockera dans son propre Relaylog et définira cette valeur sur gtid_next, qui est le prochain GTID à lire. Lors de la lecture de ce gtid_next à partir de la bibliothèque, il comparera s'il existe. est ce GTID dans votre log Binlog :

• S'il y a cet enregistrement, cela signifie que la transaction avec ce GTID a été exécutée et peut être ignorée (idempotente).

• S'il n'y a pas un tel enregistrement, l'esclave exécutera la transaction GTID et l'enregistrera dans son propre journal Binlog.

2.3 Modèle de réplication

• Réplication asynchrone : le maître transmet le journal Binlog à l'esclave. Le maître n'a pas besoin d'attendre que l'esclave mette à jour avec succès les données dans le journal Relay. la transaction. Ce mode sacrifie la cohérence des données.

• Réplication synchrone : Chaque fois que l'utilisateur opère, il faut s'assurer que le maître et l'esclave sont exécutés avec succès avant de le renvoyer à l'utilisateur.

• Réplication semi-synchrone : Elle ne nécessite pas que l'esclave s'exécute avec succès, mais elle peut demander au maître de revenir après avoir reçu avec succès le journal du maître.

2.4 Mode MGR

Algorithme de consensus distribué Paxos. Un cluster de bases de données se compose d'au moins 3 nœuds ou plus. La soumission de transaction doit être approuvée par plus de la moitié des nœuds avant de pouvoir être soumise.

MGR est une solution de réplication sans partage, mise en œuvre sur la base du protocole paxos distribué. Chaque instance dispose d'une copie complète indépendante des données. Le cluster vérifie automatiquement les informations sur les nœuds et synchronise les données. Le mode mono-maître et le mode multi-maître sont fournis. Le mode multi-maître peut sélectionner automatiquement le maître après la panne de la base de données principale. Toutes les écritures sont effectuées sur le nœud maître. Le mode multi-maître prend en charge l'écriture multi-nœuds. Le cluster offre une tolérance aux pannes. Tant que la plupart des nœuds fonctionnent normalement, le cluster peut fournir des services normalement.

2.5 Lecture parallèle

La lecture des transactions est le processus d'exécution du journal de relais à partir du thread SQL de la bibliothèque. La lecture parallèle vise à améliorer l'efficacité de ce processus et à effectuer des transactions qui peuvent être effectuées en parallèle en même temps.

• Lecture parallèle basée sur une horloge logique

Parce que les propres transactions de MySQL ont des caractéristiques ACID, les transactions synchronisées de la base de données maître à la base de données esclave, tant que l'heure logique de leur exécution se chevauche, alors les deux transactions seront Peut effectuer en toute sécurité une lecture parallèle.

• Lecture parallèle basée sur writeSet

stocke l'ensemble de transactions sur une zone de bloc de données spécifique au cours d'une certaine période de temps dans un HashMap. Les conflits ne se produisent pas entre les transactions au sein du même groupe ou entre les transactions dont les horloges logiques se chevauchent. Dans le cas contraire, il est impossible de déterminer s'il existe un conflit.

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!