Debian7.5のアップデートとミラーのデグレード状態からのリカバリ作業

この記事は約3分で読めます。
スポンサーリンク

バッドセクタのあるディスクをミラーの片方とし、交換せずにそのまま運用していた(笑)が、その状態で、Debian7.5が出たのでアップデート。

Debian7.5

アップデートは問題なく完了したが、

Can’t connect to local MySQL server through socket…/run/mysqld/mysqld.sock

とか、phpMyAdminでも、一部のテーブルに於いて、

MySQL server has gone away

とか、出るようになった。

gone away(逝った)

とあるが、

mysql -u root -p

でログインし、

show databases ;

で、データベースの存在が確認できる。

Debian7.5にアップデートしたのが原因なのか?

とも思ったが、バッドセクタのあるディスクを取り外し、スペアを投入すると、エラーはなくなった。

運悪く、バッドセクタのある場所に関連ファイルがあったのかね…

バッドセクタのあるディスクを載せたまま起動すると、起動プロセスでエラーが表示されるが、起動は可能。

だが、非常に時間がかかる。

以前も書いたが、

sda、sdb、sdc(スペア)

としており、何かあった場合の準備はしていた。

バッドセクタのあるsdbを取り外し、再起動をかけると「デグレード状態」となるが、sdcがsdbとなり、自動的にリカバリが開始される。

デグレード状態 リカバリ中

部分的に同期しています

リカバリが完了すれば、元通り両肺で運用できるが、スペアが実戦投入となりなくなったので、追加しておかなければならない。

同型式のディスクでなくてもスペアにできるが、同型式の方が精神的には良い?

# 同型式であるから同時期に逝く可能性があり、リスクは高まるかも。

最終的に、バッドセクタのあったディスク(元sdb)のバッドセクタ数は、14。

バッドセクタ数:14

このようなことがあるから、バッドセクタが生じたハードディスクは遊んでないで、速やかに交換しよう。

また、同じ型式の場合、不良ディスクがどれかをシリアルナンバーで決めるのだが、ハードディスクを筐体に格納した場合、シリアルナンバーが見えにくいことがある。

シリアルナンバーを転記し、見やすいところへ貼っておくと良いだろう。

関連:バッドセクタ数の変化(Debian7.4)

関連:バッドセクタ数:15→10→9→5→9wwwwwwwwww

関連:(Debian7.4)ミラーリングのスペアディスクの追加と自動リビルド(再構築)

関連:Debian7.4でWEBサーバーを立てる(Apache,MySQL,PHP,phpMyAdmin,FTP)

なお、取り外したバッドセクタのあるハードディスク(元sdb)をWindowsマシンにつなぐと、以下の通り。

C5:代替処理保留中のセクタ数 C6:回復不可能セクタ数

C5:代替処理保留中のセクタ数:00000000000E

C6:回復不可能セクタ数:00000000000E

まぁ、よくある組み合わせのエラーではある。

タイトルとURLをコピーしました