2024/02/05 02:00AM 頃、突然WordPressから応答が無くなり、WordPress データベースを動かしているRaspberry Pi2 に接続できなくなっていました。
データベースに接続できないだけじゃなく、リモートログインできない！
2024年になったばかりの先月、一度クラッシュして、復旧した後まだ1か月くらいしか経過していないのに。。。。またトラブル？まさか、クラッシュはしていないよね。データベースサーバーがダウンしただけだよね。
そう願いながら、RPI2 につながっている外付けHDDの電源をOff 、On、そしてRaspberry Pi2 の電源もOff、Onして再起動。
起動メッセージが出てきた後、fsck が自動実行されてファイルシステムを修復。ログインできるようにもどりました。よかった～。ただし、バックグランドで fsck と MySQLのチェックが動いている模様。
ターミナルからログインして修復が終わるのを待っていたら、コンソールに怪しいメッセージが。
CAM status: CCB request completed with an error
意味するところは、HDD上に不良セクター。
これが表示され始めると、RPI2 にコマンドを送れなくなります。待つしかないけど、待っていると、次のようになって、
ハングアップ。
再起動すれば、しばらくの間OSにアクセスできるが、その後、狩猟プロセスが切られてしまう状態。
ハングアップする前に可能であれば wordpress データを救出したい！
/var/db/mysql 下のファイルを別のディレクトリーにアーカイブできれば、ftp で救出することができるはず。
まずは、mysqldump を使ってデータベースをエクスポートしようとしたものの、途中でハングアップ。
続いて、cpio でディレクトリ全体をアーカイブしようとしたところ、これまた途中でハングアップ。
問題は、特定ファイルのバックアップ中にハングアップすること。
./wordpress/wp_jetpack_sync_queue.ibd
./wordpress/wp_links_416.sdi
./wordpress/wp_links.MYI
./wordpress/wp_links.MYD
./wordpress/wp_moove_activity_log.ibd
./wordpress/wp_options_418.sdi
./wordpress/wp_options.MYI
./wordpress/wp_options.MYD
Connection closed by foreign host.
先月、クラッシュした時は、MySQLのワークファイルがおかれているセクターがクラッシュしていたため、修復に苦労はしたもののデータは保全されていました。今回は、wp_options.MYD という WordPress データの一部が保存されているファイルを直撃している模様。
wp_options というファイルの役目を検索してみたところ、コンテンツではなく、設定情報などが入っているとのこと。
直接 RPI2 上で MySQLを復旧することは諦め、データ救出に目標を変えました。
別サーバーのUSBポートに USB HDDを接続して、外部ディスクとしてHDD に fsck を実行。
やっぱり、ディスク上にある不良セクターは修復できない！
修復は出来ないものの、OSが入ったドライブではないので、修復中にOSがハングアップするようなことはない。/var/db/mysql 下をほぼ全部別ドライブにコピーすることに成功。問題の wp_options.MYD は、エラーが出ながらも一応コピーに成功。どの程度オリジナルデータが含まれているかは不明。
ここで、RPI2用HDDは切り離し。
HTTPサーバーで、同時にMySQLサーバーを動かす去年まで運用していた構成に一時的に戻し、データ吸出しを行うことにしました。
HTTPサーバーで、吸い出したデータでMySQLを起動したところ、MySQLは無事に起動。
# mysqlcheck --all-databases -u root -p
で、スキャンを試みたところ、
wordpress.wp_aal_products OK wordpress.wp_aal_request_cache OK wordpress.wp_aal_tasks OK wordpress.wp2_commentmeta warning : 1 client is using or hasn't closed the table properly status : OK wordpress.wp_comments OK wordpress.wp_jetpack_sync_queue OK wordpress.wp_links OK wordpress.wp_moove_activity_log OK wordpress.wp_options warning : 1 client is using or hasn't closed the table properly error : Size of datafile is: 1015808 Should be: 1540524 error : Corrupt wordpress.wp_postmeta warning : 1 client is using or hasn't closed the table properly status : OK wordpress.wp_posts warning : 1 client is using or hasn't closed the table properly status : OK
しっかり、エラーが見つかって、修復できず。
続いて、自動修復オプション付きのコマンドを発行。
# mysqlcheck -u root -p --auto-repair
略
wordpress1.wp2_moove_activity_log OK
wordpress1.wp2_options OK
wordpress1.wp2_postmeta OK
データベーステーブルはOKとマークされましたので、データベースの修復は完了。
問題は、WordPress から見た時、どの程度のデータが失われているか。
Apache も起動して、WordPressが同被害を受けているか見たところ、、、、、コンテンツは問題なさそう。
しかも、Wordpress がサクサク動き出した！
よかったじゃない！と、思ったら、プラグインが全部オフになってました。
消えたデータには、WordPress プラグイン情報が保存されていた模様。まあ仕方ない。コンテンツが失われるよりはマシ と割り切るしかないけど、プラグインを元のように有効にしたところ、、、、一気にサーバーのメモリを使い果たしてスワップしまくり状態になってしまい、ほぼホストが停止してしまいました。HDDのアクセス状況を見ながら一つずつ有効に戻してゆくべきでした。
httpd を止めて、外部からのhttp アクセスを一時的に禁止し、やり直し。
一部を除いて、暫定的に復旧した感じです。1台のサーバーでHTTPとMySQLのリソースを賄うのは、現時点では無理があるので、RPI2サーバーを復旧させなきゃいけません。または別のサーバーを立てるか。早急に検討して実行に移す必要が発生しました。
2024/02/15 2:00AM 頃から 18:00頃までアクセスできなかったのは上記のような理由です。