[MySQL]-主从同步实战
[MySQL]-主从同步实战
森格 | 2022年12月14日
本文主要为在平时work中遇到的主从同步上的问题的处理，对其进行巩固总结。
一、场景介绍
在一个风和日丽的下午4点半，突然就收到一个主从同步失败的提示，三两下打开从库一看，好嘛成这样了：
# 从库上查看同步状态
mysql>show slave statusG;
报错内容如下：
Slave_IO_Running: Yes
Last_IO_Error:Got fatal error 1236 from master when reading data from binary log:'could not find next log;the first event 'mysql-bin.xxx' at xxx,the last event read from from './mysql-bin.xxx' at xxx,the last byte read from './mysql-bin.xx' at xxx'
这一大串报错，给我好一顿看，简单来说就是不能从主库的binlog读取数据了。
赶紧去主库的实例一看，好嘛，哪个给我binlog重置了啊，看着这mysql-bin.000001，内心拔凉。
转念一问周围队友，原配置主库的binlog过期时间为7天，正碰巧开发在灌入数据，主库的磁盘空间不够了。
那也没有办法，那就把主从同步再搭起来呗，准备准备，搞起。
当前的主从同步的主库的配置如下（从库除 server_id 之外均相同）：
# GTID 主从 Config
server_id = 3306 # 主从库的该ID一定要不一样
gtid_mode = on
enforce-gtid-consistency = true
master_info_repository = table
relay-log-info-repository = table
# bin-log Config
binlog-format = row # 选择row格式
expire_logs_days = 3 #开启全局事务ID
binlog_rows_query_log_events = 1 # 记录event的同时，也记录原始SQL语句
binlog_cache_size = 4M
max_binlog_size = 512M
max_binlog_cache_size = 1G
relay-log-info-repository = table
relay-log-recovery = 1
二、搭建主从
经过上面队友的一顿binlog重置操作，我们终于来到了本文的重头戏：主从同步的搭建。
2.1 创建账号
我们先来创建一个同步账号，待会设置slave的时候要用到。
# 在主库创建账号
mysql>create user 'sync'@'%' identified by 'Sync@123456';
# 授予账号监视的权限
mysql>grant replication slave on *.* to 'sync'@'%';
# 刷新权限
mysql>flush privileges;
到这里的话，我们的第一步算是完成了。
2.2 备份主库
注意：这里是在从库的实例进行的，防止影响主库的性能。
第二步就是把主库做下备份，当前，如果主库内容过大，可能导致前台进程跑的时间过长被断掉，这里使用 shell脚本 + nohup 后台执行。
shell 脚本如下：
#!bin/bash
source ~/.bash_profile
mysqldump -uusername -p'password' -P3306 -h masterHost --single-transaction --skip-lock-tables --default-set=utf8mb4 --master-data=2 -A > ./dump_master.sql
参数说明：
-
–master-data=2：CHANGE MASTER语句会被写成SQL注释。
-
–single-transaction：在导出数据之前提交一个BEGIN SQL语句，BEGIN 不会阻塞任何应用程序且能保证导出时数据库的一致性状态（仅仅适用于 Innodb存储引擎）。
Creates a consistent snapshot by dumping all tables in a single transaction. Works ONLY for tables stored in storage engines which support multiversioning (currently only InnoDB does)
- –default-set：设置默认字符集为 utf8mb4。
- –skip-lock-tables：一次性锁定当前库的所有表。
nohup后台执行：
# 防止终端关闭，进行结束，在这里使用后台进行执行
hostname>nohup sh dump_matser.sh &
# 查看进程
hostname>ps -ef | grep dump_master.sh
检查dump文件
hostname>tail -n10 ./dump_master.sql
有如下信息，就说明dump过程顺利结束（根据数据库大小，机器配置，速度可能会有差异）。
2.3 备份还原
这一步就比较简单了，同样还是用 shell脚本 + nohup 后台执行。
shell 脚本如下：
#!bin/bash
source ~/.bash_profile
mysql -uusername -p'password' -P3306 -h slaveHost < ./dump_master.sql
nohup后台执行：
# 防止终端关闭，进行结束，在这里使用后台进行执行
hostname>nohup sh dump_matser.sh &
# 查看进程
hostname>ps -ef | grep dump_master.sh
执行应该是会出现如下错误：
ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.
这里要把从库的GTID重置为空一下，才可以继续进行
# 登录从库
mysql>reset master;
这样子就可以继续执行备份还原了。
2.4 配置主从
在这里又分为了两个章节，主要原因是因为博主当时是用的传统的基于LOG_FILE和LOG_POS来进行的，感觉就是很蹩脚，后面队友提示可以GTID来搞，不得不说，很爽，不用自己再去找点位和文件信息了。不过掌握两种方式是很有必要的，下面一起来看一下吧！
2.4.1 基于LOG_FILE LOG_POS
还记得我们上面设置的 --master-data=2 嘛，这里就要用到了。
# 文件太大打开很慢，这里用grep命令快速查看下
hostname>grep 'CHANGE MASTER TO' ./dump_master.sql
该信息在dump下来的sql的前面位置，给大家看一下：
下面就好说了
# 进入从库一顿操作
mysql>stop slave;
# 把上面的信息对应下面语句就可以了
mysql>CHANGE MASTER TO MASTER_HOST='host_master',MASTER_USER='sync',MASTER_PASSWORD='Sync@123456',master_port=3306,MASTER_LOG_FILE='xxx',MASTER_LOG_POS=xxx;
# go on
mysql>start slave;
mysql>show slave masterG;
操作完就可以看到状态已经恢复正常了。
2.4.2 基于GTID
这里直接不需要我们再去查看LOG_FILE和LOG_POS，直接开搞：
# 进入从库一顿操作
mysql>stop slave;
# 执行下面语句
mysql>CHANGE MASTER TO MASTER_HOST='host_master',MASTER_USER='sync',MASTER_PASSWORD='Sync@123456',master_port=3306,master_auto_position=1;
# go on
mysql>start slave;
mysql>show slave masterG;
到这里我们的主从就重新搭建好啦！可喜可贺啊！下次可得把binlog过期时间重新设置下了。
2.4.3 传统模式 VS GTID模式
- 对应传统模式，需要找到正确的二进制日志文件和位置，否则就无法正确复制。
- 对于GTID模式，自动根据GTID来定位对应的二进制日志文件和位置，更准确地说，是自动寻找从库缺失的GTID SET对应的二进制日志记录，极大地降低了这些任务的复杂度。
以上是对两者的一个基本理解。
三、总结
本文主要介绍了，当主从同步发生故障时，要去如何发现问题所在，如何去重新进行主从的搭建，本文是采用的手动恢复的一个方式，欢迎各位大佬给与建议。