标题：mysql slave relaylog名称修改后出现启动主从复制出现启动slave时，使用repository中信息初始化relay log结构失败了。为什么失败了？原来是从tjtx135-1-95-relay-bin.index文件中找不到tjtx-96-67-relay-bin.017814文件。
出处：向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
时间：Fri, 24 Nov 2017 16:34:16 +0000
作者：jackxiang
地址：http://jackxiang.com/post/9534/

内容：
今天在使用冷备份文件重做从库时遇到一个报错，值得研究一下。
版本：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时，就会读取该表中的位置信息。

新版本使用表来代替原来的文件，主要为了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)
1
dba:(none)> change master to ......
1
2
dba:(none)> start slave;
Query OK, 0 rows affected (0.00 sec)
到这里问题解决了。
来自：https://www.cnblogs.com/mysql-dba/p/7201513.html
【经验】：以后用冷备份恢复实例后，在启动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


Generated by Jackxiang's Bo-blog 2.1.1 Release