mysql GTID主从复制故障后不停机恢复同步流程

概述GTID实现主从复制数据同步 GTID是一个基于原始mysql服务器生成的一个已经被成功执行的全局事务ID，它由服务器ID以及事务ID组成，这个全局事务ID不仅仅在原始服务器上唯一，在所有主从关系的m

GTID实现主从复制数据同步

GTID是一个基于原始MysqL服务器生成的一个已经被成功执行的全局事务ID，它由服务器ID以及事务ID组成，这个全局事务ID不仅仅在原始服务器上唯一，在所有主从关系的MysqL服务器上也是唯一的。正式因为这样一个特性使得MysqL主从复制变得更加简单，以及数据库一致性更可靠。

 

介绍

GTID的概念

 全局事务标识：global transaction IDentifIErs GTID是一个事务一一对应，并且全局唯一ID 一个GTID在一个服务器上只执行一次，避免重复执行导致数据混乱不一致 不再使用传统的MASTER_LOG_file+MASTER_LOG_POS开启复制，而是采用MASTER_auto_POSTION=1的方式开启复制。 从mysql-5.6.5及后续版本开始支持

 

GTID的组成

GTID = server_uuID:transaction_ID

server_uuID：MysqL服务器的唯一标识，查看方法MysqL客户端内：show variables like '%server_uuID%';

transaction_ID：此ID是当前服务器中提交事务的一个序列号，从1开始自增长，一个数值对应一个事务

GTID号示例：c9fba9e2-db3b-11eb-81d4-000c298d8da1:1-5

 

GTID的优势

 实现主从更简单，不用像以前一样寻找log_file和log_pos 比传统的主从更加安全 GTID是连续没有空洞的，保证数据一致性，零丢失。

 

GTID工作原理

master更新数据时，会在事务前产生GTID，一同记录到binlog日志中slave端的I/O线程将变更的binlog，写入到本地的relay log中sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录（所以MysqL5.6 slave端必须开启binlog）如果有记录，说明该GTID的事务已经执行，slave会忽略如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描

 

开始配置GTID复制

主：192.168.152.253   Centos7

从：192.168.152.252   Centos8

测试数据库：vfan

测试表：student

 

@H_502_179@1、修改MysqL服务配置文件，添加以下参数，随后重启：

server-ID=100    #server IDlog-bin=/var/lib/MysqL/MysqL-bin  #开启binlog并指定存储位置expire_logs_days=10  #日志保存时间为10天gtID_mode=on  #gtID模块开关enforce_gtID_consistency=on  #启动GTID强一致性，开启gtID模块必须开启此功能。binlog_format=row  #bin_log日志格式，共有三种STATEMENT、ROW、MIXED；默认为STATEMENTskip_slave_start=1  #防止复制随着MysqL启动而自动启动

主服务器和从服务器的配置一致即可，server-ID更改一下

 

@H_502_179@2、在主服务器中创建从服务器连接的用户

CREATE USER 'copy'@192.168.152.252' IDENTIFIED BY ';GRANT REPliCATION SLAVE ON *.* TO ;flush privileges;

创建完毕记得要测试下slave机是否能登录成功

 

@H_502_179@3、使用MysqLdump使两数据库数据同步

主MysqL执行：MysqLdump -uroot -proot1 vfan > dump2.sqlscp dump2.sql 192.168.152.252:/data/从MysqL执行：MysqL> source /data/dump2.sql

 

当前主、从服务器数据内容一致，都是以下数据：

MysqL> select * from student;+----+------+-----+| ID | name | age |+----+------+-----+|  1 | Tony |  18 ||  2 | Any  |  17 ||  3 | Goy  |  20 ||  4 | Baly |  5 | Heg  |  19 ||  6 | hhh  | 100 ||  7 | lll  |  99 |+----+------+-----+7 rows in set (0.01 sec)

 

@H_502_179@4、开启主从复制

MysqL> CHANGE MASTER TO MASTER_HOST=192.168.152.253',MASTER_USER=3306,MASTER_auto_position=1;query OK,0 rows affected,2 warnings (0.04 sec)MysqL> start slave;query OK,1)">0 rows affected (0.01 sec)## 查看slave状态MysqL> show slave status\G*************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                  Master_Host: 152.253                  Master_User: copy                  Master_Port: 3306                Connect_Retry: 60              Master_Log_file: MysqL-bin.000014          Read_Master_Log_Pos: 897               Relay_Log_file: kubenode2-relay-bin.000002                Relay_Log_Pos: 416        Relay_Master_Log_file: MysqL-bin.             Slave_IO_Running: Yes            Slave_sql_Running: Yes

 

