Pourquoi effectuer une réplication maître-esclave ?

Après avoir rencontré un retard maître-esclave MySQL, j'ai commencé à réfléchir à ce qu'est la réplication maître-esclave ? Comment y parvient-on ? Comment ça marche ? J'ai donc commencé à rechercher des informations et des articles, et maintenant je résume ici ce que j'ai compris pour approfondir mon impression.

Pourquoi devons-nous effectuer une réplication maître-esclave ?

1. Dans un système aux activités complexes, il existe une situation dans laquelle une instruction SQL doit verrouiller la table, ce qui entraîne une incapacité temporaire à utiliser le service de lecture, ce qui affectera grandement l'utilisation du maître. -réplication esclave. Laissez la bibliothèque principale être responsable de l'écriture et la bibliothèque esclave est responsable de la lecture. De cette façon, même si la bibliothèque principale verrouille la table, le fonctionnement normal de l'entreprise peut être assuré en lisant à partir de la bibliothèque esclave.

2. Sauvegarde à chaud des données

3. 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.

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

binlog : journal binaire, un fichier binaire qui stocke tous les journaux d'événements de mise à jour dans la bibliothèque principale.

La base de la réplication maître-esclave est que la base de données maître enregistre toutes les modifications apportées à la base de données dans le binlog. Binlog est un fichier qui enregistre toutes les modifications apportées à la structure ou au contenu de la base de données à partir du démarrage du serveur de base de données.

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

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 fil de discussion 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 copie démarre, la bibliothèque esclave créera deux threads pour le traitement :

Thread d'E/S de la bibliothèque esclave. Lorsque l'instruction START SLAVE commence à s'exécuter à partir de 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 les enregistrements de mise à jour dans le binlog à la bibliothèque esclave.
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 base de données. 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.

Vous pouvez savoir que pour chaque connexion de réplication maître-esclave, il existe 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 copie. 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 façon, même si la bibliothèque esclave s'arrête avant que le thread SQL ait fini d'exécuter 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.

Vérifier l'état de la réplication maître-esclave

Lorsque la réplication maître-esclave est en cours, si vous souhaitez vérifier l'état d'exécution des deux threads dans la bibliothèque esclave, vous pouvez exécuter " show slave statusG" dans l'instruction de la bibliothèque esclave, les champs suivants peuvent vous donner les informations souhaitées :

Master_Log_File — 上一个从主库拷贝过来的binlog文件
Read_Master_Log_Pos — 主库的binlog文件被拷贝到从库的relay log中的位置
Relay_Master_Log_File — SQL线程当前处理中的relay log文件
Exec_Master_Log_Pos — 当前binlog文件正在被执行的语句的位置

L'ensemble du processus de réplication maître-esclave peut être compris à travers le schéma suivant :

• Étape 1 : Les événements de mise à jour (mise à jour, insertion, suppression) de la base de données principale sont écrits dans le binlog

• Étape 2 : Initiez une connexion à partir de la base de données, connectez-vous à la bibliothèque principale

• Étape 3 : À ce stade, la bibliothèque principale crée un thread de vidage du journal binaire et envoie le journal binaire contenu à la bibliothèque esclave

• Étape 4 : Après avoir démarré depuis la bibliothèque, créez un thread d'E/S, lisez le contenu du binlog transmis par la bibliothèque principale et écrivez-le dans le journal du relais

• Étape 5 : Un thread SQL sera également créé. 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 le fichier. base de données de l'esclave

注：上面的解释是解释每一步做了什么，整个mysql主从复制是异步的，不是按照上面的步骤执行的。

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!