多級複製的資料不同步問題
昨天剛到公司,開發的同事就找到我,讓我幫他看看某一臺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新手還是需要好好了解一下開源中的資料複製實現方式與方法。這個問題的分析中根據業務的架構實現還是需要很熟練的掌握,這樣在問題發生的時候才不至於太手忙腳亂。
採用了下面的方式來實現。列出一部分的架構圖。
圖中的資料分佈在三個區域,可以理解跨越了三個大洲,各個洲有自己的業務,也就是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/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- MySQL級聯複製的同步問題(一)MySql
- DM7資料複製之資料庫級複製資料庫
- mysql的主從複製資料延遲問題MySql
- DM7資料複製之模式級複製模式
- Oracle資料不同步的問題分析和解決思路Oracle
- MySQL複製的奇怪問題MySql
- Mysql分散式部署 - 多級複製MySql分散式
- 資料庫檔案複製問題和解決辦法資料庫
- 【RMAN】使用RMAN duplicate複製同機資料庫遇到的問題資料庫
- SEO如何減少網站複製重複內容過多的問題?網站
- 資料檢視的重複問題
- Redis的資料複製Redis
- 複製指定源位置的多級資料夾下所有檔案到指定目標位置
- JS中的陣列複製問題JS陣列
- Go指標複製問題Go指標
- 資料共享(淺複製)與資料獨立(深複製)
- 資料庫複製(一)–複製介紹資料庫
- 多個資料來源的問題
- MySQL級聯複製中的資料同步(第二篇)MySql
- 資料複製_Stream
- 資料庫複製資料庫
- 複製資料庫資料庫
- MySQL級聯複製中資料同步MySql
- JavaScript 深複製的迴圈引用問題JavaScript
- java複製檔案時遇到的問題Java
- 解決csdn登陸複製的問題
- Solr資料不同步Solr
- 使用檔案複製的方式進行資料庫版本升級資料庫
- sql server2008資料庫複製實現資料同步常見問題SQLServer資料庫
- Day 7.5 資料型別總結 + 複製 淺複製 深複製資料型別
- 如何解決MySQL 主從複製資料不一致問題MySql
- 多資料庫設計問題資料庫
- mysql 資料表的複製案例MySql
- AD資料複製需要的埠
- RMAN的活動資料庫複製資料庫
- 資料複製的併發控制
- rman管理的複製資料庫資料庫
- 複製資料庫的報錯資料庫