しょっぱなから「 MySQL Cluster をカジュアルに使えるわけないじゃないですかｗｗｗ」の爆弾発言ではじまった MySQL Cluster Casual Talks に参加してきました #mysql_jp

今日は、超久しぶりに MySQL Community な勉強会、 MySQL Cluster Casual Talks : ATND に行ってきましたので、今日はそのレポートをしようと思います。
さすがの @nippondanji 節炸裂と @tsakurada さんの運用経験談が最高に楽しい勉強会でした。

まずアジェンダは以下のとおりとなっていました。

【アジェンダ】

Main Sessions:

19:00 – 19:30 @RKajiyamaさん MySQL Cluster大地に立つ！「5.6とは違うのだよ、5.6とは！」

19:30 – 20:00 @nippondanjiさんカジュアルにMySQL Clusterを使ってみよう

20:00 – 20:30 @tsakuradaさん MySQL Clusterと丸４年の付き合いを振り返ってのよもやま話と、 Version 7.3への期待（もっとユーザが増えるといいな〜）

LT:

20:30 – 20:40 @yyamasaki1さん MySQL Cluster Auto-Installerのデモ

20:40 – 20:45 @yoku0825 ウチがNDBCLUSTERを使わない理由をもう一度考える

では、 #mysql_jp が twitter ハッシュタグ、 @nippondanji 氏の「 MySQL Cluster をカジュアルに話せるわけないじゃないですかｗｗｗ」ではじまったセッションもあった MySQL Cluster Casual Talks のわたしがとってきたメモを公開しておきます。

19:00 – 19:30 @RKajiyamaさん MySQL Cluster大地に立つ！「5.6とは違うのだよ、5.6とは！」

ざっくりと MySQL Cluster とはどんなものか
MySQL 5.7 を使ってみたという方はさすがに少数
会場を提供してくれた GMO さんありがとう！ @yoku0825 さん、ありがとう！

＊＊＊＊＊

よくある質問、 MySQL のクラスタリングなの？
海外では MySQL Clustering? なんて聞かれる
SW の名前です。
MySQL の独立したプロダクト
MySQL はブランド名で、 Cluster という別製品だと思ってくれればわかりやすい
MySQL Cluster は 7.3、 MySQL Server は 5.6 。「 5.6 とは違うのだよ、 5.6 とは！」は Cluster は Server じゃないのだよ、という意味
共通するところはあれど全然ちがう
何が違うか、分散型 DB だというところがちがう
共有 Disk はいりませぬ
必要なものはサーバ、がっつりメモリを積んだサーバ。内蔵 Disk でもちろんいい。

＊＊＊＊＊

クラスタには 2 種類
HPC と HA
MySQL Cluster は HA を前提に、性能も高めているという立場

＊＊＊＊＊

その特徴は？
- 全ノードアクティブ
- シェアードナッシング型
- 全ノード多重化

＊＊＊＊＊

我々は一台のノードを失った
しかし、これは敗北を意味するのか？
否
始まりを意味するのだ

＊＊＊＊＊

アーキテクチャーの絵
クライアント
アプリケーションレイア (node.js, java, ....)
データレイア　は RAID 0+1 のようなイメージ

＊＊＊＊＊

ACID KVS として使うこともできるのだ (API でデータノードにダイレクトアクセス)
最近の KVS は ACID の何がしかの要素、たとえば、 I や D を諦めていたりする
MySQL Cluster は ACID すべてを重視

＊＊＊＊＊

本来、 D を高めようとすると性能は伸びにくいものだが
20 M updates/sec (30台のデータノードで)
をたたき出している
MySQL Cluster のページでこれは確認される。

＊＊＊＊＊

利用ユーザの例
ERICSSON 基地局ベースの位置情報の管理に使っていたのがはじまり
zynga, PayPal(実は裏側は全部 MySQL Cluster とのこと), cisco, vodafone, at&t, NEC
艦これも使ってるみたいだ

＊＊＊＊＊

NoSQL としての使い方も増えてきている

＊＊＊＊＊

