データベース障害(その2)

昨日のDB障害のつづきです。

 

========関連記事========

本日も、ついさっきまでDBを止めてました。
終わったかに見えた昨日のデータベース障害には続きがあって
昨日、バックアップから書き戻したテーブルにもエラーがあってダメだったので
再度、バックアップから書き戻して
repair table xxx;
を行う事にしたんですが、4台でSSDを構築していた1台を取り外して
32GB×3台=96GB
になっていたせいで
repair table xxx;
ができず。
なぜかというと、mysqlではrepair table xxx;を行った時にテーブルのコピーを作成するので、
SSDの空き容量は、修復対象のテーブルと同容量以上の空き容量が無いと失敗します。
んで、システムの入っている200GBのHDDに一旦コピーして設定ファイルのDBのパスを書き換えてから
repair table xxx;
を行ってから再度SSD-RAID-0に書き戻していたので、今日のDB障害の時間は長くなってしまいました。
現在は、オークション落札相場の調子も良く動いてるようなので、これでいけそうです。
ちなみに、取り外したSSDをXP機にて確認しましたが、スキャンディスクでエラーは修復出来ちゃいました。(XPのインストールも大丈夫です)
ですが、Debian機に繋げるとスーパーブロックのエラーが出た後にI/Oエラーが頻発して、やっぱり使えないという返品交換してもらいにくい状況です。
試していないのですが、スーパーブロックの修復コマンドを打てば治ったかもしれませんが、状況からして再度このSSDを入れてRAIDを組む気にはなれません。
保証が、あと2年半あるので他のPCでXPをインストールして、完全に壊れるまで使う事にしました。
今回のDB障害の教訓をまとめると
・SSDはビミョーな壊れ方をすることがある。
・ブログのバックアップは毎日取るべし!!(ブログが消えたら、やる気も一緒に消えます)
・MYSQLのセッション数が多すぎると良くない。(Webで使うDBで、セッションが50以上あるようなら、システムかプログラムを見直すべきでセッションを増やして対応するのは逆効果になることがある(もちろん規模によって適切なセッション数は変わります))
これで、DB障害からやっと立ち直りました。と思う・・・また、ダメだったらイヤだな〜

追記:次の日にも障害発生しました。

雑談スレ

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)