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

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

MySQL Cluster徹底活用術

日本オラクル株式会社MySQL Global Business UnitPrincipal Technical Support Engineer

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

免責事項

以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情

報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではない

ため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

Oracleと Javaは、 Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場

合があります。


アジェンダ

MySQL Clusterの概要

MySQL Cluster 7.3の新機能

パフォーマンス

構成例

運用について


MySQL Cluster の概要


MySQL Cluster とは

● 並列分散型の RDBMS

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

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

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

● 台数に応じたスケールアウト

– ビルトインのHA機能

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

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

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

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

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


MySQL Cluster の動作イメージ

データノード

SQL ノード

アプリケーションアプリケーションアプリケーション

NDB API

通常のMySQLプロトコル

管理ノード

SQL ノード SQL ノード

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

データノード

データノード

MGM API


可用性について

● 管理ノード

– 特に必要はない

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

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

● データノード

– データノード内部でデータを同期レプリケーション

– すべてのパーティションでレプリカがひとつでも生きていればOK

● SQLノード

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

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


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

ノードグループ 1

データノード 1


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

フラグメント 3セカンダリ










パーティション3





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
















フェイルオーバー




















フラグメント 1オフライン




























システムダウン
















システムダウン















パーティションへアクセス不能！！


レプリケーション対応

データノード

データノード

データノード

データノード

データノード群

SQL ノード

マスター

データノード

データノード

データノード

データノード


SQL ノード

スレーブ

バイナリログリレーログ

I/Oスレッド

SQLスレッド

マスタースレッド

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


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

データノード

データノード

データノード

データノード


SQL ノードStandby

SQL ノードActive

マスター

データノード

データノード

データノード

データノード


SQL ノードStandby

SQL ノードActive

スレーブ

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


MySQL Cluster 7.3 の新機能


MySQL Cluster 7.3 登場！！

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

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

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

● Node.js用ドライバ

● Auto Installer


MySQL Server 5.6 搭載

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

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

– BKA Join

– EXPLAIANの改善

– オプティマイザトレース

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

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


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

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

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

● 使い方は InnoDB と同じ

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


NDB API のボトルネック解消

● NDB APIの Transporter Mutexが分割された

● ひとつの SQL ノードで処理可能な性能の上限が上昇


Node.js 用ドライバ

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

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

– 低レイテンシー

– スケーラブル

● 既に他のラッパーあり

– Java

– memcached


Auto Installer

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

● Webベース


パフォーマンス


InnoDB との性能特性に注意

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

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

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

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

– スケール戦略も異なる

– ハードウェア要件も異なる


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

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

SQLノード各データノードに

負荷が均等に分散


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

データノードTC

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

SQLノード

1.スキャンリクエスト

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

3.データを返送

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


大規模なスキャンは得意

● Engine Condition Pushdown最適化

ストレージエンジン

SQL実行部

ストレージエンジン

SQL実行部

Pushdownなし Pushdownあり

WHERE句で絞り込み

WHERE句で絞り込み

並列処理


JOIN が遅い？

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

– 内部表へのアクセスにオーダードインデックスが使われていたら要注意！

– 内部表から１行フェッチするたびに苦手な細かいスキャン＝全データノードへ問い合わせ

● MySQL Cluster 7.2で解決！！

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

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

● MySQL Cluster 7.3でさらに改善

– Batched Key Access というアルゴリズムが加わった

– AQL で解決できないケースも拾えるようになった


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

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

customersテーブル

cust_id= 100

cust_id= 100

cust_id= 100

cust_id= 100

cust_id= 100

cust_id= 100

cust_id= 100

ordersテーブル

customersテーブル

ordersテーブル

データノード

データノード

データノード

データノード


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

データノード

データノード

データノード

データノード

スレーブマスター

INNODBINNODB

スレーブ

INNODBINNODB

スレーブ

INNODBINNODB

更新

SQLノード

JOINアプリケーション

SQLノード

SQLノード


