slave中继日志损坏如何处理

Last_SQL_Error: Error initializing relay log position: I/O error reading the header from the binary log

Last_SQL_Error: Error initializing relay log position: Binlog has bad magic number;

It‘s not a binary log file that can be used by  this version of MySQL

手工修复

解决方法:找到同步的binlog和POS点,然后重新做同步,这样就可以有新的中继日值了。

mysql> show slave status\G;

*************************** 1. row ***************************

Master_Log_File: mysql-bin.000010

Read_Master_Log_Pos: 1191

Relay_Log_File: vm02-relay-bin.000005

Relay_Log_Pos: 253

Relay_Master_Log_File: mysql-bin.000010

Slave_IO_Running: Yes

Slave_SQL_Running: No

Replicate_Do_DB:

Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 1593

Last_Error: Error initializing relay log position: I/O error reading the header from the binary log

Skip_Counter: 1

Exec_Master_Log_Pos: 821

Slave_IO_Running :接收master的binlog信息

Master_Log_File

Read_Master_Log_Pos

Slave_SQL_Running:执行写操作

Relay_Master_Log_File

Exec_Master_Log_Pos

以执行写的binlog和POS点为准。

Relay_Master_Log_File: mysql-bin.000010

Exec_Master_Log_Pos: 821

mysql> stop slave;

Query OK, 0 rows affected (0.01 sec)

mysql> CHANGE MASTER TO MASTER_LOG_FILE=‘mysql-bin.000010‘,MASTER_LOG_POS=821;

Query OK, 0 rows affected (0.01 sec)

mysql> start slave;

Query OK, 0 rows affected (0.00 sec)

mysql> show slave status\G;

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.8.22

Master_User: repl

Master_Port: 3306

Connect_Retry: 10

Master_Log_File: mysql-bin.000010

Read_Master_Log_Pos: 1191

Relay_Log_File: vm02-relay-bin.000002

Relay_Log_Pos: 623

Relay_Master_Log_File: mysql-bin.000010

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Replicate_Do_DB:

Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 0

Last_Error:

Skip_Counter: 0

Exec_Master_Log_Pos: 1191

Relay_Log_Space: 778

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: 0

Master_SSL_Verify_Server_Cert: No

Last_IO_Errno: 0

Last_IO_Error:

Last_SQL_Errno: 0

Last_SQL_Error:

如果嫌麻烦,可以在slave的配置文件里加上参数relay_log_recovery=1 就可以了

时间: 2024-08-11 11:02:23

slave中继日志损坏如何处理的相关文章

slave中继日志损坏处理办法

1.slave中继日志损坏 当slave意外宕机时,有可能损坏中继日志relay-log,再次开启同步复制时,就会报错: Last_SQL_Error:Relay log read failure: Could not parse relay log event entry. The possiblereasons are: the master's binary log is corrupted (you can check this byrunning 'mysqlbinlog' on th

MySQL复制应用中继日志解析

1.从一个大神那边得到一张图片,SQL线程应用中继日志流程,下面就实验验证一下 2.验证有PK表情况 在主库创建表结构 CREATE TABLE `table_pk` (`id`  int(11) NOT NULL ,`name`  varchar(20) NOT NULL ,`age`  tinyint NOT NULL ,`sex`  tinyint NOT NULL COMMENT '0,man,1,woman' , PRIMARY KEY (`id`)) ENGINE=InnoDB; 插

大话RAC介质恢复---联机日志损坏

对联机日志的损坏要根据日志状态进行分析,联机日志一般会有Current.Active和Inactive三种状态.Inactive状态不会造成数据丢失.而Active和Current状态的日志一般会造成数据的丢失.根据v$log.status判断受损日志的状态. a.如果是Inactive状态的日志损坏,把该组日志drop就可以.因为每个thread至少要有两组日志,所以在删除前要先添加一组. b.如果是ACTIVE/CURRENT状态,则要进行一下操作: 1.关闭所有实例 2.在受损实例上,启动

海量日志数据如何处理统计?

项目需要做一个dashboard图表网站,展示日志的相关统计信息.这个页面图表很多,一次性会加载出很多数据. 日志表有很多种,都是一些入侵攻击日志.恶意站点访问日志等等,需要统计出当前时间.过去24小时.过去一周被攻击主机个数.恶意站点数(这是其中两个需求)等等数据. 比如被攻击主机个数,需要查多张数据表,然后统计出这个数据. 日志存储在PostgreSQL里面,已经基于时间做了分表,但是每天的的日志量都在100W以上. 写入数据库的模式是随时从其他的系统中写入. 根据这个应用场景,如果设计这个

记一次Ceph日志损坏的分析处理过程

1.故障现象 今天下午看到群友在说一个问题,说ceph的某个osd处于down的状态,我大概整理下他的处理过程 1.查看OSD的状态2.查看日志信息3.启动对应的ceph-osd服务4.检查集群健康状态 2.日志损坏了,如何让osd重新上线 思路:重建日志a.先把/var/lib/ceph/osd/ceph-61/journal 日志删掉b.重建日志ceph-osd -i 61 --mkjournal 原文地址:http://blog.51cto.com/molewan/2088257

重做日志损坏之后的处理

如果遇到没有备份,特别是重做日志文件损坏,可能数据库就打不开了.用户希望挽救一部分数据,如果备份可以进行数据库的不完全恢复,或者是直接清除日志.如果不行只能强制打开市局库.具体如下: ORACLE存在一个内部参数可以尝试恢复_allow_resetlogs_corruption.描述可以通过这个语句查询到. SELECT x.ksppinm NAME,y.ksppstvl VALUE,x.ksppdesc describ FROM SYS.X$ksppi x,SYS.x$Ksppcv y WHE

[网络课摘抄]8.2模拟状态为inactive的日志损坏的恢复实验(完全恢复)

1查看当前日志状态 从这里可以看到我们现在有三组日志,每组日志中只有1个成员.为了演示这个实验,我们为每个组增加1个成员. 2为每组增加组成员 添加后我们验证一下目前各日志成员的状态: 从上面的视图中可以看到我们的日志组成员已经加到了我们的日志组中,增加到的日志成员为INVALID的状态. 3切换3组日志归档 查看此时日志状态: 可以发现此时日志组1和日志组2都是INACTIVE状态. 4删除INACTIVE状态日志 根据前面的确认,我们现在的日志组1和日志组2都是INACTIVE状态,现在我们

[网络课摘抄]8.3模拟状态为active的日志损坏的数据恢复实验(不完全恢复)

1查看当前日志状态 首先不完全恢复是会丢失数据的,由此在当前打开的数据中我们创建一些测试数据,用来验证当我们进行完不完全恢复后该数据是否还存在. 2模拟删除CURRENT状态的日志 3启动数据验证错误信息 可以看到的告警文件里的提示信息: 4对数据库进行不完全恢复 我们使用resetlog后系统提示还不一致,需要进行恢复.下一步我们使用隐藏参数,不要让数据库在打开的时候进行一致性验证. 5关闭隐藏参数

SQL 2005 日志损坏的恢复方法

SQL 在突然停电或者非正常关机下,可能会出现日期文件错误,导致数据库不正常.恢复数据库方法如下 1.数据库服务停掉 将数据库文件备份 例如数据库名为 DTMS 则将 DTMS.mdf 备份出来. 2.开启数据库服务,创建个空的名称为 DTMS的空的同名数据库. 3.关闭数据库服务,将备份的原DMTS.mdf 覆盖到新创建的数据库目录下. 4.在master 下执行下列语句 --修改数据库为紧急状态alter database DTMS set EMERGENCY --将数据库设置为单用户ALT