【MySQL】误操作使用reset slave怎么办

最新推荐文章于 2024-04-25 23:08:06 发布

卑微涛

最新推荐文章于 2024-04-25 23:08:06 发布

阅读量7k

点赞数 3

分类专栏：主从文章标签： mysql 数据库

DBATao

本文链接：https://blog.csdn.net/weixin_45238761/article/details/123776873

版权

主从专栏收录该内容

3 篇文章 0 订阅

订阅专栏

前言

各位小伙伴们，好久不见，今天我又来更新博客了（不愧是月更博主(～￣▽￣)～）

好吧，其实是因为我这个实习生，在做一个运维上线项目，然后之前对reset slave; 半懂不懂的状态，甚至理解为只是简单的重启主从关系的指令而已，然后直到前几天周五，脑子想也没想的在生产服务器上执行了这个指令（幸好当时业务还没上线），导致从库坏了，最后用了一下午+晚上，为此事以及后续引发的事件填坑┗( T﹏T )┛
特此记下我这个xx行为，下不再犯，也给大家做了一个反面教材。

=============================== 下面是正题 ==========================================
今天咱们来好好聊一聊reset slave;
众所周知，reset slave ，字面理解— 重置从库
在MySQL从库中这些这条指令后，会发生这些事情：
1.清除 master.info,relay-log.info文件(记录)。
2.删除所有的relay log，包括还没有应用完的日志，创建一个新的relay log文件。

what？这是啥，什么高级名称，下面卑微小涛来解释解释一下（PS：有基础or想看解决方案的大佬请忽略第一节，直接跳到第二节）

一、基础知识引入

谈及这个reset slave，那就不得不谈到主从库了，为了让刚来的小伙伴们更形象的看清主从的本质，特意画了这一张图（如果某天在leetcode的某个数据库面试题里面也看到了这张图，没错，就是我画的的😁）
在这里插入图片描述看不懂上面的单词？没事，细心的卑微小涛给大家找好了解释

【名词解释】
主库: 
	binlog 	#用二进制的方式，记录主库发送的事情
从库: 
	relaylog  中继日志
	master.info  主库信息文件
	relaylog.info relaylog应用的信息

主库:
	Binlog_Dump Thread : DUMP_T    #发送主库的数据到从库中
从库: 
	slave_IO_Thread     : IO_T		#复制接收DUMP_T发送的数据
	slave_SQL_Thread    : SQL_T		#读取中继日志的线程

附上主从复制原理的整个过程：

1.从库执行change master to 命令(主库的连接信息+复制的起点)
2.从库会将以上信息,记录到master.info文件
3.从库执行 start slave 命令,立即开启IO_T和SQL_T
4.从库 IO_T,读取master.info文件中的信息
	获取到IP,port,User,Pass,binlog的位置信息
5. 从库IO_T请求连接主库,主库专门提供一个DUMP_T,负责和IO_T交互
6. IO_T根据binlog的位置信息(mysql-bin.000004 , 444)或(GTID),请求主库新的binlog
7. 主库通过DUMP_T将最新的binlog,通过网络TP(传送)给从库的IO_T
8. IO_T接收到新的binlog日志,存储到TCP/IP缓存,立即返回ACK给主库,并更新master.info
9. IO_T将TCP/IP缓存中数据,转储到磁盘relaylog中.
10. SQL_T读取relay.info中的信息,获取到上次已经应用过的relaylog的位置信息
11. SQL_T会按照上次的位置点回放最新的relaylog,再次更新relay.info信息
12. 从库会自动清除应用过relaylog(中继日志文件),避免占用过多的磁盘空间

补充说明:
一旦主从复制构建成功,主库当中发生了新的变化,都会通过dump_T发送信号给IO_T,增强了主从复制的实时性.

在这里插入图片描述
好嘞，其实通俗来理解，就是
第一步：master在每个事务更新数据完成之前，将该操作记录串行地写入到binlog文件中。
第二步：salve开启一个IO_T线程，该线程在master打开一个普通连接，主要工作是binlog 进行转储。如果读取的进度已经跟上了master，就进入睡眠状态并等待master产生新的事件。I/O线程最终的目的是将这些事件写入到中继日志中。
第三步：SQL_T线程会读取中继日志，并顺序执行该日志中的SQL事件，从而与主数据库中的数据保持一致。

大家如果是面试的话，强烈建议用上面总结的那12个步骤+画的那个图。

二、思路

