Maison  >  Article  >  base de données  >  Qu'est-ce que la réplication maître-esclave MySQL

Qu'est-ce que la réplication maître-esclave MySQL

青灯夜游
青灯夜游original
2022-06-27 15:37:045129parcourir

Dans MySQL, la réplication maître-esclave signifie que les données peuvent être copiées d'un nœud maître du serveur de base de données MySQL vers un ou plusieurs nœuds esclaves. La réplication asynchrone est utilisée par défaut. Les avantages de l'utilisation de la réplication maître-esclave : 1. Laissez la base de données maître être responsable de l'écriture et la base de données esclave se charge de la lecture. Lorsque la base de données maître verrouille la table, le fonctionnement normal de l'entreprise peut être assuré en lisant à partir de l'esclave. base de données ; 2. Une sauvegarde à chaud des données peut être effectuée ; 3. L'extension de l'architecture peut réduire la fréquence d'accès aux E/S du disque et améliorer les performances d'E/S d'une seule machine.

Qu'est-ce que la réplication maître-esclave MySQL

L'environnement d'exploitation de ce tutoriel : système windows7, version mysql8, ordinateur Dell G3.

Qu'est-ce que la réplication maître-esclave MySQL ?

La réplication maître-esclave MySQL signifie que les données peuvent être copiées d'un nœud maître du serveur de base de données MySQL vers un ou plusieurs nœuds esclaves. MySQL utilise la réplication asynchrone par défaut, de sorte que le nœud esclave n'a pas besoin d'accéder au serveur maître à tout moment pour mettre à jour ses propres données. Les mises à jour des données peuvent être effectuées sur une connexion distante. Le nœud esclave peut copier toutes les bases de données ou des bases de données spécifiques. la base de données master, ou des tables spécifiques.

Pourquoi avons-nous besoin d'une réplication maître-esclave ?

1. Dans un système aux activités complexes, il existe un scénario dans lequel une instruction SQL doit verrouiller la table, ce qui entraîne une indisponibilité temporaire du service de lecture, ce qui affectera grandement l'activité en cours d'exécution. laissez la bibliothèque maître La bibliothèque est 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. 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.

Principe de réplication mysql

Principe :

(1) Le serveur maître enregistre les modifications de données dans le journal binlog binaire. Lorsque les données sur le maître changent, les modifications sont écrites dans le journal binaire ;

(2) Le serveur esclave détectera si le journal binaire maître a changé dans un certain intervalle de temps, s'il change, il démarrera un I/OThread pour demander l'événement binaire maître

(3) En même temps, le nœud maître Le thread /O démarre un thread de vidage pour lui envoyer des événements binaires et les enregistrer dans le journal de relais local du nœud esclave. Le nœud esclave démarrera le thread SQL pour lire le journal binaire à partir du journal de relais et le relire. Les données restent cohérentes avec celles du nœud principal. Enfin, I/OThread et SQLThread entreront en état de veille et attendront leur prochain réveil.

C'est-à-dire :

  • La bibliothèque esclave générera deux threads, un thread d'E/S et un thread SQL
  • Le thread d'E/S demandera le binlog de la bibliothèque principale et écrira le binlog obtenu ; dans le fichier de journal de relais local (journal de relais) ;
  • La bibliothèque principale générera un thread de vidage de journal pour transférer le binlog vers le thread d'E/S de la bibliothèque esclave ;
  • Le thread SQL lira les journaux dans le fichier journal de relais, et analysé en instructions SQL pour exécution une par une 

Remarque :

  • –le maître enregistre les instructions d'opération dans le journal binlog, puis accorde à l'esclave l'autorisation de connexion à distance (le maître doit activer le binaire binlog) fonction log ; généralement pour des raisons de sécurité des données, l'esclave active également la fonction binlog).

  • –l'esclave ouvre deux threads : le thread IO et le thread SQL. Parmi eux : le thread IO est responsable de la lecture du contenu du binlog du maître dans le journal du relais ; le thread SQL est responsable de la lecture du contenu du binlog du journal du relais et de sa mise à jour dans la base de données de l'esclave, afin de garantir que l'esclave les données et les données de base sont maintenues cohérentes.

  • –La réplication MySQL nécessite au moins deux services Mysql. Bien entendu, les services Mysql peuvent être distribués sur différents serveurs, ou plusieurs services peuvent être démarrés sur un seul serveur.

  • –La réplication MySQL est préférable pour garantir que les versions Mysql sur les serveurs maître et esclave sont les mêmes (si les versions ne peuvent pas être cohérentes, assurez-vous que la version du nœud maître est inférieure à la version du nœud esclave )

  • –maître et esclave Le temps entre les deux nœuds doit être synchronisé

