2011-10-30 125 views
2

我在Ubuntu 11.04上每30分鐘重新啓動一次MySQL 5.1.54。發生這種情況時,下列出現在MySQL日誌:MySQL在Ubuntu上每30分鐘重新啓動一次11.04

111030 12:01:52 [Note] /usr/sbin/mysqld: Normal shutdown 

111030 12:01:52 [Note] Event Scheduler: Purging the queue. 0 events 
111030 12:01:52 InnoDB: Starting shutdown... 
111030 12:01:54 InnoDB: Shutdown completed; log sequence number 0 875122 
111030 12:01:54 [Note] /usr/sbin/mysqld: Shutdown complete 

111030 12:01:55 [Note] Plugin 'FEDERATED' is disabled. 
111030 12:01:55 InnoDB: Initializing buffer pool, size = 256.0M 
111030 12:01:55 InnoDB: Completed initialization of buffer pool 
111030 12:01:55 InnoDB: Started; log sequence number 0 875122 
111030 12:01:55 [Note] Event Scheduler: Loaded 0 events 
111030 12:01:55 [Note] /usr/sbin/mysqld: ready for connections. 
Version: '5.1.54-1ubuntu4-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) 

出現這種情況發條一樣每隔30分鐘,所以這顯然是一些服務重新啓動它。

我檢查了每一個用戶的crontab中的系統(包括系統用戶),並且他們都沒有一個crontab的設置,你可以在下面的輸出中看到:

# awk -F: '{print $1}' /etc/passwd | xargs -n 1 -i crontab -u {} -l 
no crontab for root 
no crontab for daemon 
no crontab for bin 
no crontab for sys 
no crontab for sync 
no crontab for games 
no crontab for man 
no crontab for lp 
no crontab for mail 
no crontab for news 
no crontab for uucp 
no crontab for proxy 
no crontab for www-data 
no crontab for backup 
no crontab for list 
no crontab for irc 
no crontab for gnats 
no crontab for nobody 
no crontab for libuuid 
no crontab for syslog 
no crontab for sshd 
no crontab for landscape 
no crontab for ubuntu 
no crontab for statd 
no crontab for myproxy 
no crontab for condor 
no crontab for messagebus 
no crontab for avahi 
no crontab for joe 
no crontab for smmta 
no crontab for smmsp 
no crontab for postfix 
no crontab for deploy 
no crontab for mysql 
no crontab for redis 

我的dmesg包含每次重新啓動後。我不是AppArmor的專家,但我相信這是每一個MySQL服務啓動時得到正常的消息:

[1165328.780405] type=1400 audit(1319976114.984:74): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=31985 comm="apparmor_parser" 

而且,這裏是MySQL的新貴配置在/ etc /初始化/ MySQL的內容。 conf:

# MySQL Service 

description  "MySQL Server" 
author   "Mario Limonciello <[email protected]>" 

start on (net-device-up 
      and local-filesystems 
     and runlevel [2345]) 
stop on runlevel [016] 

respawn 

env HOME=/etc/mysql 
umask 007 

# The default of 5 seconds is too low for mysql which needs to flush buffers 
kill timeout 300 

pre-start script 
    #Sanity checks 
    [ -r $HOME/my.cnf ] 
    [ -d /var/run/mysqld ] || install -m 755 -o mysql -g root -d /var/run/mysqld 
    /lib/init/apparmor-profile-load usr.sbin.mysqld 
    LC_ALL=C BLOCKSIZE= df --portability /var/lib/mysql/. | tail -n 1 | awk '{ exit ($4<4096) }' 
end script 

exec /usr/sbin/mysqld 

post-start script 
    for i in `seq 1 30` ; do 
     /usr/bin/mysqladmin --defaults-file="${HOME}"/debian.cnf ping && { 
      exec "${HOME}"/debian-start 
      # should not reach this line 
      exit 2 
     } 
     sleep 1 
    done 
    exit 1 
end script 

任何想法可能會導致這種情況?它不會引起任何問題,除了Monit警報聲明「PID已更改服務mysqld」(我有Monit監視mysqld - 但它報告mysqld進程沒有錯誤,除了事實上每隔30分鐘它有它的自從MySQL重新啓動後,PID發生了變化)。