NDB API (C++)
- NoSQL の API じつはいっぱいある
  - PHP, Perl, Python, Ruby, JDBC (MySQL)
  - Cluster J (JNI)
  - JS (node.js)
  - Apache (mod_ndb) ぜんぜん update されていない
  - memcached

＊＊＊＊＊

告知
- MySQL Connect での発表を来週、やるよ MyNA(日本MySQLユーザ会)会 2013年9月 : ATND
- MySQL 5.7 DMR2, Fabric がホットトピックやで
- 10/25 にも MySQL イベントあるよ
- 場所はどちらも日本オラクル

19:30 – 20:00 @nippondanjiさんカジュアルにMySQL Clusterを使ってみよう

スライドは ➤ こちら

MySQL Cluster構築・運用バイブル　〜仕組みからわかる基礎と実践のノウハウ

posted with カエレバ

奥野幹也技術評論社 2012-04-10

Amazon

楽天市場

MySQL Cluster 構築・運用バイブルは買ってるよね？今日の入場券みたいなもんやでｗ
((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

＊＊＊＊＊

きっといつものとおり資料はアップされると思うので書いてなかった会話を記述しておきました。

＊＊＊＊＊

使えるわけないじゃないか、カジュアルに、というのは置いておいて

＊＊＊＊＊

MySQL Cluster とは！
- MySQL の姉妹製品としての位置づけ
- MySQL の Storage Engine と使える
- create table hoge engine NDB とするだけで使えちゃう！カジュアルですね！
- トランザクション対応
- HA
- ハイパフォーマンス、そして　GPL v2 最強ですね

＊＊＊＊＊

Data node にアクセスするための SQL node が複数あるのが特徴 ()
最大 255 node までできるよ

＊＊＊＊＊

速いの？
- 結論：1台だけだと InnoDB には勝てない
- ただし、 NDB API は爆速！
- ノード並べてなんぼ
- だけど、苦手はあるよ、少ししか行を取ってくるような処理は遅い
- なので sysbench とかは遅い ... order by とかスキャンする処理が多いから

＊＊＊＊＊

MySQL Cluster でできること
- 高可用性
- 遠隔地にも Replication できる DR 対応
- 価格も安い (GPL版、コモディティーマシンで構築可能)

＊＊＊＊＊

3種類のノード
- 管理ノード (クラスターの構成情報、各種操作を発行)
- データノード
- SQL ノード / API ノード

＊＊＊＊＊

シェアードナッシング＝ No SPOF
- 内部的に同期レプリケーションしている
- データをフラグメントにわけて、プライマリからセカンダリにレプリケーションする

＊＊＊＊＊

4ノードの例
- データノード、ひとつこけても大丈夫
- データノード、ふたつこけても大丈夫
- ただし、同じノードグループが2ノード死ぬとダメ

＊＊＊＊＊

とりあえずインストールするには
- パッケージをインストールする
- config.ini と my.cnf を書く
- ユーザやディレクトリつくる
- プロセス起動する
  - ほら、カジュアルだろｗ

＊＊＊＊＊

ここでデモ
- ちょっくらインストールしてみましょうという
- all status 詳細な情報をみるときに打つコマンド
  - どうだ、カジュアルだっただろとｗ

＊＊＊＊＊

使いこなすのに一番むずかしいと思うところ
- パフォーマンス
  - InnoDB とは違うから
  - 得手不得手がそれぞれで違う
  - というわけで、パフォーマンスの勘所
  - まず大事なのは、最新バージョンを使いましょう
  - まずは一番最初にバージョンをあげてみてから聞きに来いｗ
  - バージョンが新しいほど高速化している
  - 6.3 でスレッドのバインディングができるようになってたり epoll に対応してたり
  - 7.0 では DN がマルチスレッド化されたり、メッセージ通信の改善、 DN のオンライン拡張
  - 7.1 ndbinfo でパフォーマンス改善のヒントをとれるように
  - 7.2 MySQL 5.5, pushdown join, memcached の追加
  - 7.3 MySQL 5.6 および Semi-join 最適化, 外部キーの対応 (これ大事ね), NDB API のボトルネック解消

＊＊＊＊＊

非公式のベンチマーク結果
- 20110411, v7.1, 8node, 6.82M reads 当時は 1M ですごかった
- 20120215, v7.2, 17.5M reads/s
- 20120516, v7.2.7, 19.5M transactions/s
- 20120522, v7.2, 72 M reads/s
なんで速くなったのか？
- スレッドのチューニングができるようになったのが大きい

＊＊＊＊＊

スレッド数の調整
- MaxNoOfExecutionThreads
- Threadconfig

＊＊＊＊＊

主キーを使った検索は得意
一方でスキャンは弱い
なぜならデータがノードに分散しているから
問題があるのはフェッチするレコード数が少ない場合
フェッチするレコード数が多い場合は並列処理ができるためそこまで遅くならない
Engine Condition Pushdown を活用できる

＊＊＊＊＊

ユーザ定義パーティションという解決方法もある (だんだんカジュアルじゃなくなってきたぞｗ)
スキャンがスケールアウトできる (特定のデータノードにアクセスすればデータがとれるようになるから)
Push down join にも効果がでる

＊＊＊＊＊

そして、 Replication という解決方法もある
ストレージエンジンは違っても MySQL は Replication ができる

＊＊＊＊＊

MySQL Cluster の Replication アーキテクチャの説明

＊＊＊＊＊

速いディスクがあったほうがいいという話
インメモリの DB だけど
更新をすべて記録する GCP (REDO log) や
LCP (定期的にメモリの内容をディスクに書き込む処理) は IO が発生する
ディスク型テーブルというものもあるし
SSD 使えるととてもよい

＊＊＊＊＊

fusionIO を使った sysbench の例
at + link アプリプラットフォームさん、マシンを貸してくれてありがとう！

＊＊＊＊＊

BLOB は苦手
- 内部的に BLOB 用のテーブルが作成されるから
- なるべく使わず varchar で頑張るべし、 InnoDB と連携

＊＊＊＊＊

NoSQL インターフェース
- SQL よりも数断速い
- 一番速いのは NDB API 格段に速い
- 手軽に使うなら便利なバインディングがオススメ！

＊＊＊＊＊

memcached を使う場合は別に memcached サーバを立てる必要がある

＊＊＊＊＊

まとめ
- こういうときに MySQL Cluster オススメ
- 更新性能をスケールしたいとき
- HA
- 超絶高速な Join が欲しい
- ただし、不得意はある
- 適切なスケールアウト戦略が必要、そして、豊富な NoSQL API！

＊＊＊＊＊

Q&A
- 管理ノードが構成情報をもってるという回答の話
- 管理ノードは2つもつことができるのと、管理ノード自体はちょっとくらいどっちも落ちても平気 (logがとれないとかいったことはある)
- まず、リレーショナルモデルをきちんとつくればスキャンもそんなに発生しないはずだ！

20:00 – 20:30 @tsakuradaさん MySQL Clusterと丸４年の付き合いを振り返ってのよもやま話と、 Version 7.3への期待（もっとユーザが増えるといいな〜）

スライドは ➤ こちら

自己紹介、とある SIer 的な会社で働いていらっしゃる

＊＊＊＊＊

MySQL Cluster とは、はスキップ
ユーザ視点でいうと、インメモリで高可用性ってところ

＊＊＊＊＊

だいたい 2009 年ごろからつかいはじめて今も使ってる
新しいバージョンで出直して来いは、何度も言われたけど 7.0 をまだ使ってる

＊＊＊＊＊

選択当時の特徴認識 (2009)
- インメモリで高速
- コモディティーをならべてスケールアウト
- HA

＊＊＊＊＊

今の認識
- インメモリで高速は本当
  - しかし ioDrive + InnoDB でもそこそこ速いのも事実
- コモディティー
  - 共有ストレージ (Oracle RAC) と比べると安価
  - スケールアウトが難しいケースはあった
- HA
  - ここはオススメ
  - FO は高速で数秒で完了する
  - いくつか抑えておくべきポイントはある

＊＊＊＊＊

今、改めて聞かれたら主張したい優位点
- OSS だということ
- MySQL の互換性が v7.3 以降でかなり向上して使いやすくなった
- ndb 単体でもトランザクションが使える。データの永続化ができる。

＊＊＊＊＊

導入：どうつかうか？
- Web server - L2 SW - SQL,MGM - L2 SW - DN

＊＊＊＊＊

ノード構成のパターン紹介
- SQL x 2, MGM x 2, DN x 2
- DN 増やした構成 : SQL x 2, MGM x 2, DN x 4
- アクセス多な構成 : MGM x 2, SQL x 4, DN x 2

＊＊＊＊＊

高可用性を活かすために必要なシステム設計上のポイント
- HW 構成上 SPOF がないように二重化する
- 実行中のクエリがキャンセルされたとき、エラーをキャッチして後続処理を適切に作りこむ必要がある (条件により、処理をリトライしたり、エラーとして処理を中断するようにしたり、一時的な不整合は許可してあとで自己修復するバッチをながすようにしたり)

＊＊＊＊＊

設計上悩ましいポイント (1)
- InnoDB と同じ感覚でテーブル設計して大丈夫か？
- やってみるしかねーべ

＊＊＊＊＊

設計上悩ましいポイント (2)
- バッチ処理とからめて InnoDB と組み合わせる場合
- 高可用性のレベルが InnoDB 側にひっぱられることになる、どう保証するか考慮必要
- ndb と InnoDB ではトランザクション分離レベルが違うことも認識しないとダメ

＊＊＊＊＊

運用：何が起きるのか？
ハマりどころを紹介

＊＊＊＊＊

GCP stop
- デフォルトだと 2sec ごとに HDD にメモリ上の更新を書き込んでくれるのだが、これがとまってしまうと自動的に DN がシャットダウンされてしまう

＊＊＊＊＊

ローリングスタート
- NDB のパラメータを変更するのに DN の再起動が必要だが、1台づつ変更することによって、クラスタはとめないで反映する方法がある
- ただし、クラスタグループがこの最中に全部落ちたら氏ねる
- 多重障害が起きる危険を考慮する必要が出てくる

＊＊＊＊＊

ボトルネックが見えづらい
- 確認するポイントが多い
- ノード単体同士をみてもおかしいようにはみえなくてもサチることがあった

＊＊＊＊＊

データのライフサイクルどうするか？
- メモリの節約のためにデータはこまめに消したいが delete は遅い
- また、それで空いたメモリは同じテーブル内でしか再利用されない仕様なので注意が必要 (DN を再起動すれば解決、 drop table でも)

＊＊＊＊＊

バックアップはいいけどリストアががが
- NDB にはオンラインバックアップ機能がある
- しかし、リストアには時間が結構掛かる (100GB データがあると半日以上かかる )

＊＊＊＊＊

まとめ
- 高可用性システムをつくりたいなら MySQL Cluster はおすすめ
- ただもちろん考慮するべきポイントはたくさんあるので、今日の発表が一助になればと。
- 4年前に比べたらだいぶ地雷は撤去されてるはずｗ

20:30 – 20:40 @yyamasaki1さん MySQL Cluster Auto-Installer のデモ

スライドは ➤ こちら

MySQL Cluster 7.3 についている Auto Installer を使ったデモ
ndb_setup.py という python 製のスクリプトを実行することでインストールができる
ブラウザで操作するようになってる
DataMemory, IndexMemory は 1M はちっさいのですぐに大きめに変更しよう
さくらのクラウド 2 万円分無料券もらったったｗ

20:40 – 20:45 @yoku0825 ウチが NDBCLUSTER を使わない理由をもう一度考える

時間が押しているので大事なことだけいいます！

＊＊＊＊＊

ようは、 MySQL Cluster だと名前わかりづらいから NDBCLUSTER って呼ぼうよ！

それでは、今日はこんなところで。

P.S. 会場を提供してくださった GMO さんに感謝して @MikumoConoHaさんと @MikumoAnzuさんフォローしましたっすw

参考：

Togetter

MySQL Cluster Casual Talks ハッシュタグ #mysql_jp まとめ - Togetterまとめ - この MySQL Cluster Casual Talks 活発に tweet されていたので、折角なのでトゥギャらせてもらいました ( 2013-09-27 1:41 追記 )