Exemple détaillé de la façon dont MySQL implémente le processus de réplication maître-esclave (image)

Cet article présente principalement en détail le processus de mise en œuvre de la réplication maître-esclave MySQL, qui a une certaine valeur de référence. Les amis intéressés peuvent s'y référer

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

transmet les opérations DDL et DML de la base de données maître à la base de données esclave via des journaux binaires (BINLOG), puis réexécute (refait) ces journaux rendant ainsi les données de la base de données esclave cohérentes avec celles du maître ; base de données La base de données reste cohérente.

2. Le rôle de la réplication maître-esclave

1. S'il y a un problème avec la base de données maître, vous pouvez passer à la base de données esclave.

2. La séparation en lecture et en écriture peut être effectuée au niveau de la base de données

3. Une sauvegarde quotidienne peut être effectuée sur la base de données secondaire

3.

Journal binaire : Journal binaire de la base de données maître

Journal relais : Journal relais du serveur esclave

Non. Étape : Le maître écrit l'enregistrement de l'opération en série dans le fichier binlog avant que chaque donnée de mise à jour de transaction ne soit terminée.

Étape 2 : salve ouvre un thread d'E/S Ce thread ouvre une connexion normale sur le maître et sa tâche principale est le processus de vidage du journal binaire. Si la progression de la lecture a rattrapé le maître, il entre en état de veille et attend que le maître génère de nouveaux événements. Le but ultime du thread d'E/S est d'écrire ces événements dans le journal du relais.

Étape 3 : SQL Thread lira le journal de relais et exécutera les événements SQL dans le journal de manière séquentielle pour être cohérent avec les données de la base de données principale.

4. Opérations spécifiques de réplication maître-esclave

J'ai installé deux instances msyql dans des chemins différents sur les mêmes fenêtres. Il est recommandé que les versions installées de MySQL entre le maître et l'esclave ici soient cohérentes, bien que la mienne soit incohérente.

1. Modifier le fichier de configuration my.ini des bases de données maître et esclave respectivement

maître

3306 est le numéro de port par défaut de MySQL, qui n'a pas besoin d'être modifié dans l'instance principale ; l'ID du serveur est utilisé pour spécifier un identifiant unique, et différentes instances de MySQL ne le font pas. doit être répété ; binlog-do-db spécifie qu'il doit être copié dans la base de données ; log-bin est utilisé pour ouvrir les fichiers journaux binaires.

salve

Étant donné que la base de données maître-esclave s'exécutera plus tard sur le même ordinateur, le port doit être défini sur un autre Idem, voici 3307

replicate-do-db : le nom de la base de données qui doit être synchronisée, cohérent avec la configuration sur le maître.

2. Créez un compte spécifiquement pour la réplication sur le maître : weidai/123456

Ce nouveau compte se trouve dans le tableau mysql.user Créer un requête :

Lorsque j'ai fait la première opération, j'ai terminé la création de ce compte ici, mais lorsque je l'ai effectivement copié, j'ai constaté qu'il n'y avait pas de copie . Avec succès, lors du dépannage de l'erreur, j'ai constaté qu'il n'y avait aucun problème avec le binlong généré par le maître, puis j'ai vérifié l'état de l'esclave :

. Il y a une telle ligne d'erreur à la fin :

L'utilisation du compte Weidai ne peut pas se connecter au maître, donc le binlog du maître ne doit pas être obtenu, provoquant le journal de relais ne pas pouvoir être généré.

J'ai vérifié à plusieurs reprises le compte et le mot de passe et n'ai trouvé aucun problème. Ensuite, j'ai recherché des informations pertinentes et j'ai découvert que c'était parce qu'il manquait une étape lorsque le maître a créé un nouvel utilisateur :

Configurer un nouvel utilisateur ou le modifier Après avoir entré le mot de passe, vous devez utiliser les privilèges de vidage pour actualiser les tables liées aux autorisations système de MySQL, sinon l'accès sera refusé. C'est pourquoi l'erreur précédente s'est produite. Une autre façon consiste à redémarrer le serveur MySQL pour que les nouveaux paramètres prennent effet.

3. Obtenez la position des données dans la base de données principale à ce moment-là. Cependant, il est principalement utilisé pour copier la position de départ des données. , avant d'obtenir cette valeur d'état, la base de données principale La base de données ne peut plus avoir d'opérations de modification de données, il est donc nécessaire de définir d'abord le verrou de lecture pour qu'il soit valide

4. La base de données principale effectue une sauvegarde des données. Il existe de nombreuses méthodes de sauvegarde, je ne les présenterai pas ici. Une fois la sauvegarde terminée, le verrou de lecture peut être libéré, ainsi que la principale. la base de données peut effectuer des opérations d'écriture

5. Démarrez la base de données esclave et restaurez les données qui viennent d'être sauvegardées. À ce moment, les données des bases de données maître et esclave au moment de la sauvegarde. point sont cohérents.

6. Configuration liée au comportement de réplication sur la base de données esclave

7. À ce stade, la configuration est terminée, mais la base de données esclave ne peut pas être synchronisée. encore et doit être démarré. le fil esclave

8 Créez une table et ajoutez des données dans le maître, et observez-la dans l'esclave :

Oui On voit que les opérations que j'effectue chez le maître peuvent se refléter chez l'esclave A cette époque, l'esclave est comme un miroir du maître.

5. Interprétation de l'état de synchronisation maître-esclave

Utilisez la commande sur l'esclave pour afficher :

À cause de la composition, c'est trop moche, j'ai donc réglé le problème comme suit :

Slave_IO_STATE:Waiting for master to send event
Master_host:127.0.0.1
Master_user:weidai
Master_port:3306
connnect_retry:60
Master_log_file:mysql-bin.000005
Read_Master_log_pos:1662
Relay_log_file:AE6Z*****-relay-bin.000002
Relay_log_pos:1415
Slave_IO_Running:yes
Slave_SQL_Running:yes

----------------------- ---------- --------------------------Magnifique ligne de démarcation--------------- --------------- -----------------------

Slave_IO_Running : oui

Slave_SQL_Running : oui

Ces deux threads Comme mentionné précédemment, ce sont deux threads très importants sur l'esclave qui participent au processus de réplication. OUI signifie normal, NON signifie anormal.

Le thread Slave_IO copie principalement le contenu du journal binlong sur le maître dans le journal de relais de l'esclave (Relay_log). Généralement, la probabilité de problèmes est faible. La plupart des problèmes sont causés par des autorisations ou des problèmes de réseau. maître. Tout comme l'erreur mentionnée précédemment.

Le thread Slave_SQL est responsable de l'exécution du SQL dans le journal de relais, et la probabilité d'erreurs est relativement élevée. Si quelqu'un insère manuellement certains enregistrements dans la base de données esclave, un conflit de clé primaire se produira lors de la synchronisation maître-esclave.

Slave_IO_STATE : En attente que le maître envoie l'événement

Cet état indique que la synchronisation du journal du relais est terminée et en attente de nouveaux événements générés par le maître.

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!