2013.9.26 MySQL Cluster Casual Talks MySQL Clusterと丸４年の付き合いを振り返ってのよもやま話と、Version 7.3への期待

1. MySQL Clusterと丸４年の付き合いを
振り返ってのよもやま話と、
Version 7.3への期待
（もっとユーザが増えるといいな
～）
Takeshi Sakurada
@tsakurada
Ultinet Inc.
2013.9.26 MySQL Cluster Casual Talks

2. 自己紹介
• 氏名：櫻田 剛史（さくらだ たけし）
• 所属：株式会社アルティネット
• Twitter id: @tsakurada
• MySQL Clusterと商用で丸4年関わった経験
を買われて（？）MCCTにお声がけ頂きま
した。どうもありがとうございます。

3. 今日お話ししたいこと
• MySQL Clusterとは（スキップ予定）
• 選択（何故MySQL Cluster？）
• 導入（どう使うか？）
• 運用（何が起きるか？）

4. ATTENTION
• 以降のページの記載は基本的に筆者
(@tsakurada)の個人的な体験に基づくもの
ですので誤りや思い込みがあるかもしれ
ません。
• 実際に業務でお使いになる場合には必ず
公式の資料をご確認した方がよろしかろ
うと思います。

5. MySQL Clusterって？
• ユーザ視点で見ると、
– インメモリDBかつ高可用（MySQL CGE）
– ストレージエンジンがMyISAMでもInnoDBでは
なくてNDBであるものです(なので、関係者内
ではNDBとかNDBCLUSTERと呼ばれることが多
いです)
– もともとはNDBは全く別に開発されていたも
ので、MySQL AB（当時）に買収されて統合さ
れた（と聞いてます）

6. タイムライン
2008 2009 2010 2011 2012 2013 2014
構想・検証
★V7.0.5(GA)
★V7.1.3(GA)
★V7.2.4(GA)
★V7.3.2(GA)
★V6.3.8(GA)
運用中

7. ～何故MYSQL CLUSTER？
選択

8. 選択当時(2009年)の特長認識
① インメモリDBなので高速である
② 安価なIAサーバをクラスタ化して、必要性
能に応じてスケールアウト可能
③ 高可用性が求められるシーン（いわゆる
ミッションクリティカル用途）に耐える
という技術上の優位性から採用しました（単
に興味があったというもの…）。
今現在(2013年)の認識はどうかというと…
（次ページ）

9. ①インメモリDBなので高速であ
る
• インメモリDBなので高速というのは本当
です
• ただ、今となってはioDrive + InnoDBの組合
せでもかなり高い性能が出ちゃうので、
絶対的な優位性を主張するのは難しいか
も…

10. ②安価なIAサーバをクラスタ化して、
必要性能に応じてスケールアウト可能
• 共有ストレージ型のDB(Oracle RAC)と比較
して安価、という意味であれば本当でし
た
• ただし、スケールアウトという用語が万
能感を醸し出してしまうのですが、実際
にはスケールアウトが難しいケースもあ
ります（ノード構成選びで説明）

11. ③高可用性が求められるシーン（いわ
ゆるミッションクリティカル用途）に
耐える
• これは今でも優位性が高いと思います
• F/Oはとても高速で数秒で完了します
• ただ、いくつかポイントを押さえておか
ないと意味が無くなるので注意が必要で
す（後述）

12. 今、改めて聞かれたら
主張したい優位点
• ライセンスがGPLであり、無償で使えて
ソースも入手できる（サポートが欲しい
人は商用ライセンスもあり）
• MySQL(InnoDB)との互換性がV7.3以降でか
なり向上したので使いやすくなった
• NDB単体でもトランザクションが使える、
データが永続化される、高可用KVSとして
堅牢である

13. ～どう使うか？
導入

14. MySQL Cluster構成検討
• 基本的な構成
SQL MGM
SQL/MGM 1号機
SQL MGM
SQL/MGM 2号機
データー 1号機
DATA
L2 SW
L2 SW
Web server Web server Web server Web server Web server Web server Web server
アプリケーションレイヤー
データベースレイヤー
データー 2号機
DATA
データー 3号機
DATA
データー 4号機
DATA
14

15. ノード構成のパターン検討①
15
• 最小構成
DATA
SQL MGM
ミニマム構成だが、冗長性も
無いので商用環境には向かない。

16. ノード構成のパターン検討②
16
• 冗長構成
DATA
SQL MGM
単一障害点（SPoF）を排除した
冗長構成の基本形（NW部分の検討は必要）
SQL MGM
DATA

17. ノード構成のパターン検討③
17
• データ量大
DATA
SQL MGM
保存するデータ量（件数）が大きくなった場合にはデータノー
増やして対応できる。ただし、Secondary Index使用時の制約あり
SQL MGM
DATA
DATA DATA

18. ノード構成のパターン検討④
18
• アクセス多
DATA
SQL
MGM
アクセスピークに応じて性能を向上（スケールアウト）さ
せるため
には、SQLノードを増やして対応する。
今となっては、この構成が最適なケースが多いかもしれな
SQL
MGM
DATA
SQL SQL

19. ノード構成のパターン検討
構成
タイプ
MGM
ノード
SQL
ノード
DATA
ノード
合計ノー
ド数
説明
I 1 1 1 3
最小構成（冗長化無し）
試験・開発環境ならば使えるがそれ
以上の意味が無い
II 2 2 2 6 単一障害点(SPOF)無しの冗長構成
（基本形）
III 2 2 4 8 保存するデータ量（件数）が大きく
なった場合
IV 2 4 2 8 アクセスピークに応じて処理性能を
向上させたい場合
V 2 8 4 14 データ量と処理性能の両方に要求レ
ベルが高い大規模システム
VI 2 2 3 7 データノードの冗長化を2重ではな
く、3重にした場合（レプリカ数3）
VII 2 2 6 10
データ量が多く、データノードを増
やして対応した場合（レプリカ数
2）
※完全にPK（主キー）に帰着できるアプリにできないのであれば、データノードの数は最大でも4程度に止めた方が良い。
19

20. 高可用性を生かすために必要な
システム設計上のポイント
• H/W構成上SPoFが無いように2重化する
– 多重障害をどこまで考慮するかは悩ましいです
• 実行中のクエリ（トランザクション）がキャ
ンセルされた時、エラーをキャッチして後続
処理を適切に作りこむ必要があります
– 条件によって
• 処理をリトライする
• エラーとして処理を中断させる
• 一時的な不整合を許容して後から自動的にリカバリす
るバッチプログラムを定期的に起動する
• など…

21. その他、設計上悩ましいポイント
①
• MySQL(InnoDB)と同じ感覚（経験則）で
テーブル設計しても良いのか？
– InnoDBで使っていたものをそのままNDBに
持ってくると期待する性能が全く出ない可能
性もまだあるかもしれません
– ただ、 V7.2, V7.3で互換性が大幅に向上してい
ますのでチャレンジする価値は十分あると思
います

22. その他、設計上悩ましいポイント
②
• バッチ処理のことも考えてInnoDBと組み
合わせて使いたい場合
– 高可用性のレベルがInnoDB側に引っ張られる
ことになるので、それをどう補償するかを考
える必要があります
– NDBとInnoDBは現状、トランザクションの分
離レベルが違うのでその点でも注意が必要で
す

23. ～何が起きるか？
運用

24. ハマリどころポイント
• GCP Stop!
• ローリングリスタート
• ボトルネックが見えづらい
• データーのライフサイクルどうするか？
• バックアップはいいけどリストアが…

25. GCP Stop!
• GCP: Global Check Point
• GCPは（デフォルトだと2秒毎に） HDDに
メモリ上の更新ログを書き出しています
が、これが何らかの理由で停止すると…
• データノードがシャットダウンしてしま
います

