Super detailed steps for MySQL master-slave switching

Catalog

edition :

Preface :

Master slave environment :

Switching steps :

summary

edition :

MySQL-5.7.32+GTID

Preface :

This article tells MySQL Master slave switching process , The switching steps are mainly aimed at two scenarios: the normal switching between the active and standby databases and the standby database switching when the primary database is down , Master the correct switching process , It can effectively avoid data inconsistency problems that may occur during the switching process and improve the overall switching time

Master slave environment :

Scene one : Active / standby normal switching , This scenario is mainly aimed at the active / standby switchover when the active / standby synchronous replication is normal , for example ： Disaster recovery drill , Planned active / standby switchover .

Switching steps :

 1 Cut off the application traffic to the main database

 2 The primary and standby databases are set as read-only

set global read_only=ON;set global super_read_only=ON;

3 View the status of the standby database replication process

show slave status\G

confirm Slave_IO_Running,Slave_SQL_Running Status as YES,Seconds_Behind_Master by 0

4 Compare the two sides of the active and standby GTID Is it consistent

Get the data on both sides of the active and standby executed_gtid aggregate , compare

select @@global.gtid_executed;

adopt GTID_SUBSET Function

SELECT GTID_SUBSET(master_gtid_executed, slave_gtid_executed);

If in master_gtid_executed Medium GTID, Also exist slave_gtid_executed in , Then return to true(1), Otherwise return to false(0)

  Back to one , On behalf of the main library GTID The execution has been completed from the library , The two sides are identical

5 Stop the replication process from the library and clear the master-slave information

stop slave;reset slave all;

6 Turn off read-only from the library and turn on read-write , Turn to the new main database

set global read_only=off;set global super_read_only=off;

7 The master database setting implements the replication link of the new master database , Transfer to new standby database , Complete the master-slave switch

CHANGE MASTER TO MASTER_HOST='192.168.1.111',MASTER_USER='xxx',MASTER_PORT=3306,MASTER_PASSWORD='xxx',master_auto_position=1 ;start slave;show slave status\G

8 The application traffic is tangential to the new main database

Scene two : When the primary database goes down, the standby database switches to the primary database , This situation is mainly in asynchronous mode or non strong uniform semi synchronous mode , Abnormal downtime of the main library , There may be cases where the data is not fully synchronized to the slave database , Additional data needs to be verified .

1 For main library downtime , When the database is damaged and cannot be started normally , If binlog Can get , You can be right binlog Do offline analysis , Get the data of the difference

Get the data that has been executed in the standby database gtid set

select @@global.gtid_executed

If you have written data to a new master database , Can't read directly binlog Resume , Because data inconsistency may occur , Primary key conflicts , It can be downloaded from binlog It excludes those that have been executed from the library gtid And it is parsed offline into sql sentence , Leave it to the application to analyze whether to add data

mysqlbinlog -vv --base64-output=decode-rows --exclude-gtids='1b80feab-4aa6-11ec-9a60-000c29a6e7be:1-10,2b3039c9-57fa-11eb-b504-000c29ed797a:1-8256287,3a59d149-d4b8-11eb-8cf6-000c29a6e7b4:1-10,a0a3d4b2-fff8-11eb-a420-000c29a6e7be:1-10011' /opt/mysql/log/nlog.000150 > /tmp/binlog_150_gtid.sql;

If the application from the library has not yet written , No new data is generated , You can from binlog It excludes those that have been executed from the library gtid Directly import additional data

mysqlbinlog --exclude-gtids='1b80feab-4aa6-11ec-9a60-000c29a6e7be:1-10,2b3039c9-57fa-11eb-b504-000c29ed797a:1-8256287,3a59d149-d4b8-11eb-8cf6-000c29a6e7b4:1-10,a0a3d4b2-fff8-11eb-a420-000c29a6e7be:1-10011' /opt/mysql/log/nlog.000150 | mysql -uroot -p -S /opt/mysql/3306/data/mysql.sock -P3306

2 For main library downtime , But the old master database can be restarted and pulled up , After startup , If the new master database application has not written new data , The new master library can be change master Replication continues to point to the old master library , Read unapplied log recovery ;

New master library that has written data , Can't read directly binlog Resume , Because data inconsistency may occur , Primary key conflicts , Instead, the data should be parsed into sql sentence , Let the application analyze whether to add data .

use my2sql Online resolution binlog Log access sql sentence , You need to get the starting log number and the reading location , Read sites can be based on --exclude-gtids exclude gtid Post analysis binlog The start position of is read

my2sql -user xxxx -password xxxx -work-type 2sql -start-file /opt/mysql/log/nlog.000150 -start-pos=7940194 --add-extraInfo -output-dir /tmp/my2sql_recover

The catalogue will produce forward+ The text of the log number , It stores the parsed sql

summary

This is about MySQL This is the end of the master-slave switch article , More about MySQL Please search the previous articles of the software development network or continue to browse the following related articles. I hope you will support the software development network in the future ！