smallpalace's blog

鯖缶主婦の日々の記録です

mysqlのHAがらみのトラブルの思い出

MySQL HA

いーつのことーだかー思い出してごーらん、あんなことーそんなことーあーったでしょー。

というわけでこんにちは。smallpalaceです。

 

ちょっと前にテクニカルセミナー的な機会があって思い出してくれということになり思い出したのでかける範囲で書いときます。

 mysqlの運用時のトラブルまとめ。HAがらみのところほか順不同です。

 

・高負荷後の「max_connect_errors」がらみでホストによっては拒否されてアクセスできなかったりなど。対策としては、flush hosts;とmax_connect_errors=999999999でエラーカウント無効になるようです。

 

・主にクラウド上でI/OスパイクでF/Oしやすい。（I/O共有なのでしょうがないです）ベンダによってはDBだけ物理で提供（納期はかかる）というのもメニューにあったりして人気があるようです。予算が許せばioDriveとかステキ。

 

・裏側の回線のメンテでハートビートが切り替わったりしたこともあったかな。事前にわかってれば待機系のheartbeatとめとけばいい話です。

 

・cacheですがトラフィックが多すぎてmonでの監視間隔調整しないとF/Oするということがありました。キャッシュはネットワークから詰まるてのはよくある話なんですかね。

 

・バイナリログの保持期限とバックアップ間隔の不都合などでロールフォワードリカバリ難しかったり

　高負荷時に気軽にslave増やしてほしいと言われるが高負荷故にバックアップ取るメンテ時間とれなくreplicationも追いつかないみたいなことも。事前の計画とかデイリーバックアップとか重要ですね。

 

・移設時にmysqldumpでデータとるときのオプションがmaster-data=1で元のマスタにreplicationはりに行こうとするとか（予防策で2にしてますので起きたことないはず）

 

・マルチマスタ構成でF/Oした後のsplitbrain時に意外と助かったりなど（厳密には不幸中の幸いでとらぶるでないですが）

　（マルチマスタだとどっちにもreplicationしてるので上手くアプリ側のID重複しないような仕組みが機能してればsplitbrainしてもデータ消失がほとんどなかったりします。まあ専門家の方はマルチマスタはID問題的に推奨してませんので参考まで。splitbrain防ぐ一般的なやり方はSSHかIPMIでマスタを完璧に落とす、でいい気がします。）

 

・逆にDRBDでsplitbrain起きるとデータぶっ壊れてデグレするので要注意ということがあります

 

・slave追加メンテ時にアプリ側で更新とめてると言われたけど更新されつづけてたのでbkupとりなおしたような。mysqldumpだとデータ量次第で時間かかったりします。

 

・昔のHA環境の自作スクリプトの不具合で明け方の単独メンテで大変だった記憶があります(細かいことは記憶にないですがオペミスでreplicationが1分くらい止まってたみたいです）

 

・replicationが止まると言えば、SQLで止まるかIOで止まるかですが、よくあるオペミス系のIO停止のだと既存サーバとserver_idがかぶって止まったり遅延する等でしょうか。コピーできる環境で生じがちかと思います。

 

・初期のheartbeatのauthkeysファイルでcrcをsha1にされてs-in前のサーバでcpu50%貼りついたことがありました。

 

・RaidコントローラのキャッシュバッテリがWriteBackからWriteThroughになってreplicationのビハインドマスタがどんどん引き離されて広がっていく様子を目撃しました。WBに戻った瞬間に追いついてました。

 

・F/O後に構成が変わってるのにマスタになった元スレーブ上でreplicationチェックが走ってアラートがでたり等。

 

・バッチとバックアップがかぶって失敗したり。MSPだと開発と運用の情報共有が断絶しがちなので難しいですね。

 

・LVSもからんでバックアップとってるので、昔のバックアップスクリプトで、

　まだバックアップ終わってなくてreplication始まってなくてマスタに追いついてないのにサービスに入っちゃったり。

 

・バックアップの都合でDBアカウントがコピーされずにslave追加または移設時に焦ったりなど。

 

・DRDBだと、、データ壊れて書き込みできなくなったとかあったきがします。読み書きチェック監視が追加されてました。

 

・DRBDは昔の0.7とかのバージョンだとプロトコルCだとまともに動かずBとかにしてました。今は昔の話です。

 

・某社の後期のDB(Heartbeat3)でなんかあったような。IPのchekでなんか不安定という問題出てそれをはずしましたっけ。

 

・メモリが足りなくなったりとかswapしたりとかそれをきっかけにF/Oしたこともあったと思います。

　それをきっかけに、swapoffとかカーネルパラメータで仮想メモリ確保させなくしたり

　DBデーモンをoom_killerに落とさせなくしたりとか色々チューニングしたような気がします。

　最近のカーネル(2.6.36以降)はoom_adjに-17じゃなくoom_score_adjに-1000なんですね。

 

全体の話をしますと、何か外部要因でおこることも多いけど人災も結構あって人のエラー率というのはかなり高いので、、

安定した成果を出すには自動化や極力シンプルな仕組みというのは本当に必要だなあと思う次第です。

 

せっかくだから昔要望があって社内向けに作った資料を貼っておきます。

http://www.slideshare.net/YuKomiya/my-sqlha

 

こんな痛い内容を公開してよかったのか色々思うところがあり、1か月くらい悩みましたが、

誰かの転ばぬ先の杖になったらラッキーてことで。

 もちろん範囲を限定しなければもっといっぱいありますよ。。

 

では見ていただいてありがとうございました。

またそのうちに。