Quest-ce que la réplication maître-esclave MySQL

Étapes spécifiques :

1 La bibliothèque esclave se connecte à la bibliothèque principale en exécutant manuellement le changement de maître pour déclaration, et fournit toutes les conditions pour l'utilisateur connecté (utilisateur, mot de passe, port, ip) et indique à la bibliothèque esclave la position de départ du journal binaire (numéro de position du nom de fichier start slave

2). entre le thread IO de la bibliothèque esclave et le thread de dump de la bibliothèque principale.

3. Sur la base du nom de fichier et du numéro de position fournis par l'instruction de changement maître vers de la bibliothèque esclave, le thread IO initie une requête binlog à la bibliothèque maître.

4. Le thread de dump de la bibliothèque principale envoie le binlog local au thread IO de la bibliothèque esclave sous forme d'événements selon la demande de la bibliothèque esclave.

5. Recevez les événements binlog du thread IO de la bibliothèque et stockez-les dans le journal de relais local. Les informations transmises seront enregistrées dans master.info

.

6. Appliquez le journal de relais à partir du thread SQL de la base de données et enregistrez les informations appliquées dans relay-log.info. Par défaut, le relais appliqué sera automatiquement purgé

formulaire maître-esclave mysql

. (1) Un maître et un esclave

Quest-ce que la réplication maître-esclave MySQL

(2) Copie maître-maître

Quest-ce que la réplication maître-esclave MySQL

(3) Un maître et plusieurs esclaves

Quest-ce que la réplication maître-esclave MySQL

(4) Plusieurs maîtres et un De

Quest-ce que la réplication maître-esclave MySQL

(5) Réplication en cascade

Quest-ce que la réplication maître-esclave MySQL

analyse du délai de synchronisation maître-esclave de mysql

la réplication maître-esclave de mysql est une opération à thread unique, et la bibliothèque principale effectue tous les DDL Les journaux générés par et DML sont écrits dans le binlog. Étant donné que le binlog est écrit de manière séquentielle, il est très efficace. Le thread SQL de l'esclave relit les événements d'opération DDL et DML de la bibliothèque principale de l'esclave. Les opérations d'E/S de DML et DDL sont aléatoires et non séquentielles, donc le coût est beaucoup plus élevé. D'un autre côté, puisque le thread SQL est également monothread, lorsque la concurrence de la bibliothèque principale est élevée, le nombre de DML générés. dépasse la capacité du thread SQL de l'esclave. La vitesse de traitement, ou lorsqu'il y a une instruction de requête volumineuse dans l'esclave qui provoque une attente de verrouillage, alors le délai se produit.

Solution :

1. La mise en œuvre de la couche de persistance de l'entreprise adopte une architecture de sous-base de données, et le service mysql peut être étendu en parallèle pour répartir la pression.

2. Séparez la lecture et l'écriture dans une seule bibliothèque, un maître et plusieurs esclaves, le maître écrit et les esclaves lisent, pour répartir la pression. De cette façon, la pression de la bibliothèque esclave est supérieure à celle de la bibliothèque principale, protégeant ainsi la bibliothèque principale.

3. L'infrastructure de service ajoute une couche de cache Memcache ou Redis entre l'entreprise et MySQL. Réduisez la pression de lecture de MySQL.

4. MySQL pour différentes entreprises est physiquement placé sur différentes machines pour répartir la pression.

5. Utilisez un meilleur périphérique matériel que la bibliothèque principale car l'esclave aura moins de pression et le délai deviendra naturellement plus petit.

6. Utilisez un équipement matériel plus puissant

[Recommandations associées : Tutoriel vidéo 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!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn