MySQL頻繁停庫怎么回事

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

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

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

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

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

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

   Giving 2 client threads a chance to die gracefu

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

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

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

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

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

4. bug

   
   

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

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

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

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

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

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

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

使用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è)腳本有沒有問題，基本的思路就是連接到MySQL，查看一下版本，如果得到的結(jié)果為0，否則就會(huì)殺掉MySQL,然后等待5秒，重啟服務(wù)。

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

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

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

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