このようなシェル スクリプトを使用して、多数の MySQL データベースを強制終了します (推奨)

朝早くに電話で起こされました。あるプロジェクトのデータベースがダウンしていて起動できないとのことでした（寝すぎでアラームのテキストメッセージは聞こえませんでした）。とても怖かったです！

電話の相手は、MySQLデータベースのマスターデータベースはすべて起動できないが、スレーブデータベースは正常だと言っていました。マスターデータベースが他のAlibaba Cloudマスターデータベースに接続しているのではないかと疑われました。これらのデータベースは以前に Alibaba Cloud から IDC のコンピュータ ルームに移行されていたため、彼はこのような判断を下しました。

すぐにコンピュータの電源を入れ、***に接続し、データベースサーバーの1つにログインし、次のコマンドを実行してmysqlサービスを開始してみます。

[root@bbsmysql121 バックアップ]#mysqld_safe –user=mysql &

起動に失敗し、別のデータベース サーバーを試しましたが、それでも失敗しました。すべてのデータベースを起動できないことを考慮すると、問題はデータベース ホストの問題によって発生している可能性があると暫定的に判断できます。

データベースの基本的な設計は、仮想化された 2 つの物理ノードと、バックアップ用の 1 つの物理マシンです。 1 台の物理マシン上のすべての仮想マシンは MySQL マスター データベースとして使用され、別の物理マシン上の仮想マシンは MySQL スレーブ データベースとして使用されます。

仮想マシンでのトラブルシューティングをあきらめて、すぐにホスト システムにログインします。次に、2 つの側面から問題のトラブルシューティングを行います。

ü 仮想化されたバックエンド管理システム

ストレージがいっぱいで問題が深刻であることが判明しました。

ü ホストシステム debian への SSH ログイン

[6885005.756183] デバイス dm-16 のバッファ I/O エラー、論理ブロック 34667776、非同期ページ書き込みの損失
[6885005.757292] デバイス dm-16 のバッファ I/O エラー、論理ブロック 34667792、非同期ページ書き込みの損失
[6885005.758210] デバイス dm-16、論理ブロック 34667808 でバッファ I/O エラーが発生し、非同期ページ書き込みが失われました
[6885005.759079] デバイス dm-16、論理ブロック 34667824 でバッファ I/O エラーが発生し、非同期ページ書き込みが失われました
[6885005.759922] デバイス dm-16、論理ブロック 34667840 でバッファ I/O エラーが発生し、非同期ページ書き込みが失われました
[6885005.760723] デバイス dm-16 のバッファ I/O エラー、論理ブロック 34667856、非同期ページ書き込みの損失

システム ログ /var/log/messages に多数のディスク IO エラーが見つかりました。

上記の調査結果に基づいて、基本的にはディスクに問題があると結論付けることができます。1 つの問題は、proxmox によって割り当てられたストレージ領域がいっぱいであることであり、もう 1 つはディスク IO エラーです。問題がわかったら、エラーを修正するか、スレーブ データベースをマスター データベースに昇格するという 2 つの解決策があります。スタンバイの問題を考慮すると、マスター データベースの修復に最善を尽くす必要があります。修復できない場合は、2 番目の解決策 (スレーブ データベースの昇格) を使用できます。

ディスクスペースを解放する

ディスク容量がいっぱいになるのはなぜですか?誰かが仮想マシン上で何か操作を行った可能性があり、各仮想マシンが同じ操作を実行したために、ホスト マシンのディスク領域がすぐにいっぱいになった可能性があります。 MySQLデータベースを実行している仮想マシンにログインし、コマンドを実行します。

df-h

他のサーバーにログインすると、パーティション /dev/sdb1 も 90% 以上使用されています。ディレクトリ /data に入り、次のコマンドを実行してディレクトリのスペース使用量を表示します。

[root@cumysql121 データ]# du -hs *
4.0K バックアップ
59G db_pkg
59G mysql_db
[root@cumysql121 データ]# cd バックアップ
[root@cumysql121 バックアップ]# du -hs *

なんと、50G を超えるディレクトリがいくつもあります (この記事を書いているときに削除したので、記録は残っていません)。ディレクトリ名から判断すると、これらのファイルはバックアップ データベースによって自動的に生成されたものと思われます。無視して、まず削除してください。

誰かがシステム内で自動タスクを実行したに違いありません。crontab –l コマンドで確認したところ、次のことがわかりました。

#!/bin/bash
/usr/local/xtrabackup/bin/innobackupex --defaults-file=/etc/my.cnf --user=root --passwor='+N4dohask+MsLhG' /data/backup/
/data/backup/* -mtime +1 -exec rm -fr {} \; を検索します。
〜

一見すると、このスクリプトには何の問題もありません。しかし、よく見ると、最後の行に「~」記号があることがわかります。何かが間違っています。スクリプトを書いた人の意図は、ディスクがいっぱいにならないように、データベースを 1 日に 1 回バックアップし、前日の履歴バックアップ データを削除することでした。

しかし、ここでは 2 つの致命的な問題について説明します。

バックアップ戦略エラー

専用のバックアップ システムがあり、ローカル バックアップではなくこのシステムにデータをバックアップする必要があります。

間違った手段

バックアップ スクリプトが記述されたら、手動で実行してその正確性を確認する必要があります。書いた後にそのままそこに放り込むのではなく。

ディスクエラーを修復する

緊急にコンピュータ室に連絡し、技術者に KVM をホスト マシンに接続するよう依頼してください。システムを起動できない場合は、リモートでシステムを表示するか、シングル ユーザー モードに入って fsck などの修復操作を実行できます。

SSH を使用してホスト システムの Debian に接続し、ディスク領域がすべて解放されたことを確認してから、reboot を実行してシステムを再起動します。数分後、システムが正常に起動します。

その後の操作

システム ログを確認すると、ディスク IO エラーはなく、ディレクトリとファイルの作成は正常であり、各仮想マシンの起動とその上のデータベースの起動はすべて正常です。

すべての関係者に通知し、ビジネスの観点からすべてが正常かどうかを確認します。しばらくすると、テキストメッセージでたくさんの回復メッセージが届き、とても安心しました。言うまでもなく、これを実行したのはプロジェクトの SA であり、誰にも通知しませんでした。

彼に個人的に伝え、他の人にも説明するよう頼んでください。将来何か危険なことをするなら、お互いに知らせ合うのがベストです。

以上が私が紹介した内容です。このようなシェル スクリプトを使用して、多数の MySQL データベースを強制終了する方法です。お役に立てれば幸いです。ご質問がある場合は、メッセージを残してください。すぐに返信いたします。また、123WORDPRESS.COM ウェブサイトをサポートしてくださっている皆様にも感謝申し上げます。