一不小心把 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
分享到:
相关推荐
2. Relay日志文件问题:从库的复制过程会产生一系列的中继日志(Relay Log)文件,类似于主库的二进制日志,但记录的是从库接收到主库变更后需要在本地执行的SQL语句。案例中的从库积累了大量的relay-bin文件,显示...
这样即使从节点暂时离线,也能在重新连接后从中继日志中恢复缺失的数据更新。此外,通过分离读取日志和执行日志的任务,可以提高系统的整体效率。 ### 实验环境配置 实验手册还提供了一个具体的实验环境配置示例,...
3. **应用差异的中继日志到其他Slave节点**:为了确保所有Slave节点的数据一致性,MHA Manager会将差异的中继日志应用到其他所有Slave节点上。 4. **提升一个新的Master节点**:一旦确定了最新的Slave节点,MHA ...
然后,从服务器将这些日志记录到本地的中继日志中,并由从服务器上的SQL线程执行这些日志中的SQL语句,从而实现数据的同步。 在复制过程中,主要涉及三个线程:dump线程、IO线程和SQL线程。dump线程运行在主服务器...
**应用差异的中继日志(Relay Log)**:将选定Slave上的差异中继日志应用到其他所有Slave。 4. **应用从Master保存的二进制日志事件**:应用之前保存的二进制日志到新的Master上。 5. **提升一个Slave为新的...
主库上的二进制转储线程读取主库的二进制日志事件,并发送给从库的I/O线程,I/O线程将事件记录到中继日志。 3. 从库的SQL线程执行最后一步,从中继日志中读取事件并在从库上执行,实现从库数据的更新。 为了实现...
14. 中继日志文件:中继日志用于复制,记录主服务器的二进制日志事件,便于从服务器重放。当遇到问题时,可以通过调整中继日志来解决。 15. 显示复制线程状态:在MySQL中,可以使用`SHOW SLAVE STATUS\G`命令查看...
- 从服务器复制主服务器的binary log events到中继日志(relay log)。 - 从服务器的SQL线程读取并重做中继日志中的事件,同步数据到从服务器。 3. **MySQL主从复制的优点**: - 故障切换:主服务器故障时,能快速...
3.应用差异的中继日志到其他Slave;4.应用从Master保存的二进制日志事件;5.提升一个Slave为新的Master;6.使其他的Slave连接新的Master进行复制。 MHA的组成包括Manager工具包和Node工具包。Manager工具包包含检查...
- 应用差异的中继日志(relay log)到其他从服务器,以保持它们的数据一致。 - 将从主服务器保存的二进制日志事件应用到其他从服务器,确保所有节点的数据一致性。 - 提升一个具有最新数据的从服务器为新的主服务器...
从服务器通过 I/O 线程连接主服务器,读取并保存这些日志到中继日志(Relay log),然后由 SQL 线程解析并执行日志中的SQL语句,同步更新数据。 2. **安装环境**:至少需要两台运行 CentOS 7.0 的64位服务器。在...
relay-log = /usr/local/mysql/data1/relay-bin # 设置中继日志的位置 relay-log-index = relay-bin.index # 中继日志索引文件 replicate-do-table = db1.table1, db2.table2 # 可选,指定要复制的特定表 ``` 然后...
3. **I/O线程**:从库的I/O线程通过网络连接到主库,读取binlog事件,并将它们存储到中继日志(relay log)中。主库上的binlog事件是按顺序读取的。 4. **SQL线程**:从库的SQL线程读取中继日志中的事件,并在本地...
14. **中继日志文件**:中继日志记录了从主服务器接收到的更改,用于在从服务器上重放,其结构不同于二进制日志,可以自定义路径,并在I/O线程启动时创建。 15. **显示复制线程状态**:使用`SHOW SLAVE STATUS\G`...
14. **中继日志文件**:在MySQL复制中,中继日志记录了从主库接收到的事件,便于从库重放,其结构与二进制日志不同,路径可以自定义。 15. **显示复制线程状态**:使用`SHOW SLAVE STATUS\G`命令可以查看复制线程的...
1. **I/O线程(从库)**:负责从主库拉取二进制日志(Binary Log)并写入中继日志(Relay Log)。 2. **SQL线程(从库)**:负责读取中继日志并执行其中记录的操作,确保从库的数据与主库保持一致。 3. **Log Dump线程...
在MySQL的主从复制中,主库的更改被记录到二进制日志(binlog),然后从库通过IO线程从主库获取这些日志并应用到自己的中继日志(relay log)。SQL线程则读取中继日志并执行相应的SQL语句,使从库与主库保持同步。 ...
否则,从服务器可能会尝试从中继日志中恢复复制,而这些日志可能已经过时或者不完整。 在配置MySQL主从服务时,还需要注意以下几点: 1. **设置正确的复制用户和权限**:主服务器需要一个特定的复制用户,该用户在...
4.2 特殊情况:slave的中继日志relay-log损坏 116 4.3 人为失误 118 4.4 避免在master上执行大事务 119 4.5 slave_exec_mode参数可自动处理同步复制错误 120 4.6 如何验证主从数据一致 121 4.7 binlog_ignore_...
特殊情况下,如Slave的中继日志损坏(relay-bin),可能导致同步停止,错误信息可能显示为`Error initializing relay log position... Binlog has bad magic number`。此时,可能需要恢复中继日志或者重新同步。 ...