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

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

詳細的日志如下：

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服務進程啟動沒有一會就自動停止了。而且仔細查看這個日志，會發(fā)現(xiàn)里面沒有任何Error的字樣，有幾個warning的信息，但是覺得不應該是問題的根本原因。

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

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

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

3. 標紅的那句：

   Giving 2 client threads a chance to die gracefu

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

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

1. 是否是系統(tǒng)層面的異常

2. 是否是內(nèi)核參數(shù)的設置問題

3. 是否是數(shù)據(jù)庫參數(shù)的設置

4. bug

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

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

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

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

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

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

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

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

內(nèi)容如下：

#!/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秒，重啟服務。

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

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

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

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

本文題目：MySQL頻繁停庫怎么回事
文章網(wǎng)址：http://sd-ha.com/article34/pchjpe.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設計公司、商城網(wǎng)站、服務器托管、ChatGPT、網(wǎng)站改版、動態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)