[C21] MySQL Cluster徹底活用術 by Mikiya Okuno

MySQL Cluster 徹底活用術
日本オラクル株式会社
MySQL Global Business Unit
Principal Technical Support Engineer

1

Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

免責事項
以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情
報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下
の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではない
ため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載され
ている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。
Oracle と Java は、 Oracle Corporation 及びその子会社、関連会社の米国及びその他の
国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場
合があります。

2


アジェンダ
 MySQL Cluster の概要
 MySQL Cluster 7.3 の新機能
 パフォーマンス
 構成例
 運用について

3


MySQL Cluster の概要

4


MySQL Cluster とは
●

並列分散型の RDBMS
–

複数のノードでデータと処理を分散
●

●

●

ネットワークを経由してノード同士が通信

●

–

シェアードナッシング・アーキテクチャ
台数に応じたスケールアウト

ビルトインの HA 機能

MySQL サーバのストレージエンジンのひとつとして実装
–
–

レプリケーションなどの MySQL 従来の機能が利用可能

–

通常の MySQL サーバーとは別プロダクト

–

5

ACID 準拠のトランザクション

コミュニティ版あり（ GPLv2 ）


MySQL Cluster の動作イメージ
アプリケーション



通常の MySQL プロトコル
SQL ノード

SQL ノード

SQL ノード
MGM API

NDB API
データ
ノード
6


データ
データ
ノード
ノード

データ
ノード

データ
ノード

管理ノード

可用性について
●

管理ノード
–

特に必要はない

–

管理ノード不在でもデータノードは動き続ける
●

●

ただしその間のログは取れない

データノード
–
–

●

データノード内部でデータを同期レプリケーション
すべてのパーティションでレプリカがひとつでも生きていれば OK

SQL ノード
–

どのノードからでも同じデータへアクセス可能
●

7

どれかひとつ生きていれば OK


シェアード・ナッシング・アーキテクチャ
データノード 1


フラグメント 1
プライマリ

セカンダリ

プライマリ

セカンダリ

パーティション
1

3

2

4

セカンダリ

プライマリ

セカンダリ

プライマリ

ノードグループ 1
8



シェアード・ナッシング・アーキテクチャ


プライマリ

セカンダリ

プライマリ

セカンダリ

セカンダリ

プライマリ

セカンダリ

プライマリ

9



フェイルオーバー


プライマリ

セカンダリ

プライマリ

セカンダリ

セカンダリ

プライマリ

セカンダリ

プライマリ

10





オフライン

オフライン

プライマリ

セカンダリ

プライマリ

プライマリ

セカンダリ

プライマリ

11





オフライン

オフライン

プライマリ

プライマリ

プライマリ

プライマリ

オフライン

オフライン

12



システムダウン


オフライン

オフライン

プライマリ

プライマリ

オフライン

オフライン

オフライン

オフライン

13



システムダウン
オフライン

オフライン

プライマリ

プライマリ

オフライン

オフライン

パーティションへ
アクセス不能！！
オフライン

オフライン

14



レプリケーション対応
マスター

スレーブ
SQL ノード

SQL ノード
I/O スレッド

マスタースレッド

リレーログ

バイナリログ

SQL スレッド

仕組みは通常の
レプリケーションと同じ
データ
ノード

データ
ノード

データ
ノード

データ
ノード

データ
ノード

データ
ノード

データ
ノード

データ
ノード

データノード群
15



レプリケーション・フェイルオーバー
マスター

スレーブ
SQL ノード
Active

SQL ノード
Active

SQL ノード
Standby

SQL ノード
Standby

データ
ノード

データ
ノード

データ
ノード

データ
ノード

16


チャネルを構成する
SQL ノードに障害が
発生すると F/O

データ
ノード

データ
ノード

データ
ノード

データ
ノード


MySQL Cluster 7.3 の新機能

17


MySQL Cluster 7.3 登場！！
●

●

外部キー制約のサポート

●

NDB API におけるボトルネックの解消

●

Node.js 用ドライバ

●

18

MySQL サーバーのバージョンが 5.6 に

Auto Installer


MySQL Server 5.6 搭載
●

MySQL 5.6 の新機能が全て利用可能！！
–

–

BKA Join

–

EXPLAIAN の改善

–

オプティマイザトレース

–

パフォーマンススキーマの強化

–

19

サブクエリが Semi-JOIN 最適化で高速に

ジャイアントロック（ LOCK_open ）の撤廃


待望の外部キー制約サポート
●

普通に使える（尖っていない） DBMS へ一歩近づいた
–

自前で制約を実装する必要がなくなった

●

●

20

使い方は InnoDB と同じ
参照される（親テーブル）カラムは、主キーないしはユニークキーであること


NDB API のボトルネック解消
●

●

21

