読者です 読者をやめる 読者になる 読者になる

smallpalace's blog

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

MysqlClusterCasual. 20130926にいってきました

HA MySQL 勉強会・セミナー

こんにちは。smallpalaceです。

最近やっと旦那さんの浴衣が完成したけど季節はもう秋です。来年着てもらおうかと。

それはともかく、、

MysqlClusterCasualに行ってきたのでその記録を。すごく面白かったです。

聞いたままメモりました。発表資料が公開されてたら追記すると思います。 

 

http://atnd.org/events/42911

ハッシュタグ: #mysql_jp

 トゥギャッタ:http://togetter.com/li/569292

行った人のブログ:

http://d.hatena.ne.jp/garage-kid/20130926/mysqlclustercasualtalks

http://b.l0g.jp/mysql/mysql-cluster-casual-talks-memo/

------

梶山さんのお話から(途中から聞きました)

 

ACIDのKVSとしても使える

C++APIで。

データが分散配置と二重化されたりしてく

トランザクションに求められる用件を満たしたNoSQL。

一貫性とかも保障してくれるらしい

ハイパフォーマンスもあきらめなくていいらしい。

まるで夢のような話です。

 

20Mqps(2000万)update/secいけるらしい。30ノードの構成で。

 

つかってる会社:米軍、paypalNECCISCOat&t、艦コレ、zynga等

 

MySQL、NoSQL

 

ネットワークは40GbpsのInfiniBandが必要だそう。神々の遊び、というツイートを見かけました。

 

C++は直接いけるけどJAVAAPIもある

apacheのmod_ndbというのがある(つかってもらえないので塩漬け状態)

 

予告:MySQL Connectというののフィードバック情報を得られるMyNA会がある

 5.7の情報っぽいです(来週月曜)

 

 10/25 最新情報セミナー ORACLEとして

     同じ日にMySQL CasualTalksがあるよ

 

 この先2ヶ月くらいイベント山盛りだそうです。

 

 「MySQL Cluster 運用構築バイブル」の宣伝が。

 

-----

奥野さんのセミナー

「MysqlClusterをつかってみよう」

 http://nippondanji.blogspot.jp/2013/09/mysql-cluster-casual-talks-mysqljp.html

「MySQLClusterをCasualに使えるわけないじゃないか」という突っ込みから。

そうですよね。

 

MySQLのストレージエンジンとして使える。

 ENGINE NDB;

 

トランザクション対応

並列分散型

HA機能

 

SQLノードとデータノードがある

SQLの解析のCPUの負荷も分散できる

全ノードあわせて255ノードまで。

 

1台の性能ではInnoDBのほうが上

 ただしNDB APIは爆速

ノードを並べてなんぼ

 データノード

  負荷分散

  データ量の増加

 SQLノード

  SQL解析の負荷分散

ノードを増やしても性能が伸びない処理もある

 少ししかとってこないスキャンとか

 

できること

高可用性

 SPOF排除

 HA機能

 DR

パフォーマンス

 スケールアウト

 リアルタイム処理

 NoSQL

低価格

 GPL版は無償

 商用ライセンスもお手ごろ

 コモディディなハードウェアでも可能

 

管理ノード

 クラスタの構成情報を管理

 各種操作を発行

データノード

 データとトランザクションをつかさどる

SQLノード・APIノード

 

データノードのなかのデータ配置

 シェアードナッシング=NoSPOF

 ノードグループごとにフラグメントが別れ、それぞれデータを分散している

 ひとつこけても大丈夫

 ノードグループ内でひとつこける文には大丈夫。同じグループ内で両方こけるとダメ。

 

インストール

 パッケージをとってくる

 config.ini(管理ノード)とmy.cnf(SQLノード)を書く

 プロセスを起動する

  管理→SQL→データ

 

インストールのデモ

 そんなにカジュアルではなかった。

 

パフォーマンスの勘所

 単純に言うとInnOBと特性が違う。処理の得手不得手がある。

 最新のバージョンをつかいましょう

 バージョンが新しいほど高速化している

 TC(データノードのトランザクションコーディネータ)の選択ロジックが改善されたり色々あるらしい

 7.0からデータノードのオンライン拡張ができる

 7.1からndbinfoでパフォーマンス情報がとれるように

 7.2からpushdown joinというので早くなった

 7.3から外部キーが使えるようになった。NDBAPIのボトルネック解消したらしい。

 

30データノードで、19.5Mtransactions/sec、

スレッドのチューニングができるようになった

主キーを使った検索はデータノード数に応じてスケールする。

データノードは最大48台まで。

 

スキャンは弱い。なぜならデータはすべてのノードに分散しているから。

