web-dev-qa-db-ja.com

/ usr / libexec / mysqld：通常のシャットダウンですが、私のチームはそうしませんか？

データベースの1つが異常終了しましたが、ログには「正常」と表示されていました。

130422 13:23:01 [Note] /usr/libexec/mysqld: Normal shutdown

130422 13:23:01 [Note] Event Scheduler: Killing the scheduler thread, thread id 379021
130422 13:23:01 [Note] Event Scheduler: Waiting for the scheduler thread to reply
130422 13:23:01 [Note] Event Scheduler: Stopped
130422 13:23:01 [Note] Event Scheduler: Purging the queue. 41 events
130422 13:23:01 [Note] Error reading relay log event: slave SQL thread was killed
130422 13:23:01 [ERROR] Error reading packet from server: Lost connection to MySQL server during query ( server_errno=2013)
130422 13:23:01 [Note] Slave I/O thread killed while reading event
130422 13:23:01 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.002426', position 107
...
130422 13:23:04  InnoDB: Starting shutdown...
130422 13:23:04  InnoDB: Waiting for 201 pages to be flushed
130422 13:23:08  InnoDB: Shutdown completed; log sequence number 6942784551767
130422 13:23:08 [Note] /usr/libexec/mysqld: Shutdown complete

mysqld.logには関連するエラーやスタックトレースはなく、いくつかのエラーがあります。

No data - zero rows fetched, selected, or processed

イベントスケジューラから。

私のチームは（initスクリプトまたはmysqladmin shutdown、...を介して）停止しないと確信しています。 grep最後のbinlogファイルまで、SHUTDOWNステートメントがありませんでした。

他の原因はありますか？さらに情報が必要な場合はお知らせください。

PS：mysql Ver 14.14 Distrib 5.5.28、Linux（x86_64）、readline 5.1使用

4月22日月曜日18:23:33に更新ICT 2013

ソースコードを検索して、私はこれを見つけました：

$ grep -lir 'normal shutdown' mysql-5.5.28
mysql-5.5.28/scripts/mysqld_safe.sh
mysql-5.5.28/Docs/mysql.info
mysql-5.5.28/sql/share/errmsg-utf8.txt

$ grep -lr 'ER_NORMAL_SHUTDOWN' mysql-5.5.28
mysql-5.5.28/Docs/mysql.info
mysql-5.5.28/sql/mysqld.cc
mysql-5.5.28/sql/share/errmsg-utf8.txt

mysql-5.5.28/sql/mysqld.cc

  if (sig != 0) // 0 is not a valid signal number
    my_sigset(sig, SIG_IGN);                    /* purify inspected */
  if (sig == MYSQL_KILL_SIGNAL || sig == 0)
    sql_print_information(ER_DEFAULT(ER_NORMAL_SHUTDOWN),my_progname);
  else
    sql_print_error(ER_DEFAULT(ER_GOT_SIGNAL),my_progname,sig); /* purecov: inspected */

このメッセージがログファイルに記録できる理由は他にないようです。私が考えている可能性の1つは、（SUPER特権を持つ）誰かがバイナリログをオフにしてからSHUTDOWNを実行し、db接続を閉じることです。

PS： このバグ レポートでは、5.5.24でこの問題が発生した人が1人います。

mysqlshutdown
5
quanta

Linuxの視点

このLinuxコマンドを実行する必要があります

history | grep mysqladmin

これにより、誰かがサーバー内からシャットダウンを実行したかどうかを確認できます。これにより、リモートのmysqladminシャットダウンが表示されないことに注意してください。おそらく、tcpdumpを実行し、Word mysqladminまたはshutdownを見つけると役立つ場合があります。

MySQLの視点

シャットダウンコマンドは、コマンドラインユーティリティからは存在しません。したがって、バイナリログにはシャットダウンが記録されません。あなたが言ったとき、あなたは正しい軌道に乗っています。

私が考えている可能性の1つは、（SUPER特権を持つ）誰かがバイナリログをオフにしてから、SHUTDOWNを実行して再度オンにしたことです。

その特権を持つユーザーを調べます。このクエリを実行します。

SELECT user,Host FROM mysql.user WHERE shutdown_priv='Y';

次のようなものが表示される場合があります。

mysql> select user,Host from mysql.user where shutdown_priv='Y';
+-------+--------------+
| user  | Host         |
+-------+--------------+
| root  | localhost    |
| root  | 127.0.0.1    |
| root  | ::1          |
| root  | 10.240.163.% |
| root  | 10.48.19.%   |
| user1 | %            |
+-------+--------------+
6 rows in set (0.00 sec)

mysql>

シャットダウン権限を持つすべてのユーザーが表示されます。 [〜＃〜] super [〜＃〜] 特権にはシャットダウン特権がありません。 [〜＃〜] shutdown [〜＃〜] と呼ばれる別の権限があります。

あなたはすぐにその特​​権を取り消すことができます。たとえば、ユーザーuser1@'%'に注意してください。リモートシャットダウン権限があります。あなたはそれをヤンクすることができます

REVOKE SHUTDOWN ON *.* FROM user1.'%';

または

UPDATE mysql.user SET shutdown_priv='N'
WHERE user='user1' AND Host='%';
FLUSH PRIVILEGES;

これにより、リモートシャットダウン権限が処理されます。

また、SHUTDOWN特権を必要としないすべてのユーザーから削除することにより、ユーザー接続の保護にも対処する必要があります。おそらくこれを行うことができます：

UPDATE mysql.user SET shutdown_priv='N'
WHERE CONCAT(user,'@',Host) NOT IN
('root@localhost','[email protected]');
FLUSH PRIVILEGES;

このようにして、root@localhostと[email protected]のみがローカルホスト内でmysqladmin shutdownを実行できます。 mysqldが[email protected]ファイルへの接続を失い、mysql.sockが接続してシャットダウンを実行できない場合があるため、root@localhostは間違いなく手元にあります。 [email protected]を使用すると、これを発行できます。

mysqladmin -uroot -p -h127.0.0.1 --protocol=tcp

ソケットファイルを必要とせずにmysqladmin shutdownを発行する。

試してみる ！！！

4
RolandoMySQLDBA

管理対象システムでこの問題に遭遇しました。非常に明白な原因を特定するためにしばらく時間がかかりました。これは、システム全体がスケジュールされたメンテナンスのためにダウンしていたことです-更新されたカーネルパッケージが利用可能だったためと思います。

とても明白です！

もちろん、修正はシステム構成を変更して、システムが起動したときにMySQLが自動的に起動されるようにすることでした。これはCentOSにあったため、修正は次のとおりです。

$ Sudo /sbin/chkconfig --level 3 mysqld on
3
Mike Taylor

もう1つ考えられる理由を追加します。私の場合、mysqlの再起動を行ったのは無人アップグレード（Ubuntu）でした。

1
Silvan

これは、メモリが不足している場合に発生する可能性があります（今経験したように）。 Linuxの メモリ不足マネージャー は、メモリ不足（OOM）スコアが最も低いプロセスを強制終了しようとします。

Mysqlログのそのタイムスタンプの周りにメッセージのようなものがないかログを確認します。

メモリ不足：プロセス16503（mysqld）をキルしてスコア156または子を犠牲にします

と：

grep --ignore-case mysql /var/log/syslog（Debian/Ubuntu）

grep --ignore-case mysql /var/log/messages（CentOS/Fedora/RHEL）

0
Elijah Lynn