程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> MySQL綜合教程 >> Mysql半同步復制原理及問題排查,mysql排查

Mysql半同步復制原理及問題排查,mysql排查

編輯:MySQL綜合教程

Mysql半同步復制原理及問題排查,mysql排查


 

mysql半同步復制和異步復制的差別如上述架構圖所示:在mysql異步復制的情況下,Mysql Master Server將自己的Binary Log通過復制線程傳輸出去以後,Mysql Master Sever就自動返回數據給客戶端,而不管slave上是否接受到了這個二進制日志。在半同步復制的架構下,當master在將自己binlog發給slave上的時候,要確保slave已經接受到了這個二進制日志以後,才會返回數據給客戶端。對比兩種架構:異步復制對於用戶來說,可以確保得到快速的響應結構,但是不能確保二進制日志確實到達了slave上;半同步復制對於客戶的請求響應稍微慢點,但是他可以保證二進制日志的完整性。

1.問題背景

默認情況下,線上的mysql復制都是異步復制,因此在極端情況下,主備切換時,會有一定的概率備庫比主庫數據少,因此切換後,我們會通過工具進行回滾回補,確保數據不丟失。半同步復制則要求主庫執行每一個事務,都要求至少一個備庫成功接收後,才真正執行完成,因此可以保持主備庫的強一致性。為了確保主備庫數據強一致,減少數據丟失,嘗試在生產環境中開啟mysql的復制的半同步(semi-sync)特性。實際操作過程中,發現大部分實例半同步都可以正常運行,但有少部分實例始終開不起來(只能以普通復制方式運行),更奇葩的是同一個主機的兩個實例,一個能開啟,一個不能。最終定位的問題也很簡單,但排查出來還是花了一番功夫,下文將描述整個問題的排查過程。

2.半同步復制原理

mysql的主備庫通過binlog日志保持一致,主庫本地執行完事務,binlog日志落盤後即返回給用戶;備庫通過拉取主庫binlog日志來同步主庫的操作。默認情況下,主庫與備庫並沒有嚴格的同步,因此存在一定的概率備庫與主庫的數據是不對等的。半同步特性的出現,就是為了保證在任何時刻主備數據一致的問題。相對於異步復制,半同步復制要求執行的每一個事務,都要求至少有一個備庫成功接收後,才返回給用戶。實現原理也很簡單,主庫本地執行完畢後,等待備庫的響應消息(包含最新備庫接收到的binlog(file,pos)),接收到備庫響應消息後,再返回給用戶,這樣一個事務才算真正完成。在主庫實例上,有一個專門的線程(ack_receiver)接收備庫的響應消息,並以通知機制告知主庫備庫已經接收的日志,可以繼續執行。有關半同步的具體實現,可以參考另外一篇文章,mysql半同步(semi-sync)源碼實現。

3.問題分析

前面簡單介紹了半同步復制的原理,現在來看看具體問題。在主備庫打開半同步開關後,問題實例的狀態變量"Rpl_semi_sync_master_status"始終是OFF,表示復制一直運行在普通復制的狀態。

(1).修改rpl_semi_sync_master_timeout參數。

半同步復制參數中有一個rpl_semi_sync_master_timeout參數,用以控制主庫等待備庫響應消息的時間,如果超過該值,則認為備庫一直沒有收到(備庫可能掛了,也可能備庫執行很慢,較主庫相差很遠),這個時候復制會切換為普通復制,避免主庫的執行事務長時間等待。線上這個值默認是50ms,簡單想是不是這個值太小了,遂將其改到10s,但問題依然不解。

(2).打印日志

排查問題最簡單最笨的方法就是打日志,看看到底是哪個環節出了問題。主庫和備庫分別有rpl_semi_sync_master_trace_level和rpl_semi_sync_slave_trace_level參數來控制半同步復制打印日志。將兩個參數值設置為80(64+16),記錄詳細日志信息,以及進出的函數調用。

master:

2016-01-04 18:00:30 13212 [Note] ReplSemiSyncMaster::updateSyncHeader: server(-1721062019), (mysql-bin.000006, 500717950) sync(1), repl(1)
2016-01-04 18:00:40 13212 [Warning] Timeout waiting for reply of binlog (file: mysql-bin.000006, pos: 500717950), semi-sync up to file , position 0.
2016-01-04 18:00:40 13212 [Note] Semi-sync replication switched OFF.

slave:

2016-01-04 18:00:30 38932 [Note] ---> ReplSemiSyncSlave::slaveReply enter
2016-01-04 18:00:30 38932 [Note] ReplSemiSyncSlave::slaveReply: reply (mysql-bin.000006, 500717950)
2016-01-04 18:00:30 38932 [Note] <--- ReplSemiSyncSlave::slaveReply exit (0)

從master日志可以看到在2016-01-04 18:00:30時,主庫設置了半同步標記,並開始等待備庫的響應,等待10s後,仍然沒有收到響應,則認為超時,遂將半同步模式關閉,切換為普通模式。但從slave日志來看,在2016-01-04 18:00:30已經將(mysql-bin.000006, 500717950)發送給主庫,表示已經收到該日志。這就說明,master日志已經打了semi-sync標,slave收到了日志,並且也回了包,master也確實等了10s,就是沒有收到包,所以就切換為普通復制。現在問題就變成了,為什麼master沒有收到?