フェッチするレコードが多い場合、並列処理ができるのでスキャンでも悪くない。

 

どうやって問題を解決するかというと、

ユーザ定義パーティション。だんだんカジュアルではなくなってきた。

user_idをパーティションのキーにするとスキャンがスケールアウトする

 特定のデータノードにだけアクセスすればよくなるので高速に。

レプリケーションによるスケールアウト

SQLノードはMYSQLなので、レプリケーションができる。

スキャンの処理はInnDBのスレーブ側でやると少しカジュアルな感じ。

SQLノードにバイナリログを生成させればレプリケーションが可能に。

 

インメモリデータベースだけれども、早いディスクのほうがいい

 データの永続性のためにたくさんのI/Oが発生するため

  更新を記録するGCP(REDOログ)

  LCP(定期的にメモリのイメージをディスクに書き出す処理)

 ディスクテーブル

 

FusionI/Oの人に貸してもらってベンチしてみてた結果

fioはメモリに近い性能が出てた

 

BLOBは苦手

内部的にBLOB用のテーブルが作成される

 JOINが増えるのと同じ

 なるべくつかわず

  varcharでがんばる

SQLよりも数段早いNoSQLインターフェース

 1.NDB API C++によるネイティブなAPI

 2.clusterJ  javaバインディング

 3.memcachedでアクセスSQLノードの代わりにmemcachedを立てる(InnDBのやつより賢い)

 4.なんだっけ

 

こんなときにおすすめ

 更新性能をスケールしたい

 HA機能

 超絶高速なJOINがほしい

性能の特性の違いに注意

 得手、不得手がある

 適切なスケールアウト戦略をえらぶべし

 

・休憩時間に繰り広げられた@kamipoさんと奥野さんのガチンコな質疑応答

Q:SQLノードが接続した時点でデータノードをどうやって見つけるのか?

A:my.cnfのなかに管理ノードに接続するための情報が書いてあり、

 管理ノードから情報を引っ張ってきて、起動した時点で接続されてる

 

Q:管理ノードは単一障害点にみえるが

A:管理ノードは2つにできるし落ちても影響ない

 フェイルオーバーはデータノード自身がやる

 アービトレータという機能があり、管理ノードしか設定してないときには

 SQLノードもアービトレータになれる、ネットワークパーティションやスプリットブレイン起きたときに引き継ぐとか

 

Q:レプリケーションしてるときにマスタとスレーブのエンジンをかえるのはよくないとかある?

 InnDBの性質をかんがえてこういうスキーマにしなきゃいけないとかあるのかな?

A:やってみていければ大丈夫、動くかどうかはテストをしてみましょう。

 性能の特性の違いについては、メインをクラスタで弱いところだけInnoDBと考えたほうがいい。

 スキャンしたいテーブルだけレプリケーションするとか工夫を色々すると良い。

 

Q:インデックスちゃんと張られてないつかってないクエリがきたときが恐怖?

A:データベース設計しっかりやればスキャンもそこまで発生しないはず

 

ちょっと色々メモりきれませんでした。

盛り上がってきたところで休憩時間おわりに。

 

-----

桜田さんのおはなし

@tsakurada

MySQL Clusterを2009年頃から4年も運用してるそうです。

 スライド:http://www.slideshare.net/TakeshiSakurada/mcct20130926-tsakuradac

・選択

なぜMySQLClusterか。更新系が早いのがいい。IAサーバでスケールアウト、ミッションクリティカル。

インメモリDB確かに早い。今となってはIoDrive+innodbでもかなり高い性能でちゃうので優位性が出しづらい

メモリがたくさん載ってるサーバは高いのでそんなにコモディティでもない

スケールアウトでつかいづらいところもある

HA的にはほかにない。F/Oとても高速で数秒で完了する

いくつかポイントを抑えないと意味がないかも

改めて主張したい優位点

GPLで無償。Inndbとの互換性がV7.3からかなり向上した。

NDB単体でもトランザクションが使える、NoSQLとして使える

 

・導入

最小構成は全部一個ずつあればOK(検証用)

冗長構成だと全部2つずつ必要。実質サーバ4つあればそこそこいけると思われる

データ量が多くなってきたらデータノードを増やすメモリを増やす

スケールアウトのことも考えてデータノードを増やすのがいい

MysqlClusterとして使いたい場合データノードの増やしすぎに注意

SQLノードはいっぱい増やしても大丈夫

実行中のクエリ(トランザクション)がキャンセルされたとき、

エラーをキャッチして後続処理を適切に作りこむ必要があります。

 リトライ、中断、一時的な不整合を許容して後から自動的にリカバリするバッチを定期実行するなど

 アプリ側で考慮しなければならないことが。

