Maison > Article > base de données > Deux serveurs MySQL réalisent une configuration de sauvegarde mutuelle sur deux machines et testent la synchronisation des données
Cet article donne une introduction détaillée à la configuration de la sauvegarde mutuelle de deux machines. Une fois les données de test synchronisées, modifiez une donnée dans la base de données du serveur 10.168.1.44, et vous pouvez voir que le les données ont été synchronisées. À l'inverse, si vous modifiez les données de 10.168.0.126, vous pouvez également voir les modifications des données de table correspondantes dans la base de données 10.168.1.44. À ce stade, 10.168.0.126 et 10.168.1.44 ont une relation de base de données maître-esclave l'un avec l'autre.
Tutoriels vidéo mysql associés recommandés : "tutoriel mysql"
apache php mysql
Préparation préliminaire
Deux serveurs : 10.168.1.44
10.168.0.126
Environnement d'exploitation : système Linux (Centos6.5)
Version Mysql : 5.7.22
Modifier la configuration
Modifier /etc/my sur les deux serveurs Les informations du Le fichier de configuration .conf est le suivant :
Ajouter le fichier de configuration 10.168.1.44 server/etc/my.conf :
server_id=10
log-bin=master_01 //Activer le journal binaire, afin qu'un autre serveur puisse utiliser le journal pour déterminer l'opération d'exécution
binlog-do-db=test_db //Table synchronisée
binlog-do-db=my_test //La table synchronisée
est ajoutée dans le fichier de configuration 10.168.0.126 server/etc/my.conf :
server_id=20
log-bin=master_02 // Ouvrir le journal binaire, la fonction est qu'un autre serveur peut utiliser le journal pour déterminer l'opération d'exécution
binlog-do-db=test_db //Table synchronisée
binlog-do-db=my_test / /Synchronisation Après avoir ajouté la table
, exécutez la commande service mysqld restart pour redémarrer la base de données afin de rendre la modification effective
Ajouter un compte mysql
Ajoutez un compte mysql et effectuez la synchronisation des données en donnant à ses utilisateurs autorisés
10.168.1.44 commande d'exécution :
GRANT FILE ON *.* TO 'copyuser'@'10.168.0.126' IDENTIFIED BY 'Admin@123'; GRANT REPLICATION SLAVE ON *.* TO 'copyuser'@'10.168.0.126' IDENTIFIED BY 'Admin@123'; flush privileges;
10.168.0.126 commande d'exécution :
GRANT FILE ON *.* TO 'copyuser'@'10.168.1.44' IDENTIFIED BY 'Admin@123'; GRANT REPLICATION SLAVE ON *.* TO 'copyuser'@'10.168.1.44' IDENTIFIED BY 'Admin@123'; flush privileges;
Configurer la base de données esclave
Configuration 10.168.1.44 :
Afficher la état actuel de la base de données principale :
mysql> afficher l'état principal ;
Enregistrez le fichier actuel et les valeurs de position ;
Entrez 10.168.0.126 pour accéder à la base de données et afficher sa base de données principale status
Exécuter à 10.168.1.44
mysql>CHANGE MASTER TO MASTER_HOST='10.168.0.126', MASTER_USER='copyuser', MASTER_PASSWORD='Admin@123', MASTER_PORT=3306, MASTER_LOG_FILE='master_02.000002', MASTER_LOG_POS=1771, MASTER_CONNECT_RETRY=10; 在10.168.0.126执行: mysql>CHANGE MASTER TO MASTER_HOST='10.168.1.44', MASTER_USER='copyuser', MASTER_PASSWORD='Admin@123', MASTER_PORT=3306, MASTER_LOG_FILE='master_01.000008', MASTER_LOG_POS=154, MASTER_CONNECT_RETRY=10; 注:若slave开启状态无法执行以上命令,需要首先执行 stop slave;关闭slave,执行完上述命令后执行start slave;命令开启slave。 上述命令执行完后,查看从服务状态: 执行命令: mysql> show slave status\G; *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 10.168.1.44 Master_User: copyuser Master_Port: 3306 Connect_Retry: 10 Master_Log_File: master_01.000008 Read_Master_Log_Pos: 154 Relay_Log_File: cdh-2-relay-bin.000004 Relay_Log_Pos: 367 Relay_Master_Log_File: master_01.000008 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 154 Relay_Log_Space: 740 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 10 Master_UUID: 778beb1e-8f0f-11e8-a815-00505695cd8c Master_Info_File: /var/lib/mysql/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: Executed_Gtid_Set: Auto_Position: 0 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: 1 row in set (0.00 sec)
RemarqueSlave_IO_Running : Oui et Slave_SQL_Running : Oui, la configuration n'est réussie que lorsque les deux sont oui.
Tester la synchronisation des données
Modifier une donnée dans la base de données du serveur 10.168.1.44 :
Avant modification :
Après modification :
Afficher les données dans le tableau correspondant dans le 10.168.0.126 base de données :
Vous pouvez voir qu'elle a été synchronisée.
À l'inverse, si vous modifiez les données de 10.168.0.126, vous pouvez également voir les changements dans les données de la table correspondante dans la base de données 10.168.1.44.
À ce stade, la relation mutuelle de base de données maître-esclave entre 10.168.0.126 et 10.168.1.44
Il peut y avoir des problèmes
Lorsque vous vérifiez l'état de l'esclave, vous constaterez que Slave_IO_Running : Connexion
Il y a trois raisons principales à ce problème :
Le réseau n'est pas disponible (essayez de vous envoyer un ping pour voir si le ping peut fonctionner)
Mot de passe incorrect : Vérifiez si le mot de passe dans la commande exécutée lors de la configuration de l'esclave est correct (correspondant à l'état maître de la base de données du serveur esclave : l'état du maître peut être trouvé)
La raison pour laquelle j'ai ce problème est que l'utilisateur 'copyuser' utilisé pour synchroniser les données n'est créé que sur un serveur, et l'utilisateur n'est pas créé dans la base de données de l'autre serveur. . C'est OK après la création .
4. Lors de la vérification du statut de l'esclave, vous constaterez que Slave_SQL_Running : Non
La principale raison de ce phénomène est qu'il existe des différences dans les données entre les deux bases de données. Vous pouvez passer Vérifiez le journal MySQL pour localiser la donnée spécifique qui est anormale
Le journal MySQL se trouve généralement dans /var/log/mysqld.log
Il devrait l'être. Notez que si vous configurez uniquement la base de données esclave pour synchroniser les données de la base de données principale et que vous n'êtes pas configuré pour se synchroniser les unes avec les autres, la modification des données de la base de données esclave peut entraîner un échec de synchronisation.
Articles connexes :
Configuration de sauvegarde à chaud de la base de données MySQL sur deux machines_MySQL
Synchronisation en temps réel MySQL-sauvegarde mutuelle sur deux machines ( Double maître)
Vidéos associées :
Tutoriel vidéo d'analyse de cas de sauvegarde et de récupération de gestion des données 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!