多級複製的資料不同步問題

昨天剛到公司，開發的同事就找到我，讓我幫他看看某一臺mysql的庫，似乎資料是不同步了。大體的意思是，A地庫中的資料會同步到B地，B地的資料會同步到C地，C地就是開發最終需要訪問的資料，這些業務都是獨立的，但是一部分資料是需要同步的。聽起來比較拗口，實現方式也比較有意思。
採用了下面的方式來實現。列出一部分的架構圖。
圖中的資料分佈在三個區域，可以理解跨越了三個大洲，各個洲有自己的業務，也就是Area1,2,3,我們用區域ABC來替代。由於需要同步一部分資料到北京來。就是區域C通過區域B是作為中轉的。因為區域A到區域C的網路頻寬很差，需要代理中轉，資料庫都是使用了aws
這個圖比較有意思的就是區域A中的備庫，其實在這個架構中既是從庫，同時又是區域B的主庫。但是指同步一部分資料比如A,B

按照這樣的結構圖，目前發現是Area3中的資料沒有同步過來，所以排查的思路也就很清晰了。
首先檢視了Area1中的備庫
mysql> select count(*) from fact_recharge;
+----------+
| count(*) |
+----------+
|  3295669 |
+----------+
1 row in set (6 min 10.75 sec)
但是在Area3中進行查詢，發現差得倒不是很多。
> select count(*)from fact_recharge;
+----------+
| count(*) |
+----------+
|  3294066 |
+----------+
1 row in set (10.80 sec)
如果算作異地的同步，還說明不了問題所在。
繼續登入到Area2進行排查。發現通過終端ssh連線很緩慢。
ssh: connect to host 46.1.22.90 port 22: Connection timed out
好不容易登入上去，趕緊抓取了一個top結果。
發現CPU都是空閒，負載非常低。
top - 18:47:27 up 108 days, 14:45,  2 users,  load average: 0.05, 0.05, 0.00
Tasks: 539 total,   2 running, 537 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.3%us,  0.7%sy,  0.0%ni, 99.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   3932160k total,  3917400k used,    14760k free,   108268k buffers
Swap:  8393920k total,  2587788k used,  5806132k free,   580288k cached
這個時候通過本地的網路去連線緩慢，但是從top來看卻顯然不是系統負載高，因為用的是aws的服務，所以讓運維的同學幫忙去看看。
過了一會，他們反饋，網路問題解決了。
這個時候連線Area2，發現速度就快多了。檢視備庫的狀態，發現沒有問題，於是繼續排查問題，看看Area3的備庫是否正常。
發現結果slave的狀態是Reconnecting,這就意味著Area3備庫還在嘗試做同步，但是似乎還是沒有奏效。
> show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Reconnecting after a failed master event read
                  Master_Host: 46.1.22.90
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000311
          Read_Master_Log_Pos: 598159165
               Relay_Log_File: mysql-relay-bin.001428
                Relay_Log_Pos: 61280882
        Relay_Master_Log_File: binlog.000311
             Slave_IO_Running: Connecting
            Slave_SQL_Running: Yes
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 2003
                Last_IO_Error: error reconnecting to master 'repl@46.1.22.90:3306' - retry-time: 60  retries: 86400       
這個時候檢視最近的IO_Error已經超時，反覆嘗試了多次了。
同時檢視錯誤日誌，發現一段內容，可見確實是出現了網路的問題。
151104 13:56:45 [ERROR] Slave I/O: error reconnecting to master 'repl@46.1.22.90:3306' - retry-time: 60  retries: 86400, Error_code: 2003
這個時候如果確認網路沒有問題之後，可以嘗試stop slave,start slave來重新開啟資料應用
但是還是沒有奏效。使用telnet也沒有反應，還有報錯。
telnet 46.1.22.90 3306
Trying 46.1.22.90...
telnet: connect to address 46.1.22.90: No route to host
telnet: Unable to connect to remote host: No route to host
如果使用ssh的22埠來處理,發現埠是通的。
# telnet 46.1.22.90 22
Trying 46.1.22.90...
Connected to wg_in_46.1.22.90 (46.1.22.90).
Escape character is '^]'.
SSH-2.0-OpenSSH_4.3
Protocol mismatch.
Connection closed by foreign host.
反覆排查，最後發現Area2上的防火牆被開啟了，過濾了一些訪問。重新設定就好了。
所以早上的問題因為網路問題導致了資料的不同步，但是初步的網路問題解決了，不知道怎麼的，又把防火牆設定進行了修改，導致Area3的備庫壓根連不到Area2，所以日誌始終接收不了。
網路問題修復後，也不用設定stop slave,start slave,同步就開始自動更新了。
初始狀態是
> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Queueing master event to the relay log
自動重連後，根據狀態就發現確實開始應用資料日誌了。
> show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
當然同步之後，簡單確認之後就可以告知研發，問題已經得到了解決。
這個問題雖然比較簡單，但是作為MySQL新手還是需要好好了解一下開源中的資料複製實現方式與方法。這個問題的分析中根據業務的架構實現還是需要很熟練的掌握，這樣在問題發生的時候才不至於太手忙腳亂。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-1825164/，如需轉載，請註明出處，否則將追究法律責任。