30

最近、Ubuntu12.04OSデスクトップに5.5.28-29.2PerconaServer（GPL）リリース29.2をインストールしました。さまざまな方法でサーバーを停止しようとしました。

- sudo /etc/init.d/mysql stop
- sudo kill -9 pid
- mysqladmin -u root -p shutdown

このすべてのメソッドはプロセスを停止しますが、終了すると自動的に起動します。syslog（/ var / log / syslog /）を確認しましたが、常に次のトレースが表示されます。

Jan  4 17:50:44 kernel: [ 1915.494219] init: mysql main process (17311) killed by KILL signal
Jan  4 17:50:44 kernel: [ 1915.494245] init: mysql main process ended, respawning
Jan  4 17:50:44 kernel: [ 1915.500025] type=1400 audit(1357318244.557:48): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=18458 comm="apparmor_parser"
Jan  4 17:50:46 /etc/mysql/debian-start[18501]: Upgrading MySQL tables if necessary.
Jan  4 17:50:46 /etc/mysql/debian-start[18504]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Jan  4 17:50:46 /etc/mysql/debian-start[18504]: Looking for 'mysql' as: /usr/bin/mysql
Jan  4 17:50:46 /etc/mysql/debian-start[18504]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Jan  4 17:50:46 /etc/mysql/debian-start[18504]: This installation of MySQL is already upgraded to 5.5.28, use --force if you still need to run mysql_upgrade
Jan  4 17:50:46 /etc/mysql/debian-start[18515]: Checking for insecure root accounts.
Jan  4 17:50:46 /etc/mysql/debian-start[18520]: Triggering myisam-recover for all MyISAM tables

プロセスが自動的に再起動する理由を知っていますか？前もって感謝します！！

4

7 に答える 7

60

私はこれとまったく同じ問題を抱えていました。コマンドを実行するkillとプロセスが強制終了されますが、私の場合は別のプロセスIDで再びポップアップし続けます。

私がそれを永久に止める方法を理解することができた唯一の方法はこれでした：

sudo stop mysql

お役に立てば幸いです。

ソース：http ：//www.itfromscratch.com/how-to-stop-the-percona-mysql-server/

于 2013-04-11T23:34:08.997 に答える
32

使用sudo service mysql stopは私のために働いた。

于 2014-01-27T13:05:12.197 に答える
17

すべてのmysqlインスタンスを強制終了しますか？ルートとして試してください：

 pkill mysqld;
于 2013-01-04T17:02:13.403 に答える
6

MacOSでHomebrewを使用しています。私にbrew services stop mysqlはうまくいきませんでしsudo brew services stop mysqlたが、うまくいきました。

于 2017-10-25T12:41:53.370 に答える
2

ここで推測しますが、mysqldはmysql_safeinitスクリプトを介して開始される可能性があります。これによりサーバーが再起動します。

于 2013-01-04T17:01:11.243 に答える
2

事後の今年を見ている人たちにとって、私は同じような問題を抱えていて、それを解決しただけです。

/ etc/initディレクトリにmysql.confファイルと一緒に存在するorig_mysql.confと呼ばれる2番目のinitスクリプトがあったようです。これにより、upstartが2つのインスタンスを開始し、1つが終了したときに混乱したようです。そのため、継続的なリスポーンが行われました。

私の解決策：

  1. 可能であれば、upstartを介してmysqlを停止します。 service mysql stop
  2. confファイルの1つを削除します（/etc/init/orig_mysql.confを削除しました）。次に、以下を使用してinitを再起動します。 telinit u
  3. 残りのmysqldプロセスを手動で強制終了します。

実行中のmysqldプロセスがなく、それらが再生成されていないことを確認したら、。を使用してmysqlを再起動しservice mysql startます。

これが誰かを助けることを願っています。これを解決するのに2年かかりました。

于 2016-02-27T02:57:02.450 に答える
0

これはこの特定の問題には当てはまらないかもしれませんが、とにかくここに当てはまります。エラーログ（ "/var/log/mysql/error.log"）を確認したところ、 "explicit_defaults_for_timestamp = TRUE"がエラー（ "Unknown variable"）を引き起こしていることがわかりました。そこで、my.cnf（ "/etc/mysql/my.cnf"）から削除し、 "sudo start mysql"を実行すると、バックアップが実行されました。これもお役に立てば幸いです。

于 2016-02-16T03:57:17.687 に答える