NDB API の Transporter Mutex が分割された
ひとつの SQL ノードで処理可能な性能の上限が上昇


Node.js 用ドライバ
●

NDB API を用いた JavaScript 用の新しいラッパー
–
–

低レイテンシー

–
●

データノードへダイレクトにアクセスすることでパフォーマンスを稼ぐ

スケーラブル

既に他のラッパーあり
–
–

22

Java
memcached


Auto Installer
●

●

23

MySQL Cluster をお手軽に構成できるユーティリティ
Web ベース


パフォーマンス

24


InnoDB との性能特性に注意
●

InnoDB とは得手不得手が違う
–

同じような感覚で使うとパフォーマンスがでないことも・・・

–

如何に苦手なワークロードを克服することが重要
●

得意な処理は問題にはならない

–
–

25

スケール戦略も異なる
ハードウェア要件も異なる


主キーによるルックアップは速い！
●

負荷が均等に分散するためスケールアウトが容易
SQL ノード

26


各データノードに
負荷が均等に分散

細かいスキャン（範囲検索）が苦手
SQL ノード

1. スキャンリクエスト

データノード
TC

3. データを返送

データノード

2. 他のノードへリクエスト
27


すべてのデータノードが
応答を強いられる

データノード

大規模なスキャンは得意
●

Engine Condition Pushdown 最適化
SQL 実行部

SQL 実行部

WHERE 句で
絞り込み

ストレージエンジン

Pushdown なし
28


WHERE 句で
絞り込み

ストレージエンジン

Pushdown あり

並列処理

JOIN が遅い？
●

MySQL （ SQL ノード）がサポートしているのは Nested Loop のみ
–
–

●

内部表へのアクセスにオーダードインデックスが使われていたら要注意！
内部表から１行フェッチするたびに苦手な細かいスキャン＝全データノードへ問い合わせ

MySQL Cluster 7.2 で解決！！
–

–
●

データノード側で JOIN ができるようになった

Adaptive Query Localization （ AQL ）もしくは Pushdown JOIN

MySQL Cluster 7.3 でさらに改善
–
–

29

Batched Key Access というアルゴリズムが加わった
AQL で解決できないケースも拾えるようになった


ユーザー定義パーティショニング
customers orders
テーブルテーブル
cust_id
= 100

データノード
データノード

cust_id
= 100

cust_id
= 100

データノード

cust_id
= 100

cust_id
= 100

cust_id
= 100

データノード

cust_id
= 100
通常のパーティショニング

30

customers orders
テーブルテーブル


ユーザー定義パーティショニング

もっと高いスケーラビリティが欲しい場合
→ InnoDB と連携

更新
マスター
SQL
ノード

SQL
ノード

データ
ノード

データ
ノード

31


SQL
ノード
データ
ノード

データ
ノード

JOIN

スレーブ
INNODB

スレーブ
INNODB

スレーブ
INNODB

memcached
SQL
ノード

memcached

データ
ノード

データ
ノード

データ
ノード

管理ノード

SQL
ノード

データ
ノード

32


memcached

SQL ノードと同じデータに
アクセス可能！！

構成例

33


アプリケーション、 SQL ノード、データノードが同居
ロ　　　ー　　　ド　　　バ　　　ラ　　　ン　　　サ　　　ー



SQL ノード

データ
ノード

host1
34


SQL ノード

データ
ノード

host2

Connector/J
host3
Connector/J

SQL ノード

データ
ノード

host1
35


SQL ノード

データ
ノード

host2

MySQL Proxy
host3

MySQL Proxy

host4

データ
ノード

SQL ノード

host1
36


データ
ノード

SQL ノード

host2

MySQL Proxy

host

M 　 y 　 S 　 Q 　 L 　　 P 　 r 　 o 　 x 　 y

データ
ノード
データ
ノード

データ
ノード
データ
ノード


37


SQL ノード

SQL ノード

SQL ノード

SQL ノード

SQL ノード

SQL ノード

SQL ノード

SQL ノード

SQL ノード群

アプリケーションと SQL ノードが同居
ロ　　　ー　　　ド　　　バ　　　ラ　　　ン　　　サ　　　ー





SQL ノード

SQL ノード

SQL ノード

SQL ノード

データ
ノード

データ
ノード

データ
ノード

38


データ
ノード

UNIX Domain
ソケットで接続

世界最小構成（？）： Beagle Bone Black
●

ハードウェア
–

AM335x 1GHz ARM® Cortex-A8

–

512MB DDR3 RAM

–

2GB 8-bit eMMC on-board flash storage

–

micro-SD カードスロット
●

●

Toshiba microSDHC UHS-I 16GB EXCERIA

ソフトウェア
–
–

39

Gentoo Linux
MySQL Cluster 7.3.2


