【FAQ系列】Relay log 导致复制启动失败

转自:https://www.cnblogs.com/mysql-dba/p/7201513.html

在冷备份恢复或者重启数据库时,可能报以下错误,修改了主机名也可能会产生这个错误(同步日志文件名默认是用主机名定义的,所以修改了主机名后导致同步报错。)

版本:MySQL5.6.27

一、报错现象

复制代码
数据库正常启动,但是复制线程无法启动,原因是无法读取中级日志中的信息


dba:(none)> start slave;
ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository


错误日志:
2020-07-03 05:13:39 6946 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Ple
ase consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
2020-07-03 05:13:39 6946 [Note] Slave I/O thread: connected to master 'repl@10.25.231.145:3309',replication started in log 'mysql-bin.003833' at position 974401016
2020-07-03 05:13:39 6946 [Warning] Slave SQL: If a crash happens this configuration does not guarantee that the relay log info will be consistent, Error_code: 0
2020-07-03 05:13:39 6946 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.003833' at position 974401016, relay log './cpzz146-relay-bin.0
00001' position: 4
2021-07-15 14:52:06 23088 [ERROR] Failed to open the relay log './cpzz146-relay-bin.006407' (relay_log_pos 771293478).
2021-07-15 14:52:06 23088 [ERROR] Could not find target log file mentioned in relay log info in the index file './mysql-relay-bin.index' during relay log initialization.
2021-07-15 14:52:06 23088 [ERROR] Failed to initialize the master info structure
2021-07-15 14:31:51 14172 [Note] Event Scheduler: Loaded 0 events
2021-07-15 14:31:51 14172 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.6.30-log' socket: '/var/lib/mysql/mysql.sock' port: 3309 MySQL Community Server (GPL)
复制代码

二、原因分析

从报错上看,意思是启动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复制结构下,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的值(也就不会改变binglog postion位点信息)

下面解决问题:

1.清除所有的slave 信息:
sql> reset slave;
Query OK, 0 rows affected (0.00 sec)
 
 
2.设置复制开始的binglog 位点信息:
 
复制代码
   binglog 位点信息可以在show slave status 中查找

   Master_Log_File: mysql-bin.005966
   Read_Master_Log_Pos: 840235078

   也可查找关闭数据库时的应用到的最后的位点信息;

   2021-07-15 14:24:49 6946 [Note] Slave I/O thread killed while reading event
   2021-07-15 14:24:49 6946 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.005966', position 771293315

change master to master_host='ip',\
master_port=port,master_user='repl',master_password='passwd',\
master_log_file='mysql-bin.005966',master_log_pos=771293315;
复制代码
3.启动复制:
sql> start slave;
Query OK, 0 rows affected (0.00 sec)
 

用冷备份恢复实例后,在启动slave前,先进行reset slave清空下以前的旧信息。

 

 五、reset master 和reset slave 区别:

【一】RESET MASTER参数

功能说明:删除所有的binglog日志文件,并将日志索引文件清空,重新开始所有新的日志文件。用于第一次进行搭建主从库时,进行主库binlog初始化工作;

 注意reset master 不同于purge binary log的两处地方
1. reset master 将删除日志索引文件中记录的所有binlog文件,创建一个新的日志文件 起始值从000001 开始,然而purge binary log 命令并不会修改记录binlog的顺序的数值
2. reset master 不能用于有任何slave 正在运行的主从关系的主库。因为在slave 运行时刻 reset master 命令不被支持,reset master 将master 的binlog从000001 开始记录,slave 记录的master log 则是reset master 时主库的最新的binlog,从库会报错无法找的指定的binlog文件。

   注:当数据库要清理binlog文件的时候,可以通过操作系统进行删除,也可以运行reset master进行删除。但是如果当前是主数据库,且主从数据库正常的时候,千万不能用这种方式删除。

【使用场景】第一次搭建主从数据库时,用于主库的初始化binglog操作;

【二】RESET SLAVE

功能说明:用于删除SLAVE数据库的relaylog日志文件,并重新启用新的relaylog文件;

reset slave 将使slave 忘记主从复制关系的位置信息。该语句将被用于干净的启动, 它删除master.info文件和relay-log.info 文件以及所有的relay log 文件并重新启用一个新的relaylog文件。

使用reset slave之前必须使用stop slave 命令将复制进程停止。
-删除master.info和relay-log.info文件
  -删除所有的relay log(包括还没有应用完的日志)
  -创建一个新的relay log文件
  -将复制延迟选项 master_delay设置为0

【使用场景】使当原来的主从关系被破坏之后,从库经过重新初始化后直接连接会报 ERROR 1201的错误,运行reset slave后,重新配置主从连接就可以了;

 

总结:如果是需要删除mysql binlog和relaylog文件的时候,那么通过操作系统的删除或者PURGE命令都可以,但是涉及到mysql主从配置的时候便需要使用RESET MASTER和RESET SLAVE解决问题;

posted @   数据库小白(专注)  阅读(1042)  评论(0编辑  收藏  举报
编辑推荐:
· 没有源码,如何修改代码逻辑?
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
阅读排行:
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· 没有源码,如何修改代码逻辑?
· PowerShell开发游戏 · 打蜜蜂
· 在鹅厂做java开发是什么体验
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战
点击右上角即可分享
微信分享提示