MySQL DBの破損と、その直接の原因と思われるHDDの破損について詳細を記します。
2017年4月28日ごろ自宅サーバの基幹システムが入ったRAIDシステムがデグレード(縮退運転)に入ったという通知あり
代替セクタの発生等の場合でも縮退運転に入る事はよくあるが、この縮退運転は書き込み時に致命的エラーが起きたためであり、回復不能なものであった。更に書き込まれたファイルはMySQLのデータベースそのものであったため、この時点以降、データベースが少しずつ壊れ始める。
某ユーザがWordPressの記事を更新する。その時に既にタイムアウトエラーでデータベースへの接続が切れたという表示がなされたが、深刻に捉えなかったため、管理者への報告は行われなかった。
このころ、システムスクリプトのdebian-startがMySQLへのアクセスに失敗し、暴走をはじめる。常にプロセスが走る状態になりLAが1以下に下がらなくなる。なんとなくサイトが重いという印象を抱き始める。
管理者自身が自分用のDBを更新する時に数回タイムアウトというものを見る。すぐに回復するため、やはり深刻には捉えなかった。
30日の深夜、RAIDがデグレードしている事に管理者が気が付く。いつもの手順として、まずリビルドを試すが、リビルドに失敗したことからHDDに深刻なエラーが起きているのではないかと思い、smartctrlでHDDのSMARTを調べると多数のセクタ不良のパラメタが表示され、HDDが深刻な状態になっているという認識を持ち始める。HDDは半年前に交換したものだった。
現在動いているHDDのSMART報告も深刻な状況であり、システムHDDは危機的であったが、そのHDDの調査のために入ったSHELLも非常に重たい状態で操作が困難であった。psを駆使して負荷が重たい原因を探るとMySQLにアクセスしているdebian-startというスクリプトであった。当初はdebian-startをリネームして負荷を下げる事に成功したが、調査をしていくとMySQLのDBが破損しているためにdebian-startのユーザ認証が通らず、スクリプトが終了出来ずにDoSアタック状態になっているとわかってきた。
MySQLのDBが破損している事に確信をもっため、ユーザからの聞き取り調査を行い、HDDの破損によるRAIDデグレードとMySQLDBが連動していると推定、まずHDD破損によって全システムが停止する事態を回避するため、まずHDDを交換しRAIDの再構築を行った。これは5/1の深夜には成功した。
RAIDの再構築に成功したが、再構築のためにMySQLサーバを停止して再起動したとみろ、クラッシュしてしまい２度と起動しなくなってしまった。色々調査したが、データベースは一元化されたファイルに保存される形式と分散形式があり、一元化された方は一部でも破損するとどうしようもないという現実を知ることになる
破損したデータベースに見切りをつけ、MySQLを再イントールしてデータベースを刷新、バックアップのあるものはバックアップから回復させたが、やはりバックアップも29日以降のものは破損していた。
バックアップのあるものは回復させることができ、損失も数日で済んだが、無いものは交換前の古いHDDからデータベースを取り出して、一時的に挿げ替えてMysqldump、バックアップを作ってインポートしたが、おおよそ3000時間前のものな巻き戻ってしまい、多数の記事は消えてしまったし、電子部品検索システムもかなり失ってしまいました。バックアップが如何に大事かということですが、たかが3000時間程度でボロボロに壊れた東芝HDDね完全な不良品だと思います。数か月差の製造時期が異なるHDDなのですが、まったく同じような壊れ方をしていました。
RAIDから外れた最初のHDDにデータが残っていないか期待しましたが、スーパーブロックが破損しており、取り出すことはできませんでした。
高い代償というか、自宅鯖の運営で12を争う危機的状態だっと思われます。死に損ねたといってもよいぐらいですが、懲りずに運営します^^;