误操作reset slave后，就是会删掉从库赖以需要的master.info和relog.info文件
如果本身配置有MHA结构，请先暂时关闭掉MHA（若没配置，忽略此步）
- 原因：从库后面会关闭，万一这时候主库也宕机，那么MHA会把业务都插入到坏的从库里，导致业务数据丢失，所以建议先把MHA关闭
- 那这不还有另外一个从库吗？（因为一般另外一个从库用于做备份，MHA配置文件里不会把次节点选择作为新的主库）
这个时候，需要回到主库、或者另外一个从库里，用XBK把最新的数据导出来，然后传输到坏的从库节点里
关闭从库，删除或挪走从库本身有的数据内容（保留数据目录本身），再使用XBK的方式将最新的数据导入进来
导出完成后，再次启动从库节点，根据最近的位置节点信息，重新连接主库，恢复主从关系

三、实践操作

关闭MHA

ssh ip      #连接MHA节点
ps -ef |grep mha
masterha_check_status --conf=/etc/mha.conf
masterha_check_ssh --conf=/etc/mha.conf
masterha_check_repl --conf=/etc/mha.conf
/etc/init.d/masterha_manager stop    #关闭MHA。若没有这个脚本，通过上面三步的check后，只有pkill关闭也可以

导出

虽然可能每天都有备份，但估计一天的数据增长太大了，所以建议直接从主库XBK导出，然后scp到从库里
注意：根据实际环境修改相应的路径哦
ssh 主库IP   #登录主机节点
innobackupex --defaults-file=/etc/my.cnf --user=root --password=xxx --socket=mysql.sock /data  #XBK导出,/data是选择导出的存放目录
scp -r /data/new_bak刚才导出的文件   IP:/data/     #把导出的文件传输到坏的那个从库节点里

关闭并挪作原来的从库数据

ssh 从库IP
mysql> mysql -uroot -pxxx   #登录从库中
mysql> stop slave;     #停止从库的主从状态
/etc/init.d/mysqld stop   #关闭从库
mv /data/mysql  /tmp/

导入

#在从库检验主库传过来的这个文件是否能用
innobackupex --defaults-file=/etc/my.cnf  --apply-log /data/new_bak（这个是刚才传过来的文件）
#执行导入
innobackupex --defaults-file=/etc/my.cnf  --copy-back /data/new_bak（也是是刚才传过来的文件）

#导入后，进入mysql的data目录里面，找到xtrabackup_info文件
cat /data/mysql/xtrabackup_info
binlog_pos = filename 'mysql-bin.000020', position '123456'      #记录这一行，待会会用到

开始恢复从库

/etc/init.d/mysqld start      #启动MySQL
ps -ef |grep mysql
登录后执行此SQL语句，连接主从
mysql> change master to master_host='主库IP',
master_user='slave_user',
master_password='xxxxxx',
master_log_file='mysql-bin.000020',
master_log_pos=123456,
MASTER_PORT=3306;

mysql> start slave;

#从库节点上需要再执行一次
mysql> set global read_only=1;
mysql> set global relay_log_purge=0;

恢复MHA

注意：这个时候先不要启动MHA，等所有确认无误后后再启动
目的：通过MHA进行检查，是否恢复了正常的主从关系
masterha_check_ssh --conf=/etc/mha.conf      #都是检查主从状态是否OK
masterha_check_repl --conf=/etc/mha.conf


ssh MHA节点
修复mha，登录到mha manager节点
挪走之前的日志内容：
mv /var/log/masterha/mha.failover.complete /tmp/mha.failover_1
mv /var/log/masterha/manager.log /tmp/manager.log_1

#检查
masterha_check_ssh --conf=/etc/mha.conf
masterha_check_repl --conf=/etc/mha.conf

/etc/init.d/masterha_manager start
ps -ef |grep mha
检查mha是否成功启动：masterha_check_status --conf=/etc/mha.conf

#手动启动方法
#nohup masterha_manager --conf=/etc/mha.conf --ignore_last_failover > /var/log/masterha/manager.log 2>&1 &
#--ignore_last_failover：在缺省情况下，如果 MHA 检测到连续发生宕机，且两次宕机间隔不足 8 小时的话，则不会进行 Failover， 之所以这样限制是为了避免 ping-pong 效应
#该参数代表忽略上次 MHA 触发切换产生的文件，默认情况下，MHA发生切换后会在日志记目录，也就是上面设置的日志文件，下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，除非在第一次切换后删除了该文件

四、总结

以后不熟悉、半懂不懂的指令，一定要弄清楚在执行，尤其是在生产库下，这次真是慢慢的教训，本来这个运维项目下午能完成的，最后弄完后续操纵已经23：00了，泪的教训。
好了好了，如果您觉得本文对您有帮助的话，还请三连支持一下啦，点个免费的赞也行呢😃
我是励志成为一名优秀DBA的小涛同学，有疑问的小伙伴欢迎在评论区讨论，咱们一起努力，冲冲冲！咱们下篇博文再见了~
在这里插入图片描述