Explication détaillée de l'exemple de partage de code pour la réplication maître-esclave de mysql5.6 sous centos7

Cet article présente principalement l'explication détaillée de la réplication maître-esclave de mysql5.6 sous centos7. L'éditeur pense que c'est plutôt bon, je vais donc le partager avec vous maintenant et le donner comme référence. Suivons l'éditeur et jetons un coup d'œil.

1. Introduction à la réplication maître-esclave MySQL

La réplication maître-esclave de MySQL n'est pas activée. le disque de la base de données Le fichier est copié directement, mais copié sur le serveur local pour être synchronisé via le journal logique binlog, puis le thread local lit l'instruction SQL dans le journal et la réapplique à la base de données mysql .

La base de données MySQL prend en charge la réplication dans différents scénarios commerciaux tels que la réplication unidirectionnelle, bidirectionnelle, en cascade en chaîne et en anneau. Un serveur agit en tant que serveur principal principal et reçoit les mises à jour des utilisateurs, tandis qu'un ou plusieurs autres serveurs. agir comme Le serveur esclave reçoit le contenu du journal du fichier binlog du serveur maître, analyse le SQL et le met à jour sur le serveur esclave.

Un maître et un esclave (A -> B, A est le maître, B est l'esclave)

Un maître et plusieurs esclaves (A -> B, A -> C, A est le maître esclave, B et C sont des esclaves)

Synchronisation bidirectionnelle double maître (A -> B, B -> A, A et B sont tous deux maîtres et se sauvegardent mutuellement)

Cascade linéaire (A -> B -> C, A et B sont maîtres et esclaves, et C est esclave)

Cascade d'anneaux (A -> B -> C -> ; A, A, B et C sont tous deux maîtres, et chaque nœud peut écrire des données)

2 La solution pour réaliser la séparation de la lecture et de l'écriture du maître-esclave MySQL .

1. Réaliser la séparation en lecture et en écriture grâce à des programmes ( Déclaration de jugement mot-clé pour connecter la base de données maître-esclave)

2. Réaliser la séparation en lecture et en écriture grâce à l'ouverture logiciel source (mysql-proxy, amiba, stable Les performances et les fonctions sont moyennes, non recommandées pour une utilisation en production)

3 Développement indépendant du logiciel de couche DAL

3. .Introduction au principe de la réplication maître-esclave MySQL

La réplication maître-esclave MySQL est un processus de réplication asynchrone, qui copie une bibliothèque maître vers une bibliothèque esclave L'ensemble du processus. entre maître et esclave est complété par trois threads. Le thread SQL et le thread d'E/S sont du côté esclave, et l'autre thread d'E/S est du côté maître.

Principe et processus de réplication

1. Exécutez la commande start slave sur l'esclave, activez le commutateur de réplication maître-esclave et démarrez la réplication maître-esclave.

2. Le thread d'E/S de l'esclave demande au maître via l'utilisateur de réplication autorisé sur le maître, demandant l'emplacement spécifié du journal binlog spécifié.

3. Une fois que le maître a reçu la demande du thread d'E/S de l'esclave, son propre thread d'E/S responsable de la copie lira les informations du journal après la position spécifiée du journal binlog spécifié par lots en fonction du Les informations de requête de l'esclave. Elles sont ensuite renvoyées au thread d'E/S de l'esclave. En plus du journal binlog, les informations renvoyées incluent également le nouveau nom du fichier binlog du maître et la prochaine position de mise à jour spécifiée dans le nouveau binlog.

4. L'esclave obtient le contenu du journal binlog envoyé depuis le thread d'E/S sur le maître. Après le fichier journal et le point d'emplacement, le contenu du journal binlog sera écrit à la fin du propre journal de relais de l'esclave. (journal de relais) à son tour. Et enregistrez le nouveau nom et l'emplacement du fichier binlog dans le fichier master-info, de sorte que la prochaine fois que le nouveau journal binlog sera lu à partir du maître, le maître puisse être invité à lire à partir du nouvel emplacement. du nouveau binlog.

5. Le thread SQL de l'esclave détectera le contenu du journal nouvellement ajouté du thread d'E/S dans le journal de relais local en temps réel, analysera le contenu du fichier journal de relais en instructions SQL en temps opportun, et analysez les instructions SQL dans l'ordre de leurs positions. Relay-log.info enregistre le nom de fichier et l'emplacement du journal de relais d'application actuel.

4. Opération de réplication maître-esclave MySQL

J'ai plusieurs instances de MySQL sur une seule machine ici, 3306, 3308. , 3309

La base de données maître est 3306 et la base de données esclave est 3308,3309

(1), sur la base de données maître

1. Définissez la valeur de l'ID du serveur et ouvrez la fonction binlog

> vi /etc/my.cnf

 [mysqld]
 #用于同步的每台机器server-id都不能相同

server-id = 10

log-bin = /data/mysql56/data/mysql-bin

2 Redémarrez la base de données principale

> service mysqld restart

3. Connectez-vous à la base de données principale et vérifiez le serveur. -id

> mysql -uroot -p

> show variables like 'server_id';

4. Main Créer un compte sur la bibliothèque pour copier depuis la bibliothèque

> grant replication slave on *.* to "rep"@"%" identified by "123456";

> flush privileges;

> select user,host from mysql.user;

> show grants for rep@"%";

5. Table de verrouillage en lecture seule de la base de données de la bibliothèque principale (ne pas fermer). la fenêtre actuelle)