電源
USB x 4 x 2
100Mbps
8 ポート
スイッチングハブ
BeagleBone
Black x 6

40


config.ini 抜粋
[NDBD DEFAULT]

FragmentLogFileSize=8M

NoOfReplicas=2

NoOfFragmentLogFiles=4

DataMemory=120M

RedoBuffer=16M

IndexMemory=16M

ODirect=0

MaxNoOfConcurrentScans=256

TimeBetweenEpochsTimeout=10000

MaxNoOfTriggers=800

TransactionDeadlockDetectionTimeout=12000

MaxNoOfTables=100
MaxNoOfOrderedIndexes=200
MaxNoOfAttributes=8000

DiskPageBufferMemory=4M

MaxNoOfConcurrentOperations=100000

TotalSendBufferMemory=8M

MaxNoOfConcurrentTransactions=4000

41

SharedGlobalMemory=12M

RealtimeScheduler=1


構成可能なトポロジの例
ID

データノード数

レプリカ

A

2

4

2

B

4

2

2

C

3

3

1

D

42

SQL ノード数

5

1

1


ベンチマーク結果： BeagleBone Black / sysbench
tps

sysbench 0.5 without ranges

250

200
Aro
Arw
150

Bro
Brw
Cro

100

Crw
Dro
Drw

50

0
0

43

10


20

30

40

50

60

70

Threads

高性能マシン： Insight Qube
●

ハードウェア（３台貸していただきました）
–

Intel(R) Xeon(R) CPU E5-2680
●

8 コア 16 スレッド x 2 （合計 32 スレッド）

–
–
●

768GB メモリ
InfiniBand

ソフトウェア
–
–

44

RHEL 6.3
MySQL Cluster 7.3.2


構成可能なトポロジの例
ID

データノード数

レプリカ

A

1

1

1

B

1

2

2

C

1

4 ( 同一ホストに 2 ） 2

D

45

SQL ノード数

1

4 ( 同一ホストに 2 ） 1


ベンチマーク結果： Insight Qube / tpcc-mysql
TpmC
25000

20000

15000

A
B
C

10000

D

5000

0
0

46

20


40

60

80

100

120

140

Threads

ベンチマーク結果についての考察
●

数値自体はかなり良い
–

●

マシンが速かったお陰か（ 32 スレッド＋ InfiniBand ）

データノード数に応じてスケールしなかった原因
–

–

SQL ノードを増やせなかったことが原因か

–
●

テストが不完全だったため確実なことは言えない

より多くのノードを使って再検証予定

B パターンの性能が上がらなかったのは測定ミスの可能性
–

47

再検証で明らかにしたい


NUMA 対策
●

特定の NUMA ノードだけで動かす
–

●

割り込み処理しない CPU
–

●

isolcpus

CPU バインドする
–

48

irqbalance

他のプロセスに使用されない CPU
–

●

numactl –preferred=X ndbmtd ...

ThreadConfig =
recv={count=2},send={count=2},tc={count=4},ldm={count=8,cpubind=25,18-21}


運用のノウハウ

49


オンラインで可能なメンテナンス操作
●

バックアップ

●

テーブル定義変更
–

インデックスの追加・削除

–

カラムの追加

●

●

50

設定変更
アップグレード・ダウングレード


バックアップ・リストア
●

オンラインバックアップ機能搭載
–
–

●

高速
各データノードにバックアップファイルを作成

ndb_restore コマンド
–

API ノードとして動作

–

バックアップファイルを読み取ってデータを再投入
●

51

結構遅い


Pint In Time リカバリ
●

ndb_restore + バイナリログ
–

ndb_restore が Epoch と呼ばれる情報を格納

–

Epoch からバイナリログポジションを特定

–

mysqlbinlog コマンドで特定したポジションから再実行
●

52

任意のポジションで停止可能


監視
●

MySQL Enterprise Monitor
–
–

SQL ノード、データノードの状態、システムリソースなどを監視

–

問題のあるクエリの特定に役立つ Query Analyzer 機能

–

SNMP やメールによる通知が可能

–

53

MySQL Server および MySQL Cluster の商用監視ツール

http://www-jp.mysql.com/products/enterprise/monitor.html


●

MySQL Cluster Manager

●

商用の CLI ツール

●

MySQL Cluster の管理を一元化
–
–

設定変更

–

ノード追加

–

ローリングリスタートの自動化

–

54

インストール（ Auto Installer 相当）

http://www-jp.mysql.com/products/cluster/mcm/


55


56


56

[C21] MySQL Cluster徹底活用術 by Mikiya Okuno

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to [C21] MySQL Cluster徹底活用術 by Mikiya Okuno (20)

More from Insight Technology, Inc. (20)

[C21] MySQL Cluster徹底活用術 by Mikiya Okuno