仕事の合間に雑記です。またMySQLに関する記事です。Fusion-IOをMySQL DBマスタに使う時はスレーブ(こっちもFusion-IO)が耐えられるか検証した方が良いよって話。



おれが担当しているシステムは他のシステムの更新情報をかき集めてまとめるようなシステムです(あいまいな説明ですみません)。早い話、更新系の処理がかなり多いです。 更新処理が多いときにデータベースに施すテクニックの一つにデータ分割があると思いますが、マスタを分割しまくってサーバを何十台もラッキングして運用するのは骨でした。そこでioDriveの力を借りることにしました。ioDriveの力でDBを数台に集約してしまおうと。一応説明しておくとioDriveとはFusion-IO社のプロダクトで、PCIe接続の超高性能ストレージです。詳しくは下記のリンクを参照。

このioDriveですが、自社のサービスで既に実績があります。また、おれが担当しているまた別のシステムではMySQLスレーブに投入して、10数台あるMySQLスレーブを2台に集約した実績もありました。なので特に疑問をもたず「コイツ(Fusion-IO)ならいける」と・・・(なんとなく「いけんじゃね?」って思っちまったのはエンジニアとしてどうかと思う。我ながら。)。

今回用意した構成はioDriveなマスタ1に対してioDriveなスレーブ2台、この3台のセットを数セット用意しました。マスタに投入したFusion-IOは期待に応え、爆速で更新も参照も捌いてくれました。しかしながらアクセスのピーク帯になって更新処理が増えるとスレーブが600秒~1000秒も遅延してしまった。

調査してみたのですが、スレーブのCPU負荷もIO負荷も大したことなく、またNW帯域を食いつぶしていることもなく、特別重すぎるクエリがあるわけでもなく、単純にExec_Master_Log_Posが遅れている状態でした。ちなみに更新も参照もマスタのみに向けていたのでスレーブに刺さってる参照クエリが邪魔してることもなかった。おそらくはSQLスレッドがボトルネックだと考えています(そもそもDB設計に問題もあるかもしれない。インデックスもかなり張ってるし。)。マスタは並列に更新クエリを捌くことが可能だけど、SQLスレッドは一本しかないのでこの現象は当然と言えば当然。

結局このスレーブ遅延問題の解決の糸口はマスタ分割か、更新クエリを投げるアプリケーションのスレッド数を絞ってやる、というところに行きついた。物理レイヤのテクノロジがどんなに発達しても基本は大事ってことだね。というわけでioDriveをマスタに使う場合、スレーブが耐えられるかちゃんと検証した方が良い、って話でした。

2012/04/16追記

遅延が緩和されました(緩和されただけで遅延が解消したわけではない)。innodbプラグインのデータ圧縮が原因の一つだったようです。もともと扱うデータが大きく、さらにioDriveが高価でそう何枚も買えないので、容量削減目的でデータの圧縮を行っていました。が、紆余曲折あって容量に余裕が出てきたので、一部のテーブルのデータ圧縮を解除(ALTER TABLE t ROW_FORMAT=Compact)してみました。んで、ピーク帯に観察してみると遅延が緩和されていました。
圧縮のオーバーヘッドは承知していたつもりだがここまで影響があるとは・・・。圧縮の利き具合と圧縮に費やされた時間は「SELECT * FROM INFORMATION_SCHEMA.INNODB_CMP;」で見ていたりしたんだけど・・・うーむ。勉強が足りねえ。

 

ちなみにMySQL5.6.3からはSQLスレッドの本数を変更できるようです。しかしながら当然「データベース単位でしか並列化できないよ」とな。そりゃそうだ。

The slave_parallel_workers server system variable (added in this release) sets the number of slave worker threads for executing replication events in parallel. When parallel execution is enabled, the slave SQL thread acts as the coordinator for the slave worker threads, among which transactions are distributed on a per-database basis. This means that a worker thread on the slave slave can process successive transactions on a given database without waiting for updates on other databases to complete.

 

※ データストアとして流行りのKVS(KyotoTycoon等)も検証してみたのですが、運用のことを考えるとやはりMySQLでした。

HBase検証してみたかったな・・・。どうやらFaceBookとTumblrは更新処理が多い個所に使ってるようで、ええ・・・。

FaceBookの事例(これ現場で話聞いた)

Tumblrの事例

HBase backs their URL shortner with billions of URLs and all the historical data and analytics. It has been rock solid. HBase is used in situations with high write requirements, like a million writes a second for the Dashboard replacement.  HBase wasn’t deployed instead of MySQL because they couldn’t bet the business on HBase with the people that they had, so they started using it with smaller less critical path projects to gain experience.

 

 

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

Set your Twitter account name in your settings to use the TwitterBar Section.