26. GCP Stop!
• 例えば…
– UPDATE テーブル名 SET カラム名=値 WHERE 条件
– 一度のコミットにかかる時間が一定閾値を超過し
た場合（＝更新対象となる行数が多数（数万件）
になった場合など）に発生してしまいます
– なので、UPDATEする時には実際に何件が更新対
象となるのかアプリ側で把握してクエリを発行す
る必要があります
– 最新バージョン(V7.3)では閾値を無制限に指定で
きるのでその策で逃げる方法もありますが、本当
に異常が発生した場合のDBが固まってしまうリ
スクが発生します。

27. ローリングリスタート
• NDBのパラメータ変更を反映するために
データノードの再起動が必要なものがあ
るのですが、サービスを止めずにデータ
ノードを１台ずつ再起動する事ができま
す

28. ローリングリスタート
• 例えば、データノードが4台あればDATA01
から1台ずつ再起動、起動後次のDATA02に
進めます
• でも…
DATA01 DATA02
DATA03 DATA04
再起動中
ノードグループ１
ノードグループ２

29. ローリングリスタート
• 図の事例でDATA01が再起動中にDATA02に
障害が発生したら当然ですが全断になり
ますよね？
DATA01 DATA02
DATA03 DATA04
再起動中
ノードグループ１
ノードグループ２

30. ローリングリスタート
• NDBの再起動（起動）が十分高速であれば問
題にならないのですが、データ量が多くなっ
てくると(100GB over)数１０分～2時間くらい
はかかる事もありますので、その間の可用性
リスクが高まってしまいます。
– リスタート中はDDL文が発行できないなど仕様上
の制約もあったりします
– 最新のバージョンでは起動も高速化しているので
すが再起動に掛かる時間を事前に想定、検証して
おくのがよろしいかと思います。
• 多重障害をどこまで考慮するかNDBで一番悩
ましいのがこのポイントです

31. ボトルネックが見えづらい
• サーバの性能ボトルネックを探るツール
としてvmstatやiostatを良く使いますが、
NDBの場合ボトルネックが見えづらいです
（一見問題ないように見えるがサチレー
ションが発生するなど）
– Slowログを分析するのは有効な手段には変わ
りないのですが、通常遅くならない主キーで
のSELECTが出てきたりすることがなどありま
す
• 確認するべきポイントが多いと言った方
が適切かもしれません

32. ボトルネックが見えづらい
• 確認ポイントとしては例えば
– データノードで異常が起きていないか？
– SQLノードで異常が起きていないか？
– ノード間接続をしているN/Wに異常が無い
か？
– NDBINFOの値を見てみる
（事例・ノウハウが貯まってくれば自然と解
決する課題だとは思います）

33. データーのライフサイクルをどう
するか？
• メモリを節約するためには不要になった
データはなるべくこまめに消したいとこ
ろですが、DELETE文はやはり遅い（重
い）です
• あと、DELETE文で削除した場合、その空
いたメモリ領域は同じテーブル内でしか
再利用されない仕様なので注意が必要で
す
– データノードを再起動すれば解決しますが…
– DROP TABLE文であれば即時に再利用されます

34. バックアップはいいけどリストア
が…
• NDBには専用のオンラインバックアップ機能
があります（ロールフォワードリカバリをす
るためにはbinlogを使います）
• しかし…バックアップデータをリストアする
には結構時間がかかりますので、やはり事前
に検証して運用設計をしておくことがよろし
いかと思います
– 100GBぐらいあるとおそらく半日以上かかります
– ただ、通常はもう片方のデータノードが生存して
おりそこからオンラインでデータを複製・フェイ
ルバックするケース想定の方が多いと思われます

35. まとめ
• 高可用性システムを構築するには今でも
MySQL Clusterは適した選択です
• ただ、いろいろ考慮した方がよいポイン
トはあります
• いろいろな課題はあるものの、最近の機
能拡張にはめざましいものがあるので、
ユーザーがもっと増えるといいな

36. ご清聴ありがとうございまし
た
今後とも、
MySQL Clusterをよろし
く！