hbstduy#11
非常に遅くなりましたが、先週に行われたhbstduy#11について。
http://heartbeats.jp/hbstudy/
Maatkitの話
http://d.hatena.ne.jp/marqs/20100515
http://www.slideshare.net/marqs/maatkit-4098945
Maatkit(マートキット) というツールがあって、mysqlでいろいろなことができるらしい。
http://www.maatkit.org/
自分が興味を持ったところを書いてみる。
別スレーブノードのクエリーキャッシュを温める。
新しいスレーブを接続する前に、その新しいマシンにはクエリーキャッシュがありません。
そのため DiskIOが発生するわけですが、クエリーキャッシュを温めておけば、
クエリーがキャッシュにのり、高速に動作することがきたいされます。
あるスレーブサーバーのクエリーのうち select だけを別サーバに向ける
tcpdump -i eth0 port 3306 -s 0 -x -nn -q -tttt | mk- query-digest --type tcpdump --execute h=somedb01.host.h -uuser -ppassword --filter '$event->{fingerprint} =~ m/^select/'
なんという力技!!
わざと遅延させたスレーブを作る。
mk-slave-delayでmasterからslaveへの処理を遅らせる
1日送らせたスレーブを作っておけば、
オペミスでデータをすべて飛ばしても助かるかもしれないる
(もちろん、これだけに頼るのは危険だから バックアップは必須)
マスターとスレーブのズレをチェックして埋める
mk-table-check
マスターとスレーブのずれのチェック。
なにこれすごい。
master と slave がずれたとき、 change master to や reset slave で強引に合わせるとデータの途中に穴が開くことがあるけど、
それすらもあわせてくれるのかなぁ。これはぜひ試してみたい。
制限
mysqlの4系は動かない。
SSDの話
http://d.hatena.ne.jp/halfrack/20100516/1273996781
http://halfrack.g.hatena.ne.jp/keyword/hbstudy11?mode=presentation
この話を聞くためにきました!!
自分なりのまとめ
SSDの導入
はてなは昔からssdを利用しているらしく、最初にかったのは 2008/8/28 。
だけど、それは黒歴史だったらしい。不安定でディスクより先に壊れたとか。
安物だと膨大な負荷をかけると破損があったりするんだろうな。
次に買ったのは X25-M で 2009/2/26 に買ったらしい。
X25-Mは、奥さんも講演されていたな。。。
http://www.nicovideo.jp/watch/sm5377449
X25-Mの価格を見ると、、6万。高い。。。
http://kakaku.com/item/05371910212/
X25-Mの価格は、2万円ぐらいです。
http://kakaku.com/item/K0000109824/
#コメント欄で教えてもらいました。ありがとうございます。
主にDB用らしい。導入時期が遅いのは値段が高かったから。
現在 57台のSSDマシンが動作している。
SSDがないとサービスが死んでしまうぐらい大事。
SSD vs Disk
SSD は update が早すぎて、レプリケーションが追いつくどころか離されるぐらい。
SSDに追いつくためにdiskは、 ちゃんとしたraidカードを積んでいるサーバが必要になっている。
はてなはサーバハードのリプレースを頻繁にやる。(運営ご苦労様です)
SSDの特徴
ALTER TABLE が早い
disk で RAIDを組んだマシンで alter するより、SSDマシンだと tar でもって展開した方が早かったりするぐらい。
ddでテストしていると、やはりシーケンシャルライトが遅いなという特徴がある。(diskより早いけど)
SSD の DB を導入すると、1台で参照系クエリーをすべて裁けたれする。
ディスクとSSDの混合環境で、SSDが倒れると、DISKに膨大な負荷がきて、アクセスを裁けなくなったりする。
結果、サーバダウン。これはよくない。
(これは多重化したのに故障率が逆に上がってしまう盲点だよなぁw)
SSDサーバの用途
SSD をマスターDBにつかわないでください。
はてなでは、SSDをマスターDBには、まだ使っていないことになっているw
実際には、データベースペアの方割がSSDだったすることもあるとかないとか。
基本的に、SSDの用途は、mysqlのスレーブノード。
参照クエリーがいっぱい来るところ。
基本はリードだけなんだけど、レプリケーションが大量にくるので結構書き込んでいる。
スレーブだけではなく、squid のキャッシュに使うと早いとか。
クローラーで集めたデータを保存するサーバなどにも使っている。
マシン構成
RAM 8G + SSD Random read でカバー
EPCメモリもない家庭用のPC
RAIDなしのシングル構造
/ から SSD に全部乗せている。
ファームウェアのバージョンは特に気にしていない。
ファイルシステムのアライメントとかもはあんまり気にしていない。
品質の悪い SATA れーブルを使うとパフォが劣化したことがある。
サーバの動作モード AHIC にしないと動作モードが下がる。
SSDの寿命とかとSMART
SSD 50台動いていてまだ一台も壊れていないw
X25-M は SMART でいろいろな情報が取れる。
0xE9 233 Media Wearond Indicator
Write両の多いDBはどんどん減っていく。
これが0なのが、寿命らしい。
だけど、0になっているサーバもあるらしい
なぜ？
6のサーバがあったが なぜか 106 になっていた。
0xE8 232 Available Reserved Space
よく話題になるが、監視していてもあまりかわらない。
値が99のサーバも
障害であがったSSDを回収して
ddコマンドでシーケンシャルリード、シーケンシャルライトを行ってみると、シーケンシャルライトの速度は落ちているけど、ランダムライトは落ちていないらしい。
インフラエンジニアのためのcassandra入門
http://d.hatena.ne.jp/akuwano/20100514#1273853869
kumofs vs cassandra(カサンドラ) を見てみたいなぁ。。。
高負荷で安定しないとか「ちょっwww」って思ってしまう。高負荷だから利用するんだろうと。
話を聞いていると、 kumofs の方がいいような気がするが、どうなの？