在此先感謝。

+2

你可以檢查(也可能發佈)你的mysql作業定義在新貴? (/etc/init/mysql.conf) – hovanessyan

+0

發表,謝謝。 – user1020643

回答

0

你可以檢查(並可能發佈)你的mysql作業定義在暴發戶? (/etc/init/mysql.conf)。 OK =嘗試刪除「重生」。它不像新貴文檔中記錄的那樣工作。一般來說,如果它被其他進程殺死,它就會被用來重新生成進程,但它似乎沒有按預期運行。你可以看到爲什麼apparmour總是加載 - 因爲腳本中的預啓動節。由於暴發戶很新,而且還在不斷髮展,所以最好使用SysV方式。

+0

試圖剛剛刪除它,並重新啓動MySQL。我同意堅持SysV的方式。但是,這是一個在Ubuntu 11.04上與標準mysql-server軟件包打包在一起的開箱即用的新貴腳本,所以人們會期望它能夠正常工作。不過,我會在接下來的30分鐘內知道問題是否存在。感謝您的建議。 – user1020643

+0

沒有,在我從upstart腳本中刪除'respawn'並且手動重新啓動後,它幾乎在30分鐘後重新啓動。 ( – user1020643

+0

)要比關閉apparmour配置文件還要依賴這種「開箱即用」的新貴腳本,但它們並不總是按照預期行事,如果你想堅持以下腳本實驗 - 複製當前的upstart作業定義,並將其剝離到最低限度(運行腳本+啓動服務命令的運行級別) - 比使用該腳本。看到結果後,開始添加其他內容(post和pre start )如果這沒有幫助,你的問題是由另一個服務而不是MYSQL本身造成的。 – hovanessyan

0

您應該嘗試在沒有AppArmor的情況下運行它:只運行/usr/bin/mysqld_safe/usr/bin/mysqld而不使用新貴並等待30分鐘。如果mysql不自動重新啓動,請在/etc/init/mysql.conf文件中禁用AppArmor,或者對其進行不同的配置。

如果問題仍然存在,請閱讀mysql的日誌。如果日誌未默認啓用,則啓動mysqld時可以使用選項--log-error=/tmp/mysql.log --log-warnings

1

你是否在使用廚師或傀儡,這可能會觸發重啓?

0

似乎將/etc/init.d/mysql啓動腳本轉換爲sysV樣式,而不是作爲一個暴發戶腳本似乎糾正我的問題。

0

我有升級到Ubuntu 14.04相同的問題。我發現這個問題是因爲它提到了AppArmor日誌消息,所以謝謝!我可能沒有意識到MySQL正在重啓。

調查/var/log/daemon.log後,我發現/etc/mysql/debian-start的輸出反覆出現。相關的部分是這樣的:

May 18 06:48:18 tom /etc/mysql/debian-start[15525]: Upgrading MySQL tables if necessary. 
May 18 06:48:18 tom /etc/mysql/debian-start[15528]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored 
May 18 06:48:18 tom /etc/mysql/debian-start[15528]: Looking for 'mysql' as: /usr/bin/mysql 
May 18 06:48:18 tom /etc/mysql/debian-start[15528]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck 
May 18 06:48:18 tom /etc/mysql/debian-start[15528]: Error: Server version (5.5.35-1ubuntu1) does not match with the version of 
May 18 06:48:18 tom /etc/mysql/debian-start[15528]: the server (5.5.37) with which this program was built/distributed. You can 
May 18 06:48:18 tom /etc/mysql/debian-start[15528]: use --skip-version-check to skip this check. 
May 18 06:48:18 tom /etc/mysql/debian-start[15528]: FATAL ERROR: Upgrade failed 

我通過/etc/mysql/debian-start腳本讀取並嘗試運行升級命令腳本,希望能調試它(MySQL服務器需要的時間運行):

/usr/bin/mysql_upgrade --defaults-extra-file=/etc/mysql/debian.cnf 

然後我發現這個工作沒有抱怨,一切都從那個時候開始起作用。我不知道爲什麼它首先失敗,但似乎解決它。 MySQL自此以後沒有重啓過。