磁盘写满导致MySQL复制失败的解决方案

案例场景

今天在线上发现一个问题,由于监控没有覆盖到,某台机器的磁盘被写满了,导致线上MySQL主从复制出现问题。问题如下:

localhost.(none)>show slave status\G
*************************** 1. row ***************************
               Slave_IO_State:
                  Master_Host: 10.xx.xx.xx
                  Master_User: replica
                  Master_Port: 5511
                Connect_Retry: 60
              Master_Log_File:
          Read_Master_Log_Pos: 4
               Relay_Log_File: relay-bin.001605
                Relay_Log_Pos: 9489761
        Relay_Master_Log_File:
             Slave_IO_Running: No
            Slave_SQL_Running: No
                   Last_Errno: 13121
                   Last_Error: Relay log read failure: Could not parse relay log event entry. 
The possible reasons are: the master's binary log is corrupted (you can check this by running 
'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by 
running 'mysqlbinlog' on the relay log), a network problem, the server was unable to fetch a
 keyring key required to open an encrypted relay log file, or a bug in the master's or 
slave's MySQL code. If you want to check the master's binary log or slave's relay log, 
you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.

于是查看error log,发现error log中的内容如下:

2021-03-31T11:34:39.367173+08:00 11 [Warning] [MY-010897] [Repl] Storing MySQL user name or 
password information in the master info repository is not secure and is therefore not 
recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; 
see the 'START SLAVE Syntax' in the MySQL Manual for more information.

2021-03-31T11:34:39.368161+08:00 12 [ERROR] [MY-010596] [Repl] Error reading relay log 
event for channel '': binlog truncated in the middle of event; consider out of disk space

2021-03-31T11:34:39.368191+08:00 12 [ERROR] [MY-013121] [Repl] Slave SQL for channel '': Relay 
log read failure: Could not parse relay log event entry. The possible reasons are: the master's 
binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the 
slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log),
 a network problem, the server was unable to fetch a keyring key required to open an encrypted
 relay log file, or a bug in the master's or slave's MySQL code. If you want to check the 
master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW
 SLAVE STATUS' on this slave. Error_code: MY-013121

2021-03-31T11:34:39.368205+08:00 12 [ERROR] [MY-010586] [Repl] Error running query, slave SQL
 thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We 
stopped at log 'mysql-bin.000446' position 9489626

从描述中可以看到,error log是比较智能的,发现了磁盘问题,并提示我们需要"consider out of disk space"

解决问题

登录服务器,很快就发现是MySQL所在的服务器磁盘使用率达到100%了,问题原因跟error log中的内容一致。

现在就解决这个问题。基本的思路就是清理磁盘文件,然后重新搭建复制关系,这个过程似乎比较简单,但是实际操作中,在搭建复制关系的时候出现了下面的报错:

### 基于gtid的复制,想重新搭建复制关系
localhost.(none)>reset slave;
ERROR 1371 (HY000): Failed purging old relay logs: Failed during log reset

localhost.(none)>reset slave all;
ERROR 1371 (HY000): Failed purging old relay logs: Failed during log reset

第一步:因为复制是基于gtid进行的,所以直接记录show slave status的状态后,就可以重新reset slave,并利用change master语句来重建复制关系了。

但是却出现上面的报错,从报错信息看是mysql无法完成purge relay log的操作,这看起来不科学。好吧,既然你自己不能完成purge relay logs的操作,那就让我来帮你吧。

第二步:手工rm -f 删除所有的relay log,发现报错变成了:

localhost.(none)>reset slave all;
ERROR 1374 (HY000): I/O error reading log index file

嗯,好吧,问题没有得到解决。

然后思考了下,既然不能通过手工reset slave 来清理relay log,直接stop

slave 然后change master行不行呢?

第三步:直接stop slave,然后change master,不执行reset slave all的语句,结果如下:

localhost.(none)>change master to master_host='10.13.224.31',
    -> master_user='replica',
    -> master_password='eHnNCaQE3ND',
    -> master_port=5510,
    -> master_auto_position=1;
ERROR 1371 (HY000): Failed purging old relay logs: Failed during log reset

得,问题依旧。

第四步:反正复制已经报错断开了,执行个start slave看看,结果戏剧性的一幕出现了:

localhost.(none)>start slave;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    262
Current database: *** NONE ***

Query OK, 0 rows affected (0.01 sec)

localhost.(none)>
[root@ ~]#

执行start slave之后,实例直接挂了。

