一次Mysql slave库恢复实战记录

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

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,至此,mysql从库找不到该文件,是无法同步了。

解决办法:
1.在slave库上重新指定同步位置。(不可行)

slave stop;
CHANGE MASTER TO MASTER_LOG_FILE=‘mysql-bin.000095‘,MASTER_LOG_POS=869242147; //mysql master节点上mysql-bin.000095的已有位置
slave start;

slave节点上show slave status,依然报错,具体的报错内容没有复制下来,只记得errno为1236,Slave_IO_Running进程不运行,Slave_SQL_Running进程运行,大概描述就是某个库的某个表有问题。
在多次尝试指定不同的同步位置(报错的位置,master上mysql-bin-000095刚写过的位置)依然存在该错误。
实际上,表记录已经有问题,就拿描述中提出的那个表来说,slave库存放了约1200条记录,master库则有1900+的记录。除非手工将这些数据补上,否则由于记录操作数据的日志已经丢失(被我删除),是找不到最近的一致的日志操作执行位置的。

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

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

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

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

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

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日志的位置:

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节点上强行指定master日志读取位置或者跳过错误,也不排除slave库上数据丢失的可能。

原文地址:https://blog.51cto.com/kotori/2412630

时间: 2024-07-30 19:46:13

一次Mysql slave库恢复实战记录的相关文章

MySQL误删库恢复实战

创建测试库.表 create database test; use test; create table leo (id int,name varchar(10)); 插入数据 insert into leo values (1,"liufeng"); insert into leo values (2,"zhangsan"); insert into leo values (3,"liufeng"); insert into leo value

使用Percona Xtrabackup创建MySQL slave库

MySQL Server 版本: Server version: 5.7.10-log MySQL Community Server (GPL) Percona Xtrabackup 版本: innobackupex version 2.4.2 Linux (x86_64) (revision id: 8e86a84) 说明: [master]:表示在master库上执行的语句 [slave]:表示在slave库上执行的语句 --执行master库的全备[master]innobackupex

【转】mysql增量备份恢复实战企业案例

来源地址:http://seanlook.com/2014/12/05/mysql_incremental_backup_example/ 小量的数据库可以每天进行完整备份,因为这也用不了多少时间,但当数据库很大时,就不太可能每天进行一次完整备份了,这时候就可以使用增量备份.增量备份的原理就是使用了mysql的binlog日志. 本次操作的MySQL版本为5.5.40 for Linux (x86_64). 增量备份要确保打开了二进制日志,参考mysql的日志系统: 1 mysql> show

MySQL备份和恢复实战

MyISAM数据表备份之mysqlhotcopy 数据表为myisam引擎的备份.可以使用mysqlhotcopy和mysqldump工具进行备份. 1)介绍 这个工具是一个Perl语言写的脚本.使用mysqlhotcopy必须安装perl-DBD-MySQL.perl-DBD. 2)特点 a:文件系统级别的copy,mysqldump则是数据库端的SQL语句集合 b:只能运行在数据库目录所在的机器上,mysqldump则任何机器都可以. c:mysqldump和mysqlhotcopy都执行l

MySQL从库记录binlog日志出错一例

昨天晚上学习视频"L11-16-配置MySQL从库记录binlog及其生产应用场景w",开头部分就卡住了. 在数据库的配置文件/data/3307/my.cnf里,开启参数"log-bin = /data/3307/mysql-bin",并增加"log-slave-updates"参数之后,重启数据库服务. 测试创建1个新库"create database oldgirl02;"之后,即使过滤新生成的logbin日志文件还是没

从MySQL全库备份中恢复某个库和某张表【转】

从MySQL全库备份中恢复某个库和某张表 一.全库备份-A [[email protected] backup]#mysqldump -uroot -p123456 --default-character-set=utf8 --single-transaction --extended-insert=false --hex-blob --master-data=2 --log-error=/tmp/test.err --routines --triggers --events --quick -

mysql库备份&库恢复

1.1全库备份 mysqldump -uroot -p123456 database_demo > /home/utfladmin/database_demo_20191101.dump 1.2清除库中某张表的信息-查询结果为空: 1.3全库恢复 mysql -uroot -p123456 database_demo < /home/utfladmin/database_demo_20191101.dump 1.4验证:查询1.2步骤清除数据的表-有结果: 原文地址:https://www.c

mysql全库备份恢复某个表

早上小红过来问我说网站的一个功能没了,看了下数据库,少了个表.好吧,心里mmp,开始恢复数据 环境: 全库备份 恢复某一个表 1.1 查看备份数据 [[email protected] mysql_backup]$ ls -lhtotal 16G-rw-r--r-- 1 root root 5.4G May 21 00:58 2018_05_21_00_30_01.all.sql.zip     ##找到了备份数据 1.2  查看备份文件类型 [[email protected] mysql_b

再谈MySQL全库备份

再谈MySQL全库备份 简介 Part1:写在最前 在很早之前,我写过一个MySQL生产库全库备份脚本,今天有同事问我是不是要再加一个-R参数来备份存储过程,理由的话是由于mysqldump --help中 关于存储过程的默认备份是false. routines                          FALSE MySQL生产库全库备份脚本 http://suifu.blog.51cto.com/9167728/1758022 实战 Part1:写在最前 我备份一般就三个参数 --s