1. 程式人生 > >TR2021_0000偶發資料庫連線異常問題排查

TR2021_0000偶發資料庫連線異常問題排查

##【問題描述】 資料庫連線異常是很難排查的一類問題。因為它牽涉到應用端,網路層和伺服器端。任何一個元件異常,都會導致資料庫連線失敗。開發遇到資料庫連線不上的問題,都會第一時間找DBA來協助檢視,DBA除了需要懂得資料庫以外,還需要對應用,對網路有所瞭解,知道在哪裡看應用程式的日誌,以及看網路交換機效能指標,才能清晰的定位問題。下面是一個數據庫偶發連線不上的例子: 步驟|分析 ----------------|------------ S(主觀) |某應用程式,有40臺左右應用伺服器,時不時的會報資料庫連線異常。報錯後迅速自愈。報錯內容為: Communications link failure. The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server. 報錯頻率大概每天有四五次左右。應用是新上的。 O(客觀) |MySQL版本為5.7.23, 服務端作業系統版本為7.6.1810. 瞬間有20多臺應用伺服器都報這個錯誤。馬上自愈。應用部署在同城兩個機房,每個機房都有報錯。每天總會出現四五次。 A(評估) |同時有20多臺應用伺服器報錯,而且分佈在兩個機房。問題應該出在服務端。 P(計劃) |建議在服務端抓網路包,進一步定位問題。並進一步檢視服務端的效能計數器。 ##【問題分析】 通過問題的初步評估,故障應該是出現在服務端,也有可能是服務端的網路。我們隨之查看了服務端MySQL的各項效能指標,在故障期間,效能指標都是正常的。在伺服器端單邊抓包,抓到的內容如下: 時間戳 |源 |目標 |Info -----|----|----|------ 2021-01-08 17:15:05.667331 |應用 |DB |48184 -> 3309 [SYN] 2021-01-08 17:15:06.717752 |應用 |DB |[TCP Retransmission] 48144 -> 3309 [SYN] 2021-01-08 17:15:06.717762 |DB |應用 |3309 -> 48184 [SYN, ACK] 2021-01-08 17:15:06.719101 |應用 |DB |48144 -> 3309 [RST] 上述網路包解讀如下: * 17:15:05.66 應用伺服器(埠號48184)向DB伺服器(埠號3309) 傳送一個SYN請求。 * 過了1.05秒左右,應用伺服器再次向DB伺服器傳送SYN請求 * 在17:15:06.71的時候,DB伺服器響應了客戶端的請求,傳送了確認包ACK * 在17:15:06.71的時候,應用伺服器傳送了連線重置的請求,要求中止連線。 從上述的特徵來看,連線重置是客戶端發起的。但這個情有可原,因為DB端超過1.05秒還沒有響應客戶端的SYN請求,客戶端不耐煩,直接中止了連線。而這個1.05秒,恰好是開發在客戶端的Tomcat JDBC connect Timeout連線超時設定。所以問題進一步縮小到服務端的TCP/IP連線層面。 我們用下面的命令,來監控服務端丟包情況: ``` # netstat -s | egrep "listen|LISTEN" 5268 times the listen queue of a socket overflowed 5268 SYNs to LISTEN sockets dropped ``` 發現確實在服務端丟包,而且出現的頻率和客戶端報錯的時間吻合。每次應用程式報錯,服務端的drop數也會隨之增加。 對於Linux伺服器端,server端建連過程需要兩個佇列,一個是SYN queue,一個是accept queue。前者叫半開連線(或者半連線)佇列,後者叫全連線佇列。從伺服器角度看,建立TCP連線的過程如下圖: ![](https://img2020.cnblogs.com/blog/1247138/202101/1247138-20210112175401038-1977430402.png) SYNs to LISTEN sockets dropped的丟包型別,說明在半連線隊列出現了問題。 分析發現,該例項部署的DB數量比較多,且對應的應用伺服器數量也比較多,應用會有短時間建立大量連線的情況,導致半連線佇列溢位。半連線佇列的大小取決於linux的引數tcp_max_syn_backlog、somaxconn和應用程式呼叫Listen方法時的backlog引數。 關於tcp_max_syn_backlog、somaxconn與半連線佇列的分析,網上的資料非常多,這裡不展開細節分析,我們可以簡單地認為: ``` 全連線佇列長度 = min(somaxconn, backlog) 半連線佇列長度 = min(應用呼叫Listen的backlog,somaxconn,tcp_max_syn_backlog) ``` 我們可以用下面的命令,來監控全連線的佇列大小,發現值為128,可以說明我們somaxconn值或者mysqld的backlog設定比較小,從而導致半連線佇列也比較小。 ``` #ss -ntlp | more LISTEN 0 128 :::3309 :::* ``` 對於這次的案例,我們先調大了linux作業系統的兩個引數。 ``` #echo 'net.ipv4.tcp_max_syn_backlog=65535' >> /etc/sysctl.conf #echo 'net.core.somaxconn=65535' >> /etc/sysctl.conf #sysctl –p ``` 接下來,我們分析下mysqld呼叫Listen方法時,backlog相關的程式碼。 MYSQLD在啟動時會呼叫network_init的方法,會傳入back_log引數,程式碼如下:

static bool network_init(void)
{
  if (opt_bootstrap)
    return false;
  set_ports();
  if (!opt_disable_networking || unix_sock_name != "")
  {
    std::string const bind_addr_str(my_bind_addr_str ? my_bind_addr_str : "");

    Mysqld_socket_listener *mysqld_socket_listener=
      new (std::nothrow) Mysqld_socket_listener(bind_addr_str,
                                                mysqld_port, back_log,
                                                mysqld_port_timeout,
                                                unix_sock_name);
    if (mysqld_socket_listener == NULL)
      return true;
    mysqld_socket_acceptor=
      new (std::nothrow) Connection_acceptor
創建出mysqld_socket_listener物件後,傳遞給Connection_acceptor後,最終會呼叫作業系統的Listen方法,程式碼如下:

static inline int inline_mysql_socket_listen
(
MYSQL_SOCKET mysql_socket, int backlog)
{
  int result;
  if (mysql_socket.m_psi != NULL)
  {
    /* Instrumentation start */
    PSI_socket_locker *locker;
    PSI_socket_locker_state state;
    locker= PSI_SOCKET_CALL(start_socket_wait)
      (&state, mysql_socket.m_psi, PSI_SOCKET_CONNECT, (size_t)0, src_file, src_line);

    /* Instrumented code */
    result= listen(mysql_socket.fd, backlog);
對於back_log值的確定,mysql有2種處理方式。 一種是情況預設情況,會設定50 + (max_connections / 5)且不超過900。具體的程式碼如下:

int init_common_variables()
{
  umask(((~my_umask) & 0666));
  my_decimal_set_zero(&decimal_zero); // set decimal_zero constant;
  tzset();      // Set tzname

  /* Fix back_log */
  if (back_log == 0 && (back_log= 50 + max_connections / 5) > 900)
      back_log= 900;
}
另外一種情況,也可以手動設定mysqld的啟動引數。

static Sys_var_ulong Sys_back_log(
       "back_log", "The number of outstanding connection requests "
       "MySQL can have. This comes into play when the main MySQL thread "
       "gets very many connection requests in a very short time",
       READ_ONLY GLOBAL_VAR(back_log), CMD_LINE(REQUIRED_ARG),
       VALID_RANGE(0, 65535), DEFAULT(0), BLOCK_SIZE(1));
為了保持伺服器配置的統一化,我們這次調整了mysqld的啟動back-log=2048,調整完成後,重啟mysql服務,觀察了2天,再未發生半連線丟包的問題。 ##【問題總結】 全連線佇列、半連線佇列溢位這種問題很容易發生,但可能報錯具有偶然性,很容易被忽視,linux版本的不斷進化,TCP的設計也越來越複雜,作為一名合格的DBA,也需要對網路有所瞭解,才能更好地定位和處理日常的運維