到这里,复制彻底断开了,从库实例已经挂了。

第五步:看看实例还能不能重启,尝试重启实例,发现实例还能起来。实例重新起来后,查看复制关系,结果如下:

localhost.(none)>show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Queueing master event to the relay log
                  Master_Host: 10.xx.xx.xx
                  Master_User: replica
                  Master_Port: 5511
                Connect_Retry: 60
              Master_Log_File: 
          Read_Master_Log_Pos: 4
               Relay_Log_File: relay-bin.001605
                Relay_Log_Pos: 9489761
        Relay_Master_Log_File:
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
                   Last_Errno: 13121
                   Last_Error: Relay log read failure: Could not parse relay log event entry.
 The possible reasons are: the master's binary log is corrupted (you can check this by running 
'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by 
running 'mysqlbinlog' on the relay log), a network problem, the server was unable to fetch a 
keyring key required to open an encrypted relay log file, or a bug in the master's or slave's 
MySQL code. If you want to check the master's binary log or slave's relay log, you will be able 
to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
                 Skip_Counter: 0

复制关系依旧报错。

第六步:重新reset slave all看看,结果成功了。

localhost.(none)>stop slave;
Query OK, 0 rows affected (0.00 sec)

localhost.(none)>reset slave all;
Query OK, 0 rows affected (0.03 sec)

第七步:重新搭建复制关系并启动复制

localhost.(none)>change master to master_host='10.xx.xx.xx',
    -> master_user='replica',
    -> master_password='xxxxx',
    -> master_port=5511,
    -> master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.01 sec)

localhost.(none)>start slave;
Query OK, 0 rows affected (0.00 sec)

localhost.(none)>show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.xx.xx.xx
                  Master_User: replica
                  Master_Port: 5511
                Connect_Retry: 60
                          ...
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

发现实例的复制关系可以建立起来了。

一点总结

当磁盘写满的情况发生之后,mysql服务无法向元信息表中写数据,relay log也可能已经不完整了,如果直接清理了服务器上的磁盘数据,再去重新change master修改主从复制关系,可能会出现报错,不能直接修复,因为这不是一个正常的主从复制关系断裂场景。

所以,正确的做法应该是:

1、清理服务器的磁盘

2、重启复制关系断开的那个从库

3、重新reset slave all、change master来搭建主从复制关系即可

如果有更好的方法,还请不吝赐教。

以上就是磁盘写满导致MySQL复制失败的解决方案的详细内容,更多关于MySQL复制失败的解决方案的资料请关注我们其它相关文章!

(0)