@H_502_179@5、检查是否同步

主服务器中插入数据：MysqL> INSERT INTO student(name,age) VALUES(gogoo50),(zhazha25);query OK,1)">2 rows affected (0.03 sec)Records: 2  Duplicates: 0  Warnings: 0从服务器中读取：MysqL>  from student;+----+--------+-----+| ID | name   | age |+----+--------+-----+|  1 | Tony   |  2 | Any    |  3 | Goy    |  4 | Baly   |  5 | Heg    |  6 | hhh    | 7 | lll    |  99 ||  8 | gogoo  |  50 ||  9 | zhazha |  25 |+----+--------+-----+9 rows 0.00 sec)

数据已经同步，基础的主从复制已经搭建完成

 

现在模拟一个主从复制架构中，从服务器中途复制失败，不再同步主服务器的场景，并要求不停业务进行数据同步修复，恢复一致。

@H_502_179@1、首先先模拟一个数据插入的场景

vim insert.sh

#!/usr/bin/env bashvalues=(`find /usr/ -type d | awk -F /' {print $NF}' | sort -u`)while truedoage=$(( $RANDOM%100 ))name=${values[$(( $RANDOM%6 ))]}MysqL -h127.1 -P3306 -uroot -proot1 -e "INSERT INTO vfan.student(name,age) VALUES('"${name}',${age});" &> /dev/null sleep $(( $RANDOM%5 ))done

运行脚本，数据在随机插入（插入时间间隔 < 5s）

目前主MysqL数据：

MysqL>  from student;+----+---------------------+-----+| ID | name                | age |......|  97 | _                   |   2 ||  98 | 00bash              |  15 ||  99 | 00bash              |  52 || 100 | 00bash              |  43 || 101 | _                   |  65 || 102 | 00                  |  67 |+-----+---------------------+-----+102 rows 0.01 sec)

 

@H_502_179@2、数据还在陆续插入，此时模拟slave节点宕机或异常(在此就直接stop slave;)

MysqL> stop slave;query OK,1)">0.01 sec)

 

@H_502_179@3、此时主库数据还在增加，而从库已经不同步，以下是从库数据：

MysqL> ......| 82 | 00bash              |  50 || 83 | 00systemd-bootchart |  36 || 84 | 00bash              |  48 || 85 | 00systemd-bootchart |  41 || 86 | 72 |+----+---------------------+-----+86 rows 0.00 sec)

 

@H_502_179@4、开始从库恢复数据

思路：

 先通过MysqLdump全量备份当前的数据，由于不能影响业务，所以在MysqLdump数据时不能造成锁表。要保持数据写入

 由于MysqLdump时数据还在写入，所以有一部分数据还是会同步不全，所以导入MysqLdump的数据后，跳过dump中包含的GTID事务，再重新建立一次主从配置，开启slave线程，恢复数据并同步。

 

（1）MysqLdump不锁表备份数据

MysqLdump -uroot -proot1 --single-transaction --master-data=2 -R vfan | gzip > dump4.sql

主要起作用参数：--single-transaction

 

（2）查看当前MysqLdump导出数据的GTID号

[root@TestCentos7 data]# grep GLOBAL.GTID_PURGED dump4.sql SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ c9fba9e2-db3b-11eb-81d4-000c298d8da1:1-228';

以上的 c9fba9e2-db3b-11eb-81d4-000c298d8da1:1-228 表示MASTER机执行到的GTID事务号

 

（3）去从数据库导入

scp dump4.sql 152.252:/dataMysqL客户端内：MysqL> source /data/dump4.sql此时从库数据：MysqL>  from student;| 230 | 53 || 231 | 00bash              |  66 || 232 | _                   |  18 || 233 | 0.33.0              |  98 || 234 | 00bash              |  14 |+-----+---------------------+-----+234 rows 0.00 sec)主库数据：| 454 | _                   |  46 || 455 | 03modsign           |  59 || 456 | 00systemd-bootchart |  77 || 457 | 03modsign           |   6 || 458 | 88 |+-----+---------------------+-----+458 rows 0.00 sec)

从库数据恢复一部分到234行，主库数据依然在增加，已经是458条

 

（4）由于我们MysqLdump的数据已经包含了在MASTER执行的 1-228 个事务，所以我们在SLAVE进行同步的时候，要忽略这些事务不再进行同步，不然会出现类似于这种报错：

MysqL>137827417             Slave_IO_Running: Yes            Slave_sql_Running: No                   Last_Errno: 1062                   Last_Error: Could not execute Write_rows event on table vfan.student; Duplicate entry 87' for key student.PRIMARY1062; handler error HA_ERR_FOUND_DUPP_KEY; the events master log MysqL-bin.000002,end_log_pos 10588

 

要想跳过某些GTID，SLAVE必须保证 gtID_purged 参数为空才能正确跳过，查看当前的gtID_purged：

MysqL> show global variables like %gtID%;+----------------------------------+-------------------------------------------------------------------------------------+| Variable_name                    | Value                                                                               |+----------------------------------+-------------------------------------------------------------------------------------+| binlog_gtID_simple_recovery      | ON                                                                                  || enforce_gtID_consistency         | ON                                                                                  || gtID_executed                    | b30cb2ff-32d4-11eb-a447-000c292826bc:1-2,c9fba9e2-db3b-11eb-81d4-000c298d8da1:80 || gtID_executed_compression_period | 1000                                                                                || gtID_mode                        | ON                                                                                  || gtID_owned                       |                                                                                     || gtID_purged                      | c9fba9e2-db3b-11eb-81d4-000c298d8da1:70                                           || session_track_gtIDs              | OFF                                                                                 |+----------------------------------+-------------------------------------------------------------------------------------+8 rows 0.02 sec)

 

当前gtID_purged不为空，所以我们要先设置它为空，执行：

MysqL> reset master;query OK,1)">0.05 sec)MysqL> show global variables like ;+----------------------------------+-------+| Variable_name                    | Value |+----------------------------------+-------+| binlog_gtID_simple_recovery      | ON    || enforce_gtID_consistency         | ON    || gtID_executed                    |       || gtID_executed_compression_period | 1000  || gtID_mode                        | ON    || gtID_owned                       |       || gtID_purged                      |       || session_track_gtIDs              | OFF   |+----------------------------------+-------+0.00 sec)

 

（5）gtID_purged为空后，开始重置SLAVE

MysqL> reset slave all;query OK,1)">0.02 sec)

 

（6）重置后，设置跳过的GTID，并重新同步MASTER

MysqL> SET @@GLOBAL.GTID_PURGED= sec)MysqL> CHANGE MASTER TO MASTER_HOST=0.04 sec)

 

（7）开启SLAVE进程，查看同步状态

MysqL>84993             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:                    Last_Error:                  Skip_Counter:           Exec_Master_Log_Pos:               Relay_Log_Space: 85206              Until_Condition: None               Until_Log_file:                 Until_Log_Pos:            Master_SSL_Allowed: No           Master_SSL_CA_file:            Master_SSL_CA_Path:               Master_SSL_Cert:             Master_SSL_Cipher:                Master_SSL_Key:         Seconds_Behind_Master: Master_SSL_Verify_Server_Cert: No                Last_IO_Errno:                 Last_IO_Error:                Last_sql_Errno:                Last_sql_Error:   Replicate_Ignore_Server_IDs:              Master_Server_ID:                   Master_UUID: c9fba9e2-db3b-11eb-81d4-000c298d8da1             Master_Info_file: MysqL.slave_master_info                    sql_Delay:           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: c9fba9e2-db3b-11eb-81d4-000c298d8da1:229-519            Executed_GtID_Set: c9fba9e2-db3b-11eb-81d4-000c298d8da1:                auto_position:          Replicate_Rewrite_DB:                  Channel_name:            Master_TLS_Version:        Master_public_key_path:         Get_master_public_key:             Network_namespace: 1 row 0.00 sec)

可以看到，同步正常！

 

（8）最后，查看master与slave数据是否一致

MASTER数据：SELECT * FROM student;| 520 | 00systemd-bootchart |  521 | 00systemd-bootchart |  44 || 522 | 03modsign           |  523 | 00systemd-bootchart |  45 || 524 | 90 || 525 | 03modsign           |  21 |+-----+---------------------+-----+525 rows  sec)SLAVE数据：SELECT * FROM student;| 519 | 99 || 0.00 sec)

在我们修过程中插入的数据也已经全部同步。数据完全一致，主从复制修复完成。

总结

以上是内存溢出为你收集整理的mysql GTID主从复制故障后不停机恢复同步流程全部内容，希望文章能够帮你解决mysql GTID主从复制故障后不停机恢复同步流程所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。