MySQL級聯複製中的資料同步（第二篇）

今天解決了兩個蠻有意思的MySQL問題，簡單分享出來。

首先是昨天說的級聯複製的情況，因為架構做了調整，我們要刪除其中的一箇中繼節點（新加坡節點），而直接使用北京節點去連線北美的節點。

更多的資訊可以參考。

MySQL級聯複製中的資料同步(r11筆記第20天)

大體的架構方式如下：

如此一來，為了避免重建從庫，而且沒有GTID的情況下，我們可以統一規劃一下偏移量，平滑遷移。

實現後的架構圖如下：

看起來還是比較簡單，但是偏移量真是一個比較瑣碎細緻的活兒。在此也感謝我的同事程振，我們一起討論了實現的方式和細節。

大體來說，目前的北京節點的延遲較大，所以大體的思路就是停止新加坡節點的slave，（當然要保證slave的read_master_log_pos和Exec_Master_Log_Pos要追平）也可以直接停止io_thread(stop slave io_thread),或者stop slave，讓北京節點去追平GAP，然後直接平滑切換到北美的節點上。

北京節點（slave）和新加坡節點（master）的偏移量情況如下：

北京(slave)	新加坡（master)
>show slave  status\G	> show master  status\G
Master_Log_File:  binlog.000408	File: binlog.000408
Read_Master_Log_Pos:  129590180	Position: 675358376
Relay_Log_File:  mysql-relay-bin.002263	Binlog_Do_DB:
Relay_Log_Pos:  25551626	Binlog_Ignore_DB:
Relay_Master_Log_File:  binlog.000408

北京節點要去新加坡節點讀取資料變化，得追平GAP，可以看出延遲已經很大了。

這裡有一點很容易弄混淆，那就是新加坡節點（slave）的偏移量。

新加坡（slave)

> show  slave status\G

Master_Log_File:  binlog.000621

Read_Master_Log_Pos:  287660027

Relay_Log_File:  mysql-relay-bin.002070

Relay_Log_Pos:  287660170

Relay_Master_Log_File:  binlog.000621

北京節點要追平的偏移量是675358376而非287660027

過了些時間，總算是追平了，和預期的一樣，是追平到了675358376。

資料如下：

北京(slave)	新加坡（master)
>show slave status\G	> show master  status\G
Master_Log_File:  binlog.000408	File: binlog.000408
Read_Master_Log_Pos:  675358376	Position: 675358376
Relay_Log_File:  mysql-relay-bin.002281	Binlog_Do_DB:
Relay_Log_Pos:  414747263	Binlog_Ignore_DB:
Relay_Master_Log_File:  binlog.000408

這個時候問題就來了，北美的slave節點已經接受資料變化，偏移量肯定在增長，而這個時候一個重要的參考依舊就是新加坡slave節點的偏移量資訊。從下面可以看出偏移量已經有了重大的差別，如果沒有參考基礎就無從開始設定。

新加坡（slave)	北美從庫（master)
> show  slave status\G	> show master  status\G
Master_Log_File:  binlog.000621	File: binlog.000621
Read_Master_Log_Pos:  287660027	Position: 344035385
Relay_Log_File:  mysql-relay-bin.002070	Binlog_Do_DB:
Relay_Log_Pos:  287660170	Binlog_Ignore_DB:
Relay_Master_Log_File:  binlog.000621

接下來就是北京節點的重頭戲了。開始使用change master來修改

stop slave;
CHANGE MASTER TO  MASTER_HOST='xxxx',
 MASTER_USER='repl_new',        
 MASTER_PASSWORD='xxxx',    
 MASTER_PORT=3306,        
 master_log_file='binlog.000621',
 master_log_pos=287660027；
start slave;

如上的兩個重要引數就取自新加坡的從節點資訊。

然後start slave之後，就可以看到偏移量開始大幅度提升。

Read_Master_Log_Pos: 288885733

很快就追平了北美從庫（master）的偏移量

檢視北美從庫（master）的資訊

北美slave節點

> show master status\G

File: binlog.000621

Position: 348627763

Binlog_Do_DB:

Binlog_Ignore_DB:

如此一來一個看似複雜的平滑遷移過程就完成了。昨天我蠻有深意的給出下面的一個級聯複製圖.

整個過程操作順利完成之後，也讓我對GTID這個很不錯的特性更加渴望。手工來分析判斷，真是很讓人費神。