相关推荐

  • MySQL 复制表的方法

    1.mysqldump 执行过程: 一.将数据导出为 sql 文件. mysqldump -h$host -P$port -u$user --add-locks=0 --no-create-info --single-transaction --set-gtid-purged=OFF db1 t --where="a>900" --result-file=/client_tmp/t.sql 将数据导出为 sql 文件保存.上面几个参数的含义分别是: 1.–single-trans

  • 浅析MySQL并行复制

    01 并行复制的概念 在MySQL的主从复制架构中,主库上经常会并发的执行很多SQL,只要这些SQL没有产生锁等待,那么同一时间并发好几个SQL线程是没有问题的. 我们知道,MySQL的从库是要通过IO_thread去拉取主库上的binlog的,然后存入本地,落盘成relay-log,通过sql_thread来应用这些relay-log. 在MySQL5.6之前的版本中,当主库上有多个线程并发执行SQL时,sql_thread只有一个,在某些TPS比较高的场景下,会出现主库严重延迟的问题.MyS

  • MySQL 8.0.23中复制架构从节点自动故障转移的问题

    接触MGR有一段时间了,MySQL 8.0.23的到来,基于MySQL Group Replicaion(MGR)的高可用架构又提供了新的架构思路. 灾备机房的slave,如何更好的支持主机房的MGR? MGR 到底可以坏几个节点? 这次我就以上2个问题,和大家简单聊下MGR的一些思想和功能. 一.MySQL Group Relication 成员数量的容错能力 上面的表格相信大家不会陌生了,我经常在面试里会问:"4个节点的MGR,最多坏几个呢?" ,多数人回答:"最多坏1个

  • MySql主从复制实现原理及配置

    数据库读写分离对于大型系统或者访问量很高的互联网应用来说,是必不可少的一个重要功能.对于MySQL来说,标准的读写分离是主从模式,一个写节点Master后面跟着多个读节点,读节点的数量取决于系统的压力,通常是1-3个读节点的配置.而一般的读写分离中间件,例如Mycat的读写分离和自动切换机制,需要mysql的主从复制机制配合. 主从配置需要注意的地方 1.主DB server和从DB server数据库的版本一致 2.主DB server和从DB server数据库数据名称一致 3.主DB se

  • 浅析MySQL的WriteSet并行复制

    [历史背景] 岁月更迭中我已经从事MySQL-DBA这个工作三个年头,见证MySQL从"基本可用","边缘系统可以用MySQL","哦操!你怎么不用MySQL"; 正所谓!"一个数据库的境遇既取决于历史的进程,取决于它的自我奋斗!",关于"历史的进程"在此不表,关于"自我奋斗"这里也只想谈一下并行复制的几个关键时间结点 总的来说MySQL关于并行复制到目前为止经历过三个比较关键的时间结点

  • MySQL复制问题的三个参数分析

    今天星期二,早上居然起晚了,上班迟到了,简直是...废话不多说,在昨天的文章中,我们提到了三个参数,分别是: slave_exec_mode参数: sql_slave_skip_counter=N参数; slave-skip-errors=N参数. 这三个参数都可以解决并行复制中的一些指定的错误,例如duplicate key 1062错误等,今天我们简单试验一下,这三个参数的区别: 01 sql_slave_skip_counter参数 这个参数的设置主要是为了跳过某些错误的"event&qu

  • MySQL主从复制原理以及需要注意的地方

    写在前面 最近在写Mycat专题,由于不少小伙伴最近要出去面试,问我能不能简单写下MySQL的主从复制原理和注意事项,因为在之前的面试中被问到了这些问题.我:可以啊,安排上了!! 主从复制原理 (1) Master 将数据改变记录到二进制日志(binary log)中,也就是配置文件 log-bin 指定的文件, 这些记录叫做二进制日志事件(binary log events): (2) Slave 通过 I/O 线程读取 Master 中的 binary log events 并写入到它的中继

  • Mysql主从复制与读写分离图文详解

    文章思维导图 为什么使用主从复制.读写分离 主从复制.读写分离一般是一起使用的.目的很简单,就是为了提高数据库的并发性能. 你想,假设是单机,读写都在一台MySQL上面完成,性能肯定不高. 如果有三台MySQL,一台mater只负责写操作,两台salve只负责读操作,性能不就能大大提高了吗? 所以主从复制.读写分离就是为了数据库能支持更大的并发. 随着业务量的扩展.如果是单机部署的MySQL,会导致I/O频率过高. 采用主从复制.读写分离可以提高数据库的可用性. 主从复制的原理 ①当Master

  • MySql主从复制机制全面解析

    作为一个关系型数据库,MySQL内建地提供数据复制机制,这使得在使用时,可以基于其复制机制实现高可用架构等高级特性,从而使得MySQL无需借助额外的插件或其他工具就具备适用于生产环境.这是MySQL得到大面积实际应用的条件之一. 基于MySQL的复制机制,不仅可以实现数据库的高可用,还能实现如:性能扩展.异地灾备以及冷热分离等高级特性. 高可用:通过配置一定的复制机制,MySQL实现了跨主机的数据复制,从而获得一定的高可用能力,如果需要获得更高的可用性,只需要配置多个副本,或者进行级联复制就可以

  • MYSQL数据库GTID实现主从复制实现(超级方便)

    一.添加Maria源 vi /etc/yum.repos.d/MariaDB.repo 粘贴阿里云的最新mariadb镜像: [mariadb] name = MariaDB baseurl = https://mirrors.aliyun.com/mariadb/yum/10.5/centos7-amd64/ gpgkey=https://mirrors.aliyun.com/mariadb/yum/RPM-GPG-KEY-MariaDB gpgcheck=1 安装新版本的MariaDB yu

  • mysql 如何动态修改复制过滤器

    MySQL动态修改复制过滤器 说说今天遇到的问题吧,今天在处理一个业务方的需求,比较变态,我大概描述一下: 1.线上的阿里云rds上面有个游戏的日志库,里面的表都是日表的形式,数据量比较大了,每次备份的时候,都会导致线上的rds报警,报警内容是IO资源占用过多. 2.这个rds上有一个本地的ECS只读从库,这个只读从库会实时同步线上的rds数据库中的数据,这个只读从库供业务方查询使用 3.业务方说这些数据都还有用,只读从库上的数据必须有,线上rds上的数据可以删除,保留两个星期即可. 场景就是这

随机推荐