本文主要是介绍又成长了，异常掉电踩到了MySQL主从同步的坑！，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
📢📢📢📣📣📣
哈喽！大家好，我是【IT邦德】，江湖人称jeames007，10余年DBA及大数据工作经验
一位上进心十足的【大数据领域博主】！😜😜😜
中国DBA联盟(ACDU)成员，目前服务于工业互联网
擅长主流Oracle、MySQL、PG、高斯及Greenplum运维开发，备份恢复，安装迁移，性能优化、故障应急处理等。
✨ 如果有对【数据库】感兴趣的【小可爱】，欢迎关注【IT邦德】💞💞💞
❤️❤️❤️感谢各位大可爱小可爱！❤️❤️❤️
文章目录
- 前言
- 📣 1.主从复制简介
- 📣 2.主从复制原理
- 📣 3.机房掉电主从故障
- ✨ 3.1 故障现象
- ✨ 3.2 故障处理
- 📣 4.知识点
- 📣 5.故障总结
本文总结了主从复制的原理及日常运维的坑
前言
本文总结了主从复制的原理及日常运维的坑
📣 1.主从复制简介
MySQL 复制是指从一个 MySQL 主服务器(master)将数据拷贝到另一台或多台 MySQL 从服务器(slaves)的过程，将主数据库的 DDL 和 DML 操作通过二进制日志传到从库服务器上，然后在从服务器上对这些日志重新执行，从而使得主从服务器的数据保持同步。
📣 2.主从复制原理
MySQL复制的基本过程如下：
- Slave上面的 IO 线程连接上 Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；
- Master接收到来自 Slave 的 IO 线程的请求后，通过复制的 IO 线程根据请求信息读取指定日志指定位置之后的日志信息，返回给 Slave端的 IO 线程。
- Slave的 IO 线程接收到信息后，
将接收到的日志内容依次写入到 Slave端的 Relay Log 文件(mysql-relay-bin.xxxxxx)的最末端，并将读取到的 Master 端的 binlog 的文件名和位置记录到 master-info 文件中.
- 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.000002Position: 195Binlog_Do_DB: Binlog_Ignore_DB:
Executed_Gtid_Set: c5833cbf-fa39-11ee-ae67-0242c0a8441f:1-5
1 row in set (0.00 sec)--从库执行的GTIDLast_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:6Auto_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
这篇关于又成长了，异常掉电踩到了MySQL主从同步的坑！的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
