這篇文章主要介紹MySQL頻繁停庫怎么回事，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

成都創新互聯成立與2013年，先為嘉蔭等服務建站，嘉蔭等地企業，進行企業商務咨詢服務。為嘉蔭企業網站制作PC+手機+微官網三網同步一站式服務解決您的所有建站問題。

詳細的日志如下：

2017-04-13 16:25:29 40180 [Note] Server socket created on IP: '::'.
2017-04-13 16:25:29 40180 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
2017-04-13 16:25:29 40180 [Note] Slave I/O thread: connected to master 'xx@xxxx:6606',replication started in log 'mysql-bin.000105' at position 732153962
2017-04-13 16:25:29 40180 [Warning] Slave SQL: If a crash happens this configuration does not guarantee that the relay log info will be consistent, Error_code: 0
2017-04-13 16:25:29 40180 [Note] Event Scheduler: Loaded 0 events
2017-04-13 16:25:29 40180 [Note] /mysql_base/bin/mysqld: ready for connections.
Version: '5.6.20-log'  socket: '/tmp/mysql.sock'  port: 6607  Source distribution
2017-04-13 16:25:29 40180 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000105' at position 634901970, relay log '/mysql_log/relay-log.000339' position: 25153965
2017-04-13 16:26:01 40180 [Note] /mysql_base/bin/mysqld: Normal shutdown

2017-04-13 16:26:01 40180 [Note] Giving 2 client threads a chance to die gracefully
2017-04-13 16:26:01 40180 [Note] Event Scheduler: Purging the queue. 0 events
2017-04-13 16:26:01 40180 [Note] Shutting down slave threads
2017-04-13 16:26:01 40180 [Note] Slave SQL thread exiting, replication stopped in log 'mysql-bin.000105' at position 637977115
2017-04-13 16:26:01 40180 [Note] Slave I/O thread killed while reading event
2017-04-13 16:26:01 40180 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.000105', position 732432767
2017-04-13 16:26:01 40180 [Note] Forcefully disconnecting 0 remaining clients
2017-04-13 16:26:01 40180 [Note] Binlog end
2017-04-13 16:26:01 40180 [Note] Shutting down plugin 'partition'
2017-04-13 16:26:01 40180 [Note] Shutting down plugin 'INNODB_SYS_DATAFILES'
2017-04-13 16:26:01 40180 [Note] Shutting down plugin 'INNODB_SYS_TABLESPACES'
2017-04-13 16:26:01 40180 [Note] Shutting down plugin 'INNODB_SYS_FOREIGN_COLS'因為mysql服務進程啟動沒有一會就自動停止了。而且仔細查看這個日志，會發現里面沒有任何Error的字樣，有幾個warning的信息，但是覺得不應該是問題的根本原因。

   通過上面的日志，我們會得到一些基本的信息：

1. 這是一個從庫，可以從relay的信息看出

2. 停庫的時候看起來是一個順序的過程，不像是掉電宕機，異常crash的特點

3. 標紅的那句：

   Giving 2 client threads a chance to die gracefu

我覺得這句日志是這個問題查找的一個重點方向，怎么兩個thread就可以優雅的die了。

   所以我準備從幾個角度來查看。

1. 是否是系統層面的異常

2. 是否是內核參數的設置問題

3. 是否是數據庫參數的設置

4. bug

   第一個問題，我查看了文件系統是ext4,內存是64G,剩余內存還很多，系統的配置和負載都不高。

   第二個問題，我查看了內核參數的設置，主要的shmmax這些參數設置都沒有問題，我看了里面還指定了很多細節的網絡設置，我們糾結了下是否是swap會有影響，盡管目前swap使用率幾乎為0，還是帶著試試看的心態調試了下，設置swapniess=1，結果測試問題依舊。

   第三個問題是否是數據庫參數的設置，這個我看buffer_pool_size是40G，其它的參數設置也蠻合理，也沒有生疏的參數設置，所以這個地方也無從下手，不過還是試了是把buffer_pool_size從40G設置為4G，結果問題依舊。

   第4個問題，查找bug,還真找到一個，https://bugs.mysql.com/bug.php?id=71104  但是這個問題很難解釋的通，因為根據這位網友的反饋，這臺服務器早上還好好的，下午就是這樣了，所以說是bug也有些牽強。

   帶著疑問，我也嘗試了啟動加上skip-slave-start都無濟于事。

我覺得得換個思路，還有哪些盲點沒有考慮到。

我突然看到日志目錄下有一個文件，這個文件一看就不是MySQL系統生成的，很像是手工指定生成的文件。查看里面的信息，發現是檢測MySQL運行狀態的檢查。由此我想是不是系統層面設置了什么任務之類的。

使用crontab -l查看，果然看到兩個，第2個就是這個檢查服務狀態的任務腳本，而第一個是一個check_mysql.sh這樣的腳本

內容如下：

#!/bin/bash
    datetime=`date +"%F %H:%M:%S"`
  /mysql_base/bin/mysql -uxx -pxx  -e "select version();" &>/dev/null
  if [ $? -eq 0 ]
         then     
        #date +"%F %H:%M:%S"
                echo "$datetime   mysql is running" >>/mysql_log/check_mysql.log
          else
                pkill mysql;
        sleep 5;
                /mysql_base/bin/mysqld_safe --user=mysql >/dev/null 2>&1 &
        echo "$datetime  ERROR:**************mysql restarted********************" >>/mysql_log/check_mysql.log
  fi大家細細看看這個腳本有沒有問題，基本的思路就是連接到MySQL，查看一下版本，如果得到的結果為0，否則就會殺掉MySQL,然后等待5秒，重啟服務。

  這里的關鍵就是第一部分的內容了，如果連接失敗，后面的步驟肯定會出問題，也就是會直接殺掉MySQL.

  和這位網友確認，他上午是修改了一個數據，這個用戶的密碼應該修改了，導致連接異常出了這個意料之外的問題。

   最快的解決方式就是先注釋掉這個cron,然后調整下密碼，更關鍵的是這個邏輯要進行持續的改進。

以上是“MySQL頻繁停庫怎么回事”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注創新互聯行業資訊頻道！

本文題目：MySQL頻繁停庫怎么回事
文章網址：http://www.2m8n56k.cn/article34/pchjpe.html

成都網站建設公司_創新互聯，為您提供網站設計公司、商城網站、服務器托管、ChatGPT、網站改版、動態網站

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：[email protected]。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