最も安全な掃除方法は何ですか?
レプリケーションなしの Debian 8 上の MySQL サーバー 5.5.62-0。
ミスをして、26GB のテーブルに新しい列を作成しました。MySQLSHOW PROCESSLIST
が 100% の CPU でデータを tmp テーブルにコピーしていることが示されました。
+-----------+------+-----------+--------+---------+------+-------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----------+------+-----------+--------+---------+------+-------------------+------------------+
| 145904211 | root | localhost | huge | Query | 160 | copy to tmp table | ALTER TABLE ... |
| 145905739 | root | localhost | NULL | Query | 0 | NULL | show processlist |
+-----------+------+-----------+--------+---------+------+-------------------+------------------+
数分後、メイン パーティションがいっぱいになり、CPU が 0 に低下しました。systemctl stop mysql
一時ファイルがクリーンアップされることを期待していました。サービスも再起動されませんでした。
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 79G 75G 1000K 100% /
$ sudo systemctl start mysql
Job for mysql.service failed. See 'systemctl status mysql.service' and 'journalctl -xn' for details.
VPS をシャットダウンしてディスクを拡張しました。サーバーは正常に再起動し、MySQL プロセスを起動して接続することができました。すべて正常に動作しているようです。
しかし、20 分前のインシデント以来、ディスク使用量は減少していません。
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 158G 75G 75G 50% /
ハウスキーピングが作動しますか、それとも自分で散らかしたものを手動で掃除する必要がありますか? 最も安全な方法は何ですか?
答え1
まず、mysql コマンドライン ツールから:
kill 145904211;
それすべきクリーンアップしてください。そうでない場合は、 のような名前で始まるファイルを探してください#sql...
。そのうちの 1 つは、 が実行されていたときのタイムスタンプが付いた巨大なファイルですALTER
。それを削除してください。
安全のためALTER
、少なくとも 5.5 日間は次のように動作しました。
- 既存のテーブルと同じように、新しい空のテーブルを作成します。
- スキーマを変更する(あなたの場合は列を追加する)
- 既存のテーブルから新しいテーブルにすべてのデータをコピーします。(遅い部分)
- いくつかのテーブルの名前を変更します。
- 古いテーブルを削除します。
おそらく、ステップ 3 の途中で行き詰まっているでしょう。
唯一のリスクは、非常に高速なステップ 4 のときです。それ以前は、古いテーブルがまだ正常に動作しています。その後、新しいテーブルが古いテーブルを置き換えます。