Quel est le principe de la réplication maître-esclave MySQL ?

Principe de réplication maître-esclave MySQL : d'abord, la bibliothèque maître envoie des événements de mise à jour à la bibliothèque esclave ; puis la bibliothèque esclave lit l'enregistrement de mise à jour et exécute enfin l'enregistrement de mise à jour ; avec la bibliothèque principale.

Recommandations d'apprentissage gratuites associées : tutoriel vidéo MySQL

Principe de réplication maître-esclave MySQL :

Pourquoi faire une réplication maître-esclave

• Dans entreprise complexe Dans le système, il existe un tel scénario. Il existe une instruction SQL qui nécessite le verrouillage de la table, ce qui entraîne une incapacité temporaire à utiliser le service de lecture, ce qui affectera grandement l'activité en cours. Utilisez la réplication maître-esclave. La bibliothèque maître est responsable de l'écriture et la bibliothèque esclave est responsable de la lecture. De cette façon, même si la base de données maître verrouille la table, le fonctionnement normal de l'entreprise peut être garanti par la lecture à partir de la base de données esclave.

• Effectuez une sauvegarde à chaud des données. Si la base de données principale tombe en panne, elle peut être remplacée à temps pour garantir la disponibilité de l'entreprise.

• Extension de l'architecture. Le volume d'activité devient de plus en plus important et la fréquence d'accès aux E/S est trop élevée, ce qui ne peut pas être satisfait par une seule machine. À l'heure actuelle, le stockage multi-bases de données est utilisé pour réduire la fréquence d'accès aux E/S disque et. améliorer les performances d'E/S d'une seule machine.

Processus de réplication maître-esclave MySQL

Mise à jour des événements de la base de données principale (mise à jour, insertion , delete) est écrit dans le binlog

La bibliothèque principale crée un thread de vidage du binlog et envoie le contenu du binlog à la bibliothèque esclave

La bibliothèque esclave démarre et initie une connexion et se connecte à la bibliothèque principale

Après le démarrage de la bibliothèque esclave, créez un thread d'E/S, lisez le contenu du binlog de la bibliothèque principale et écrivez-le dans le journal de relais

Après le démarrage de la bibliothèque esclave , créez un thread SQL et lisez le contenu du journal de relais, exécutez l'événement de mise à jour de lecture à partir de la position Exec_Master_Log_Pos et écrivez le contenu mis à jour dans la base de données de l'esclave

Remarque : le processus ci-dessus est un processus relatif, pas un processus absolu

MySQL Le principe de la réplication maître-esclave

La réplication maître-esclave MySQL est un processus de réplication asynchrone La base de données maître envoie des événements de mise à jour à la base de données esclave. , et la base de données esclave lit les enregistrements de mise à jour et exécute les enregistrements de mise à jour, de sorte que la base de données esclave Le contenu soit cohérent avec la bibliothèque principale.

binlog : journal binaire, un fichier binaire qui enregistre tous les journaux d'événements de mise à jour dans la bibliothèque principale. Binlog est un fichier qui enregistre tous les enregistrements de modifications (structure et contenu de la base de données) à partir du moment où le service de base de données est démarré. Dans la bibliothèque principale, tant qu'un événement de mise à jour se produit, il sera écrit dans le binlog dans l'ordre, puis transmis à la bibliothèque esclave en tant que source de données pour la réplication à partir de la bibliothèque esclave.

Thread de sortie Binlog : chaque fois qu'une bibliothèque esclave se connecte à la bibliothèque principale, la bibliothèque principale crée un thread et envoie le contenu du binlog à la bibliothèque esclave. Pour chaque événement SQL sur le point d'être envoyé à la bibliothèque esclave, le thread de sortie binlog le verrouillera. Une fois l'événement lu par le thread, le verrou sera libéré, même lorsque l'événement est complètement envoyé à la bibliothèque esclave, le verrou sera libéré.

Dans la bibliothèque esclave, lorsque la réplication démarre, la bibliothèque esclave créera le thread d'E/S de la bibliothèque esclave et le thread SQL de la bibliothèque esclave pour le traitement de la copie.

Thread d'E/S de la bibliothèque esclave : lorsque l'instruction START SLAVE commence à s'exécuter dans la bibliothèque esclave, la bibliothèque esclave crée un thread d'E/S, qui se connecte à la bibliothèque principale et demande à la bibliothèque principale d'envoyer la mise à jour. enregistrements dans le binlog vers De la bibliothèque. Le thread d'E/S de la bibliothèque esclave lit les mises à jour envoyées par le thread de sortie binlog de la bibliothèque principale et copie ces mises à jour dans des fichiers locaux, y compris les fichiers journaux de relais.

Thread SQL de la bibliothèque : Créez un thread SQL à partir de la bibliothèque. Ce thread lit les événements de mise à jour écrits dans le journal de relais par le thread d'E/S de la bibliothèque et les exécute.

Pour résumer, on constate que :

Pour chaque connexion de réplication maître-esclave, il y a trois threads. Une bibliothèque principale avec plusieurs bibliothèques esclaves crée un thread de sortie binlog pour chaque bibliothèque esclave connectée à la bibliothèque principale. Chaque bibliothèque esclave possède son propre thread d'E/S et son propre thread SQL.

En créant deux threads indépendants, la bibliothèque esclave sépare la lecture et l'écriture de la bibliothèque esclave lors de la réplication. Par conséquent, même si le thread responsable de l’exécution s’exécute plus lentement, le thread responsable de la lecture de l’instruction update ne devient pas plus lent. Par exemple, si la bibliothèque esclave n'a pas fonctionné depuis un certain temps, lorsqu'elle est démarrée ici, bien que son thread SQL s'exécute lentement, son thread d'E/S peut lire rapidement tout le contenu du binlog de la bibliothèque principale. De cette manière, même si la bibliothèque esclave s'arrête avant que le thread SQL ait terminé l'exécution de toutes les instructions de lecture, le thread d'E/S a au moins entièrement lu tout le contenu et l'a sauvegardé en toute sécurité dans le journal de relais local de la bibliothèque esclave. , prêt à exécuter des instructions au prochain démarrage de la bibliothèque esclave.

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!