TR2021_0000偶發資料庫連接例外問題排查

【問題描述】

資料庫連接例外是很難排查的一類問題，因為它牽涉到應用端，網路層和服務器端，任何一個組件例外，都會導致資料庫連接失敗，開發遇到資料庫連接不上的問題，都會第一時間找DBA來協助查看，DBA除了需要懂得資料庫以外，還需要對應用，對網路有所了解，知道在哪里看應用程式的日志，以及看網路交換機性能指標，才能清晰的定位問題，下面是一個資料庫偶發連接不上的例子：

【問題分析】

通過問題的初步評估，故障應該是出現在服務端，也有可能是服務端的網路，我們隨之查看了服務端MySQL的各項性能指標，在故障期間，性能指標都是正常的，在服務器端單邊抓包，抓到的內容如下：

上述網路包解讀如下：

• 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連接的程序如下圖：

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);
}

創建出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，也需要對網路有所了解，才能更好地定位和處理日常的運維問題，

標籤：MySQL

上一篇：MySql創建存盤程序，并使用事件定時呼叫

下一篇：ASPxGridView排序空值默認為最小，Oracle資料庫空值默認最大引起的排序問題