(3)select函數

前面提到了,主庫實例上有一個專門接收響應包的線程(ack_receiver),它通過select函數監聽socket,發現有slave的響應消息後,讀取消息,通知工作線程可以繼續執行。那麼問題是不是出現在select函數上面?因為select是一個系統調用,一直沒有懷疑,但已經跟到這裡來了,那就得看看。與select函數相關的有幾個重要的宏定義和說明。主要實現在/usr/include/bits/typesizes.h,/usr/include/bits/select.h和/usr/include/sys/select.h這三個文件中。

FD_ZERO(fd_set *fdset):清空fdset與所有文件句柄的聯系。FD_SET(int fd, fd_set *fdset):建立文件句柄fd與fdset的聯系。FD_CLR(int fd, fd_set *fdset):清除文件句柄fd與fdset的聯系。FD_ISSET(int fd, fd_set *fdset):檢查fdset聯系的文件句柄fd是否可讀寫,當>0表示可讀寫。

array
{
__fd_mask __fds_bits[__FD_SETSIZE / __NFDBITS]; 1024/64=16 (long int)
}fd_set
#define __FD_SET_SIZE 1024
typedef long int __fd_mask; //8個字節
#define __NFDBITS (8 * (int) sizeof (__fd_mask)) // 64位
#define __FDMASK(d) ((__fd_mask) 1 << ((d) % __NFDBITS)) //fd%64=N,則在第N位設置為1
#define __FDELT(d) ((d) / __NFDBITS) //表示在第幾個long int
#define __FDS_BITS(set) ((set)->__fds_bits) 
#define __FD_SET(d, set) (__FDS_BITS (set)[__FDELT (d)] |= __FDMASK (d))
#define __FD_CLR(d, set) (__FDS_BITS (set)[__FDELT (d)] &= ~__FDMASK (d))
#define __FD_ISSET(d, set) \
((__FDS_BITS (set)[__FDELT (d)] & __FDMASK (d)) != 0) 

通過FD_SET可以設置我們想要監聽的句柄,句柄信息存儲在fd_set位數組中,數組元素的個數由__FD_SETSIZE/64決定,對於__FD_SETSIZE=1024而言,整個數組只有16個long int。每個句柄占有一個位,就是1024個位,可以存儲1024個句柄。假設句柄值為138,那麼138/64=2,138%64=10,那麼這個句柄在數組的標示在第2個long int的第10位置1。那麼如果句柄值超出1024呢,這裡不就溢出了?我仔細撸了撸代碼,發現根本就沒有容錯判斷,如果句柄值超過1024就一定會溢出。由於select函數是遍歷數組中的每個位,然後去判斷該句柄是否可讀可寫,因此對於超過1024的句柄,永遠也不會去判斷,因此主庫永遠不知道備庫是否發送了響應包。

(4)驗證

上面只是理論分析,如果實際運行的實例句柄確實是超過了1024,那麼問題就定位到了。

1.得到mysql進程mysql-pid

ps –aux | grep mysqld | grep port

2.gdb attach到該進程

gdb –p mysql-pid

3.找到ack_receive線程,並切換

info thread
thread thread_id

4.打印socket的值,這裡fd值為2344。

(5)如何解

我們看到了由於__FD_SETSIZE的定義,一般是1024,導致select函數最多只能監聽1024個句柄,並且最大句柄值不超過1024。第一個方法是調大該參數,但這種方法需要重新編譯linux內核。而且由於select機制,每次都需要遍歷 的每一位來判斷句柄上是否有消息到來,因此如果設置很大,將導致效率非常低。select是一種比較老的IO復用機制,比較先進的poll,epoll都有類似的功能,並且更強大,也沒有句柄總數和最大句柄的限制。有關select,poll,epoll等機制,大家可以去網上查資料,這裡不展開討論。

(6)官方版本

看了最新oracle官方版本git上5.7的源代碼,這塊也是用select來實現的,所以也存在類似的問題。當然,由於句柄號有復用機制,當實例上連接數很少,或者長連接不多時,不容易出現fd>1024的情況,所以這個bug不是很容易出現,但問題是普遍存在的。

(7)問題延生

問題定位後,另外一個問題還困擾我了半天。因為mysql內核中有監聽的部分有3塊,1是監聽端口的select,2是線程池的監聽epoll,3是半同步的select監聽。slave binlog dump的線程就是普通的工作線程,而工作線程的socket會受epoll的監聽,這樣一來,binlog dump的socket會同時受半同步的select監聽和線程池的epoll監聽,這不亂了嗎?後來仔細看了看代碼,才發現線程池的epoll監聽采用的是EPOLLONESHOT模式,每次接收消息後會解綁,需要重新注冊,因此不會出現同一個句柄被兩種監聽機制同時監聽的情況。

到此,排查問題過程就結束了,結論是比較簡單的,但定位這個問題確實花費了一些功夫。由於select一種比較通用的多路IO復用機制,因此有用到select函數的童鞋,可能要注意下它的限制。

您可能感興趣的文章:

  • mysql中復制表結構的方法小結
  • MySQL復制表結構和內容到另一張表中的SQL語句
  • MySQL中表復制:create table like 與 create table as select
  • 深入解析半同步與異步的MySQL主從復制配置

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved