删除了slave 的 中继日志后的恢复

本文详细记录了一次MySQL主从复制过程中从机中继日志被误删除后的故障现象及恢复过程。通过重新获取主服务器上的二进制日志,并定位到缺失SQL的起始位置,最终成功恢复了数据同步。

一不小心把 slave 的中继日志给删掉了。最后也给我恢复了。所以继续模拟一下过程。整理记录

一 master 一 slave 。 master 是win slave 是 FB 系统。。其实和系统无关。

目前同步正常。。

先在slave 中把中继日志删掉

beihai365# rm beihai365-relay-bin.00000*

一共有两个中继日志。 中继日志是。slave i/o 线程 生成的一个 master 更新操作的日志 在 slave 本地。这样就可以保证 主从同步

无论slave 是否能及时消化掉master 的更新语句,反正 slave i/o 都给你copy 到本地了。你自己慢慢消化去~~

接下来,我继续在master 那里插入N条记录。。这会 slave 处于出错状态也就stop 了。那么 slave i/o 也就无法从master 那里获取到 binlog 生成本地中继日志。从而导致slave 丢失了现在更新的N条记录

mysql> insert into rep1_test values('5','1');
Query OK, 1 row affected (0.06 sec)

mysql> insert into rep1_test values('5','2');
Query OK, 1 row affected (0.05 sec)

mysql> insert into rep1_test values('5','3');
Query OK, 1 row affected (0.05 sec)

mysql> insert into rep1_test values('5','4');
Query OK, 1 row affected (0.06 sec)

mysql> insert into rep1_test values('5','5');
Query OK, 1 row affected (0.05 sec)

然后在 从哪里看 show slave status \G; 里面的 LAST_Error

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.

显示了错误信息。我们在看下是否同步了数据

mysql> select * from rep1_test;

| w | j2 |
| w | j3 |
| w | j4 |
| w | j5 |
| w | j6 |
+------+------+
123 rows in set (0.00 sec)

数据无法更新。

虽然这样,但

show slave status 和 show master status 里面显示的

Master_Log_File: mysql-bin.000006
Read_Master_Log_Pos: 2524

任然是一至的。

因为只是 slave sql 线程停掉了而已。 i/o 线程任然和 master 联系。

OK。那现在咋办呢。已经丢失了几天SQL了。 我们知道 slave 端只有中继日志是保存那些更新sql的。但给我删掉了。所以唯一办法就是从master 那里找了, binlog 嘛。 只要没删除binlog 。master 做啥都是给记录下的。

通过FTP 。我在slave 里拿到了 binlog 。

拿之前记得,要先把给读锁了,不给更新binlog先

mysql> flush tables with read lock;

别拿错了 : File: mysql-bin.000006

beihai365# mysqlbinlog ./mysql-bbin | less

打开了binlog 日志。然后要做的就是找到缺少SQL的起点位置。

# at 1889
#100204 16:56:07 server id 2 end_log_pos 100 Query thread_id=4 exec_time=0 error_code=0
SET TIMESTAMP=1265273767/*!*/;
insert into rep1_test values('5','1')

看到。从1889节点开始,就是我们丢失的SQL记录。OK补回来就行

beihai365# mysqlbinlog --start-position="1889" ./mysql-bbin | mysql -u root -p

| w | jj |
| w | j1 |
| w | j2 |
| w | j3 |
| w | j4 |
| w | j5 |
| w | j6 |
| 5 | 1 |
| 5 | 2 |
| 5 | 3 |
| 5 | 4 |
| 5 | 5 |
+------+------+
128 rows in set (0.00 sec)

OK补回来了。

不过别忘了。slave 现在还在当J状态。 要弄回来才行。

只要重启一下slave 的客户端的mysql 就行了。

然后再确定一下:

Master_Log_File: mysql-bin.000007
Read_Master_Log_Pos: 98
Relay_Log_File: beihai365-relay-bin.000005
Relay_Log_Pos: 244
Relay_Master_Log_File: mysql-bin.000007
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

然后在看下 master 的 master_log_file 和 read_master_log_pos 是否对得上。

再看下 是否有两个yes 。有就行了。OK

评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值