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

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

詳細(xì)的日志如下：

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'因?yàn)閙ysql服務(wù)進(jìn)程啟動(dòng)沒(méi)有一會(huì)就自動(dòng)停止了。而且仔細(xì)查看這個(gè)日志，會(huì)發(fā)現(xiàn)里面沒(méi)有任何Error的字樣，有幾個(gè)warning的信息，但是覺(jué)得不應(yīng)該是問(wèn)題的根本原因。

   通過(guò)上面的日志，我們會(huì)得到一些基本的信息：

1. 這是一個(gè)從庫(kù)，可以從relay的信息看出

2. 停庫(kù)的時(shí)候看起來(lái)是一個(gè)順序的過(guò)程，不像是掉電宕機(jī)，異常crash的特點(diǎn)

3. 標(biāo)紅的那句：

   Giving 2 client threads a chance to die gracefu

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

   所以我準(zhǔn)備從幾個(gè)角度來(lái)查看。

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

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

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

4. bug

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

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

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

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

   帶著疑問(wèn)，我也嘗試了啟動(dòng)加上skip-slave-start都無(wú)濟(jì)于事。

我覺(jué)得得換個(gè)思路，還有哪些盲點(diǎn)沒(méi)有考慮到。

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

使用crontab -l查看，果然看到兩個(gè)，第2個(gè)就是這個(gè)檢查服務(wù)狀態(tài)的任務(wù)腳本，而第一個(gè)是一個(gè)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大家細(xì)細(xì)看看這個(gè)腳本有沒(méi)有問(wèn)題，基本的思路就是連接到MySQL，查看一下版本，如果得到的結(jié)果為0，否則就會(huì)殺掉MySQL,然后等待5秒，重啟服務(wù)。

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

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

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

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