memcached

データノード


管理ノードデータノード

データノード

データノード

SQLノード

SQLノード

memcached memcached

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


構成例


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

host1 host2

データノード

SQL ノードデータノード

SQL ノード

アプリケーションアプリケーション

ロ　　　ー　　　ド　　　バ　　　ラ　　　ン　　　サ　　　ー


Connector/J

host1 host2

データノード


SQL ノード

host3

アプリケーション

Connector/J


MySQL Proxy

host1 host2

データノード


SQL ノード

host3


MySQL Proxy

host4


MySQL Proxy

SQL ノード群

SQL ノード

host


M 　 y 　 S 　 Q 　 L 　　 P 　 r 　 o 　 x 　 y

データノード

データノード

データノード

データノード


SQL ノード SQL ノード SQL ノード

SQL ノード SQL ノード SQL ノード SQL ノード


アプリケーションと SQL ノードが同居

データノード


データノード

データノード

データノード

SQL ノード


ロ　　　ー　　　ド　　　バ　　　ラ　　　ン　　　サ　　　ー

SQL ノード


SQL ノード


SQL ノード


SQL ノード


SQL ノード


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

● ソフトウェア

– Gentoo Linux

– MySQL Cluster 7.3.2


電源USB x 4 x 2

100Mbps8ポート

スイッチングハブBeagleBone

Black x 6


config.ini 抜粋

[NDBD DEFAULT]

NoOfReplicas=2

DataMemory=120M

IndexMemory=16M

MaxNoOfConcurrentScans=256

MaxNoOfTriggers=800

MaxNoOfTables=100

MaxNoOfOrderedIndexes=200

MaxNoOfAttributes=8000

MaxNoOfConcurrentOperations=100000

MaxNoOfConcurrentTransactions=4000

FragmentLogFileSize=8M

NoOfFragmentLogFiles=4

RedoBuffer=16M

ODirect=0

TimeBetweenEpochsTimeout=10000

TransactionDeadlockDetectionTimeout=12000

SharedGlobalMemory=12M

DiskPageBufferMemory=4M

TotalSendBufferMemory=8M

RealtimeScheduler=1


構成可能なトポロジの例

ID SQL ノード数データノード数レプリカ

A 2 4 2

B 4 2 2

C 3 3 1

D 5 1 1


0 10 20 30 40 50 60 700

50

100

150

200

250

Aro

Arw

Bro

Brw

Cro

Crw

Dro

Drw

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

tps

Threads

sysbench 0.5 without ranges


高性能マシン： Insight Qube

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

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

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

– 768GB メモリ

– InfiniBand

● ソフトウェア

– RHEL 6.3

– MySQL Cluster 7.3.2


構成可能なトポロジの例

ID SQL ノード数データノード数レプリカ

A 1 1 1

B 1 2 2

C 1 4 ( 同一ホストに 2 ） 2

D 1 4 ( 同一ホストに 2 ） 1


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

0 20 40 60 80 100 120 1400

5000

10000

15000

20000

25000

A

B

C

D

Threads

TpmC


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

● 数値自体はかなり良い

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

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

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

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

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

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

– 再検証で明らかにしたい


NUMA 対策

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

– numactl –preferred=X ndbmtd ...

● 割り込み処理しない CPU

– irqbalance

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

– isolcpus

● CPUバインドする

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


運用のノウハウ


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

● バックアップ

● テーブル定義変更

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

– カラムの追加

● 設定変更

● アップグレード・ダウングレード


バックアップ・リストア

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

– 高速

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

● ndb_restore コマンド

– API ノードとして動作

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

● 結構遅い


Pint In Time リカバリ

● ndb_restore + バイナリログ

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

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

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

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


監視

● MySQL Enterprise Monitor

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

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

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

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

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


● MySQL Cluster Manager

● 商用のCLIツール

● MySQL Clusterの管理を一元化

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

– 設定変更

– ノード追加

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

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


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

Documents

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