【FAQ系列】Relay log 导致复制启动失败
2017-07-18 17:10
501 查看
今天在使用冷备份文件重做从库时遇到一个报错,值得研究一下。
一、报错现象
这个时候查看error.log:
从报错上看,意思是启动slave时,使用repository中信息初始化relay log结构失败了。为什么失败了?原来是从tjtx135-1-95-relay-bin.index文件中找不到tjtx-96-67-relay-bin.017814文件。到这里,答案就很清楚了,由于我使用的是冷备份文件恢复的实例,在mysql库中的slave_relay_log_info表中依然保留之前relay_log的信息,所以导致启动slave报错。
那如何解决呢?先来简单的了解MySQL Relay log的基础知识:
二、MySQL Relay log介绍
在MySQL复制结构下,Slave服务器会产生三种日志文件,用来保存主库的二进制日志事件以及relay log已执行到的位置和状态。
1、relay log 文件:由IO thread线程从主库读取的二进制日志事件组成,该日志被Slave上的SQL thread线程执行,从而实现数据的复制。
2、master info log:该文件保存slave连接master的状态以及配置信息,如用户名,密码,日志执行的位置等。在5.6版本之前,都是使用master.info文件,从5.6开始,通过在my.cnf 中配置
3、relay log info log:该文件保存slave上relay log的执行位置。在5.6版本之前,都是使用relay-log.info文件,从5.6开始,通过在my.cnf中配置
新版本使用表来代替原来的文件,主要为了crash-safe replication,从而大大提高从库的可靠性。为了保证意外情况下从库的可靠性,mysql.slave_master_info和mysql.slave_relay_log_info表必须为事务性的表,从5.6.6起,这些表默认使用InnoDB存储引擎。在5.6.5及之前的版本默认使用MyISAM引擎,可用下面语句进行转换:
【注意】不要试图手工的更新、插入、删除以上两个表的内容,以免出现意料不到的问题。
三、问题解决
通过上面的报错以及relay log介绍,很容易知道由于mysql.slave_relay_log_info表中保留了以前的复制信息,导致新从库启动时无法找到对应文件,那么我们清理掉该表中的记录不就可以了。再次提醒,不要手动删该表数据,MySQL已经提供工具给我们了:reset slave:
reset slave干的那些事:
下面解决问题:
到这里问题解决了。
【经验】:以后用冷备份恢复实例后,在启动slave前,先进行reset slave清空下以前的旧信息。
【参考资料】:https://dev.mysql.com/doc/refman/5.6/en/slave-logs.html
https://dev.mysql.com/doc/refman/5.6/en/reset-slave.html
版本:MySQL5.6.27
一、报错现象
dba:(none)> start slave; ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository
这个时候查看error.log:
2017-07-17 16:19:02 9022 [ERROR] Failed to open the relay log './tjtx-96-67-relay-bin.017814' (relay_log_pos 172582079). 2017-07-17 16:19:02 9022 [ERROR] Could not find target log file mentioned in relay log info in the index file './tjtx135-1-95-relay-bin.index' during relay log initialization. 2017-07-17 16:19:02 9022 [ERROR] Failed to initialize the master info structure 2017-07-17 16:19:02 9022 [Note] Check error log for additional messages. You will not be able to start replication until the issue is resolved and the server restarted. 2017-07-17 16:19:02 9022 [Note] Event Scheduler: Loaded 0 events 2017-07-17 16:19:02 9022 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.6.27-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Server (GPL) 2017-07-17 16:19:06 9022 [ERROR] Slave SQL: Slave failed to initialize relay log info structure from the repository, Error_code: 1872
从报错上看,意思是启动slave时,使用repository中信息初始化relay log结构失败了。为什么失败了?原来是从tjtx135-1-95-relay-bin.index文件中找不到tjtx-96-67-relay-bin.017814文件。到这里,答案就很清楚了,由于我使用的是冷备份文件恢复的实例,在mysql库中的slave_relay_log_info表中依然保留之前relay_log的信息,所以导致启动slave报错。
那如何解决呢?先来简单的了解MySQL Relay log的基础知识:
二、MySQL Relay log介绍
在MySQL复制结构下,Slave服务器会产生三种日志文件,用来保存主库的二进制日志事件以及relay log已执行到的位置和状态。
1、relay log 文件:由IO thread线程从主库读取的二进制日志事件组成,该日志被Slave上的SQL thread线程执行,从而实现数据的复制。
2、master info log:该文件保存slave连接master的状态以及配置信息,如用户名,密码,日志执行的位置等。在5.6版本之前,都是使用master.info文件,从5.6开始,通过在my.cnf 中配置
--master-info-repository=TABLE。这些信息会被写入
mysql.slave_master_info表中,代替原来的master.info文件了。
3、relay log info log:该文件保存slave上relay log的执行位置。在5.6版本之前,都是使用relay-log.info文件,从5.6开始,通过在my.cnf中配置
--relay-log-info-repository=TABLE,使用mysql.slave_relay_log_info表代替原来的文件。每次当slave上执行start slave时,就会读取该表中的位置信息[code]。
新版本使用表来代替原来的文件,主要为了crash-safe replication,从而大大提高从库的可靠性。为了保证意外情况下从库的可靠性,mysql.slave_master_info和mysql.slave_relay_log_info表必须为事务性的表,从5.6.6起,这些表默认使用InnoDB存储引擎。在5.6.5及之前的版本默认使用MyISAM引擎,可用下面语句进行转换:
ALTER TABLE mysql.slave_master_info ENGINE=InnoDB; ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;
【注意】不要试图手工的更新、插入、删除以上两个表的内容,以免出现意料不到的问题。
三、问题解决
通过上面的报错以及relay log介绍,很容易知道由于mysql.slave_relay_log_info表中保留了以前的复制信息,导致新从库启动时无法找到对应文件,那么我们清理掉该表中的记录不就可以了。再次提醒,不要手动删该表数据,MySQL已经提供工具给我们了:reset slave:
reset slave干的那些事:
1、删除slave_master_info ,slave_relay_log_info两个表中数据; 2、删除所有relay log文件,并重新创建新的relay log文件; 3、不会改变gtid_executed 或者 gtid_purged的值
下面解决问题:
dba:(none)> reset slave; Query OK, 0 rows affected (0.00 sec)
dba:(none)> change master to ......
dba:(none)> start slave; Query OK, 0 rows affected (0.00 sec)
到这里问题解决了。
【经验】:以后用冷备份恢复实例后,在启动slave前,先进行reset slave清空下以前的旧信息。
【参考资料】:https://dev.mysql.com/doc/refman/5.6/en/slave-logs.html
https://dev.mysql.com/doc/refman/5.6/en/reset-slave.html
相关文章推荐
- Relay log 导致复制启动失败
- FAQ系列 | 列类型被自动修改导致复制失败
- FAQ系列 | table id问题导致主从复制失败
- 虚拟机复制操作CentOS6导致eth0转为eth0以至于网络服务启动失败的解决方案
- [Oracle 11g r2(11.2.0.4.0)]案例分析1-OLR丢失导致数据库启动失败
- VS2010 中Set容器的 iterator 被默认定义为了const_iterator,导致通过iterator复制的操作失败
- SYSVOL 共享后的最近 24 小时内出现了警告或错误事件。 失败的 SYSVOL 复制问题可能导致组策略问题
- Spring配置文件xsi:schemaLocation无法解析导致启动失败的解决方案 转!classpath:/org/springframework/
- DI v6.2,DI Governor在Linux下启动脚本startDIGovernor.sh编码格式问题导致启动失败
- 解决端口被占用而导致软件运行失败,程序无法启动,无法安装开发工具等问题
- 【Hadoop】ZooKeeper集群搭建中的Connection refused而导致的启动失败
- JDK冲突导致启动IBM Cognos 8失败
- 卸载或升级jenkins插件导致jenkins启动失败
- [MySQL FAQ]系列 — MySQL无法启动例一
- 过期文件导致VCS双机启动失败
- Oracle数据库案例整理-删除和停止Oracle数据库失败-Oracle回收站启动导致删除表空间文件失败
- ubuntu 10.04任务栏误删导致桌面启动失败
- 由于系统时间修改导致Oracle启动失败
- 引用 Acronis Disk Director Suite 10.00.2160 汉化版导致硬盘分区失败启动时出现Abnormal termination