前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >MySQL Slave库恢复实录

MySQL Slave库恢复实录

作者头像
星哥玩云
发布2022-08-18 19:07:16
2830
发布2022-08-18 19:07:16
举报
文章被收录于专栏:开源部署开源部署

状况描述: 今天登录一个MySQL数据库slave节点主机发现/var/lib/mysql下存放大量的mysql-relay-bin文件,最早的文件创建日期甚至是2018年,我记得在slave库同步完master的日志操作记录后,会删除这些文件(默认设置不会删除,我记错了),于是便查看了slave库的状态,发现如下报错:

代码语言:javascript
复制
mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: *.*.*.*
                  Master_User: dbsync
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000095
          Read_Master_Log_Pos: 869242147
               Relay_Log_File: mysqld-relay-bin.000146
                Relay_Log_Pos: 871280529
        Relay_Master_Log_File: mysql-bin.000075
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: cdb,cdb_admin
          Replicate_Ignore_DB: mysql
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 1594
                   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, 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
          Exec_Master_Log_Pos: 871280384
              Relay_Log_Space: 19994786573
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 1594
               Last_SQL_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, 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.
1 row in set (0.00 sec)

ERROR: 
No query specified

原因: 我在master节点上删除了名称为mysql-bin.00007格式的文件,其中包括mysql-bin.000075,因此,slave库找不到该文件,无法同步。

解决办法:

重做slave库。由于数据差异太大,而且我觉得不光一张表出现了数据不一样的问题,所以干净点,把从库重做。

1)比对master、slave节点库配置信息,保证一致。(我不知道为什么设置了双主模式,实际上我只有一个实例跑在master节点上啊?)

2)在master、slave节点上查看流量情况(show processlist),保证要重做的slave库上没有业务的流量接入。

3)停止master节点上slave进程。(这个停了以后,我就没开过,不知道有没有问题,待观察)

4)记录master节点上库的日志记录位置,之后备份数据库

代码语言:javascript
复制
mysql> show master status;
+------------------+-----------+-------------------------------+------------------+
| File             | Position  | Binlog_Do_DB                  | Binlog_Ignore_DB |
+------------------+-----------+-------------------------------+------------------+
| mysql-bin.000095 | 871760173 | cdb,cdb_admin | mysql            |
+------------------+-----------+-------------------------------+------------------+
1 row in set (0.01 sec)
 mysqldump -u root -p --databases cdb,cdb_admin > bak.master.sql

5)保险起见,备份slave节点库: mysqldump -u root -p --databases cdb,cdb_admin > bak.slave.sql

6)重做开始:把master库备份文件复制到slave节点上,导入该备份文件 mysql -u root -p < bak.master.sql

7)在slave节点上,重新指定读master日志的位置:

代码语言:javascript
复制
slave stop;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000095',MASTER_LOG_POS=871760173; //POS为刚才记录的master节点日志记录位置
slave start;

8)slave节点上 show slave status;此时Slave_IO_Running,Slave_SQL_Running均运行起来了,刷新slave status,Read_Master_Log_Pos数值也开始增加,重新开始同步了。

总结: 清理文件时,要注意mysql-bin文件在master、slave节点日志读取和写的位置啊!删之前一定要确认日志位置在master和slave断已被读过,不要乱删,否则搞得slave库无法同步了,就算在slave节点上强行指定master日志读取位置或者跳过该错误,也不排除slave库上数据丢失的可能。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云数据库 SQL Server
腾讯云数据库 SQL Server (TencentDB for SQL Server)是业界最常用的商用数据库之一,对基于 Windows 架构的应用程序具有完美的支持。TencentDB for SQL Server 拥有微软正版授权,可持续为用户提供最新的功能,避免未授权使用软件的风险。具有即开即用、稳定可靠、安全运行、弹性扩缩等特点。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档