又成长了，异常掉电踩到了MySQL主从同步的坑！

📢📢📢📣📣📣
哈喽！大家好，我是【IT邦德】，江湖人称jeames007，10余年DBA及大数据工作经验
一位上进心十足的【大数据领域博主】！😜😜😜
中国DBA联盟(ACDU)成员，目前服务于工业互联网
擅长主流Oracle、MySQL、PG、高斯及Greenplum运维开发，备份恢复，安装迁移，性能优化、故障应急处理等。
✨ 如果有对【数据库】感兴趣的【小可爱】，欢迎关注【IT邦德】💞💞💞
❤️❤️❤️感谢各位大可爱小可爱！❤️❤️❤️

前言

本文总结了主从复制的原理及日常运维的坑

📣 1.主从复制简介

MySQL 复制是指从一个 MySQL 主服务器(master)将数据拷贝到另一台或多台 MySQL 从服务器(slaves)的过程，将主数据库的 DDL 和 DML 操作通过二进制日志传到从库服务器上，然后在从服务器上对这些日志重新执行，从而使得主从服务器的数据保持同步。

📣 2.主从复制原理

MySQL复制的基本过程如下：

1. Slave上面的 IO 线程连接上 Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；

2. Master接收到来自 Slave 的 IO 线程的请求后，通过复制的 IO 线程根据请求信息读取指定日志指定位置之后的日志信息，返回给 Slave端的 IO 线程。

3. Slave的 IO 线程接收到信息后，
   将接收到的日志内容依次写入到 Slave端的 Relay Log 文件(mysql-relay-bin.xxxxxx)的最末端，并将读取到的 Master 端的 binlog 的文件名和位置记录到 master-info 文件中.

4. Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后，会马上解析该 Log 文件中的内容成为在 Master 端真实执行时候的那些可执行的SQL 语句，并在自身执行这些 SQL。

📣 3.机房掉电主从故障

✨ 3.1 故障现象

机房掉电，数据库非正常关机。
MySQL拉起后，从库报如下错误。
Slave_IO_Running: No
Slave_SQL_Running: Yes

发现从库的GTID比主库的GTID要大

--主库的GTID
mysql> show master status\G
*************************** 1. row ***************************
             File: MMK-JEM-Master1-ip31-bin.000002
         Position: 195
     Binlog_Do_DB: 
 Binlog_Ignore_DB: 
Executed_Gtid_Set: c5833cbf-fa39-11ee-ae67-0242c0a8441f:1-5
1 row in set (0.00 sec)

--从库执行的GTID
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 46081bff-fa3a-11ee-9d8b-0242c0a84420:1-7,
c5833cbf-fa39-11ee-ae67-0242c0a8441f:1-2:6
                Auto_Position: 1

✨ 3.2 故障处理

1）在从上执行 reset master;
在从库上执行这个命令的作用是清空从库的 gtid
2）然后从库重置即可
mysql> stop slave;
mysql> reset slave;
mysql> start slave;
mysql> show slave status\G
3)查询从库被执行过的gtid
mysql> select @@GLOBAL.gtid_executed;
±-----------------------------------------+
| @@GLOBAL.gtid_executed |
±-----------------------------------------+
| c5833cbf-fa39-11ee-ae67-0242c0a8441f:1-2 |
±-----------------------------------------+

此时我们发现有报错信息

–解决方案，跳过从库gtid
mysql> stop slave;
mysql> set gtid_next=‘c5833cbf-fa39-11ee-ae67-0242c0a8441f:3’;
mysql> begin;commit;
mysql> set gtid_next=‘automatic’;

mysql> start slave;
mysql> SHOW SLAVE STATUS\G

–此时发现同步一切OK
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

📣 4.知识点

在MySQL中，sync_binlog参数用于控制二进制日志(binlog)的同步方式。
它决定了事务提交到binlog的时机以及是否需要等待数据同步完成才返回客户端

根据实际需求，设置sync_binlog参数的值。
0: 表示不进行同步，即异步写入binlog。
1: 表示在事务提交后立即将binlog同步到磁盘。
n: 表示在事务提交后等待n次fsync操作后将binlog同步到磁盘。

📣 5.故障总结

从二进制日志读取数据时，从主机收到致命错误1236：“使用主机的SERVER_UUID，从机的GTID比主机多。这可能表示二进制日志的末尾被截断，或者最后一个二进制日志文件丢失，例如，在sync_binlog！=1.主服务器可能已回滚或可能未回滚已复制到从属服务器的事务。建议将master已从slave回滚到master的任何事务复制到master