InnDBと同じ感覚でテーブル設計していいのか

そのままもってくるとだめかも

トランザクションの分離レベルも違うので注意が必要

高可用性のレベルがInnDB側に引っ張られることになるのでそれをどう保障するかを考える必要がある

 

・運用

なにが起きるか?

→GCP stop!

 GlobalCheckPoint デフォルトだと2秒ごとにHDDにメモリ上の更新ログを書き出していますが、

 コレが何らかの理由でとまるとデータノードがシャットダウンする

 UPDATE t set xx where xxx

 一度のコミットにかかる時間が一定閾値を超過した場合に発生することがある。

 かかる時間と件数を事前にアプリ側で把握してないとだめ

 7.3では無制限の閾値にできるがDBが固まるかも。

 

→ローリングリスタート

NDBのパラメータ変更を反映するためにデータノードの再起動が必要なものがある

再起動が高速であれば問題にならないが、データ量が多くなってくると

 100GBoverだと数十分~2時間とかかかることも。

 リスタート中はDDL文は発行できない

 最新バージョンでは起動時間も高速化しているらしい

多重障害をどこまで考慮するかNDBで一番悩ましいのがこのポイント。

 

→ボトルネックがみえずらい

vmstatとかiostatとかつかうが、NDBの場合ボトルネックがみえずらい。

一見なにも問題なさそうなのにサチレーションが発生するなど

slowログで通常遅くならないselectがでてきたりする

確認ポイントとしては

データノードで異常が起きていないか、SQLノードで異常が起きていないか、などなど

 

データのライフサイクルをどうするか

 メモリを節約するためには削除したいがDELETE遅い

 あいた領域が同じテーブル内でしか再利用されない仕様なので要注意(他でつかうにはローリング再起動必要

 

→バックアップはいいけどリストアが。。

NDBには専用のオンラインバックアップ機能があります

 ロールフォワードリカバリにはbinlogをつかう

しかしバックアップをリストアするには時間がかかる

 100GBあるとおそらく半日以上(ndb-restoreみたいなコマンド)

 ただ、通常は片方のデータノードが生存していてそこからオンラインで

 データを複製・フェイルバックするほうが多いと思われる

 相方が死んだほうがrepがとまるので性能アップする

 

僕達とオラクルさんでだいぶ地雷を撤去したのでそろそろカジュアルに使えると思います

心配な人はライセンスかったほうがいいかな。

------------

山崎さん オラクルのセールスコンサルの人

 スライド: http://www.slideshare.net/yoyamasaki/5mysql-cluster

MySQL Cluster Auto installer

のデモ

 

赤と青のターミナル画面に気をとられましたが、ブラウザで進められるのはいいなと思いました。

 

奥野さんの本がおススメ

 

さくらのクラウド2万円分無料券もらいました。ありがとうございました。

GMOのイベントでカジュアルにさくらの無料券が配られるという。

 

-------

yoku0825さんの高速LT

http://www.slideshare.net/yoku0825/ndbcluster 

7.2

10/04にMyNAのやつがある

10/19にOSC

XtraDBXCluster面白いです

 マルチマスター

 

ほとんどメモれなかったです。

 

------

 

個人的には、以前からMySQL Clusterは知ってはいました。

きっかけは、某社のオンラインゲームの運用がめんどくさいからやらないかという話が来たこと。

それを受けるかどうかで調べてみて、ライセンス買ってくれないなら問い合わせできないから無理そうですと回答して終わった話です。

無理だと思った理由としては、難しそう、受けても引継ぎ困難になるのが目に浮かんだとかそんな感じです。

その後も高可用性の点でどうなのと社内の人に聞かれたりしましたが、その時点では、JOINが苦手とか

内部ネットワーク10GB必要とか最低3台からとか専任の担当者が必ず必要になるほど運用に手間がかかる、

というような情報があって、それを伝えた時点でじゃあいいやとなるのでした。

その後JOINについては改善されたんだなとわかってよかったです。

 

Twitterでの反応で、面白く共感したのが、

 人類が使いこなすには早すぎるテクノロジーっぽい、

 夢の話が胃の痛い話になってる、

 40MbpsのInfiniBandとか神々の遊び、

というようなつぶやきでした。

まあそうだよね。そうおもうの私だけじゃなくてよかったです。

 

このプロダクトが必要とされるのはもっとこう元々オラクルつかってるような

官公庁とかライフラインにかかわるような領域のシステムたちではなかろうか。

そっちからなら破格の値段ですねーという話になるんじゃないのかと思いました。

もうすこしお金持ちで高可用性を必須とするお客様に売れそうな気がします。

 

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

また機会がありましたら何か書きます。