Just to clarify, there are three sets of file/position coordinates in SHOW SLAVE STATUS:

1) The position, ON THE MASTER, from which the I/O thread is reading:Master_Log_File/Read_Master_Log_Pos. -----相對于主庫,從庫讀取主庫的二進制日志的位置,是IO線程

2) The position, IN THE RELAY LOGS, at which the SQL thread is executing:Relay_Log_File/Relay_Log_Pos?----相對于從庫,是從庫的sql線程執(zhí)行到的位置

3) The position, ON THE MASTER, at which the SQL thread is executing:Relay_Master_Log_File/Exec_Master_Log_Pos?----相對于主庫,是從庫的sql線程執(zhí)行到的位置

Numbers 2) and 3) are the same thing, but one is on the slave and the other is on the master.

mysql >?show slave status \G

Master_Log_File:?mysql-bin-m.000329

Read_Master_Log_Pos:?863952156　----上面二行代表IO線程,相對于主庫的二進制文件

?

Relay_Log_File:?mysql-relay.003990

Relay_Log_Pos:?25077069　----上面二行代表了sql線程,相對于從庫的中繼日志文件

Relay_Master_Log_File:?mysql-bin-m.000329

.....

Exec_Master_Log_Pos:?863936961---上面二行代表了sql線程,相對主庫

(為了方便演示,我把上面這行提前了.)

Relay_Log_Space:?25092264---當前relay-log文件的大小

Slave_IO_Running:?Yes

Slave_SQL_Running:?Yes

從上面可以看到,read_master_log_pos?始終會大于exec_master_log_pos的值(也有可能相等):因為一個值是代表io線程,一個值代表sql線程;sql線程肯定在io線程之后.(當然,io線程和sql線程要讀寫同一個文件,否則比較就失去意義了) .

在binlog中,Xid代表了提交的事務號.現(xiàn)在我們分別去主從庫看看,驗證一下,在主庫的mysql-bin-m.000329文件的863936961處是否與從庫的mysql-relay.003990文件的25077069處有相同的sql語句.

先看主庫的binlog:

# at?863936961

#100111 20:11:39 server id 115000 end_log_pos?863937234?Query?thread_id=515886?exec_time=0 error_code=0

use mall00/*!*/;

UPDATE mall00.t_item_sid88 SET item_end_time = 1263816699, item_is_online = 1, item_status = 1 WHERE iid IN (94322390, 94322428, 94322452, 94322473, 94322506, 94322532, 94322604, 94322641, 94322670, 94322706)/*!*/;

# at?863937234

#100111 20:11:39 server id 115000 end_log_pos?863937261?Xid?= 1225244590

COMMIT/*!*/;

# at 863937261

#100111 20:11:39 server id 115000 end_log_pos 863937457?Query?thread_id=515886?exec_time=0error_code=0

SET TIMESTAMP=1263211899/*!*/;

再看從庫的relaylog:

# at 25077069

#100111 20:11:39 server id 115000 end_log_pos863937234?Query?thread_id=515886?exec_time=0 error_code=0

use mall00/*!*/;

UPDATE mall00.t_item_sid88 SET item_end_time = 1263816699, item_is_online = 1, item_status = 1 WHERE iid IN (94322390, 94322428, 94322452, 94322473, 94322506, 94322532, 94322604, 94322641, 94322670, 94322706)/*!*/;

# at 25077342

#100111 20:11:39 server id 115000 end_log_pos?863937261?Xid?= 1225244590

COMMIT/*!*/;

從上面的日志中,可以看到binlog與realy-log的內(nèi)容是相同的,除了開頭的at位置處的偏移量.因為偏移量始終是相對于文件自身來說,主庫上相對于binlog本身,從庫上相對于relay-log本身.還可以看到,在每個query語句過后,都有一個Xid?的event,提交該事務,也表明在mysql中是自動提交的,每條語句執(zhí)行完畢后,系統(tǒng)都自動提交了.那么在基于行的復制中,可能會看到多條binlog?語句才對應一次commit,自然說明這是基于行的復制.

還有一點,就是主庫和從庫的對應位置的event大小是相同的,例如上面的:

25077342-25077069(從庫上event大小) ?= ?863937234-863936961(主庫上event大小)

否則,說明從庫的relay-log丟失了,有可能是操作系統(tǒng)緩存丟失,也可能是mysql?異常crash導致relay-log buffer中的數(shù)據(jù)丟失.那么這時候就需要重設主從同步了.

總結

以上是生活随笔為你收集整理的show slave status\G中的Read_Master_Log_Pos和Relay_Log_Pos的(大小)关系的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。