> flush table with read lock;

Afficher la bibliothèque principaleStatut

> show master status;

6. Sauvegardez tous les fichiers de données dans la base de données principale

> mysqldump -uroot -p -A -B | gzip > /data/mysql_bak.$(date +%F).sql.gz

7. Après avoir sauvegardé les données de la base de données principale, déverrouillez

> unlock tables;

8. Migrez les données exportées de la bibliothèque principale vers la bibliothèque esclave

(2), sur l'esclave. bibliothèque

1. Définissez la valeur de l'ID du serveur et désactivez la fonction binlog

①Il existe deux situations dans lesquelles binlog doit être ouvert

②B au milieu de synchronisation en cascade A->B->C doit ouvrir le binlog

③Faites-le à partir de la bibliothèque esclave. La sauvegarde de la base de données nécessite une sauvegarde complète et le journal binlog pour être une sauvegarde complète.

> vi /mysql-instance/3308/my.cnf 

[mysqld]

server-id = 11

relay-log = /mysql-instance/3308/relay-bin

relay-log-info-file = /mysql-instance/3308/relay-log.info

2. Redémarrez la base de données esclave

> /mysql-instance/3308/mysql restart

3. Connectez-vous à la base de données esclave pour vérifier les paramètres

> mysql -uroot -p -S /mysql-instance/3308/mysql.sock

> show variables like 'log_bin';

> show variables like 'server_id';

4. par mysqldump depuis la base de données principale vers Depuis la base de données

> gzip -d /data/mysql_bak.2017-01-15.sql.gz

Restaurez les données de la base de données maître vers la base de données esclave

> mysql -uroot -p -S /mysql-instance/3308/mysql.sock < /data/mysql_bak.2017-01-15.sql

5. Connectez-vous à la base de données esclave et configurez les paramètres de réplication

CHANGE MASTER TO

MASTER_HOST='127.0.0.1',

MASTER_PORT=3306,

MASTER_USER='rep',

MASTER_PASSWORD='123456',

MASTER_LOG_FILE='mysql-bin.000001',

MASTER_LOG_POS=396;

Faites attention au MASTER_LOG_FILE ci-dessus et MASTER_LOG_POS sont les informations affichées dans la bibliothèque principale en utilisant show master status ;.

Affichez le fichier master.info

> cat /mysql-instance/3308/data/master.info

6. Démarrez le commutateur de synchronisation de la base de données esclave et testez la réplication maître-esclave

> mysql -uroot -p -S /mysql-instance/3308/mysql.sock -e "start slave;"

> mysql -uroot -p -S /mysql-instance/3308/mysql.sock -e "show slave status\G;"

> mysql -uroot -p -S /mysql-instance/3308/mysql.sock -e "show slave status\G" | egrep "IO_Running|SQL_Running|_Behind_Master"

7. -réplication esclave

> mysql -uroot -p -e "create database wohehe;"

> mysql -uroot -p -S /mysql-instance/3308/mysql.sock -e "show databases;"

五、mysql主从复制线程状态说明及用途

1、主库线程的同步状态

> show processlist\G; 


*************************** 1. row ***************************

   Id: 5

  User: rep

  Host: localhost:47605

   db: NULL

Command: Binlog Dump

  Time: 4728

 State: Master has sent all binlog to slave; waiting for binlog to be updated

  Info: NULL

说明主库线程已从binlog读取更新，发送到了从库，线程处理空闲状态，等待binlog的事件更新。

2、从库线程的同频状态

> show processlist\G; 

*************************** 2. row ***************************

   Id: 6

  User: system user

  Host:

   db: NULL

Command: Connect

  Time: 5305

 State: Slave has read all relay log; waiting for the slave I/O thread to update it

  Info: NULL

说明从库已读取所有中继日志，等待从库I/O线程的更新。

六、主从复制故障

如果我在从库上创建了一个库，然后去主库创建同名的库，那么这就会冲突了。

> show slave status; 

Slave_IO_Running: Yes

Slave_SQL_Running: No

Seconds_Behind_Master: NULL

Last_Error: Error 'Can't create database 'xxxxx'; database exists' on query. Default database: 'xxxxx'. Query: 'create database xxxxx'

对于该冲突解决方法

方法一

> stop slave;

#将同步指针移动下一个，如果多次不同步，可重复操作

> set global sql_slave_skip_counter = 1;

> start slave;

方法二

> vi /mysql-instance/3308/my.cnf 

#把可以忽略的错误号事先在配置文件中配置

slave-skip-errors = 1002,1007,1032

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!