MariaDB Galera Cluster活用例

セントラル短資FX株式会社 清水 純

Agenda

• 会社紹介

• MariaDBってなに？

• MaraiDB Galera Clusterとは

• ベンチマーク

• 活用例(提案)

2

会社紹介

• インターネット上でのFXサービスを提供しています。

3

MariaDBってなに？

• MySQL派生のオープンソースデータベース。

• MySQL ABの創設者 Michael "Monty" Widenius氏が立ち上げたプロジェクト。

• MySQL5.5とMariaDB5.5はほぼ同じだけど、次バージョンのMySQL5.6とMariaDB10はだいぶ異なる。

• これはMariaDB5.5の次期バージョン(現在はベータバージョン10.0.5がリリースされています)では、MySQL5.6と同じ機能を移植、あるいは別実装する予定だがMySQL5.6には無い新機能を備えたリリースを行うのでMariaDB5.6としてはリリースしないとのことらしいです。

4

MariaDBを選択する理由

• バージョン5.5で比較すれば、MariaDBはMySQLのCommunity Edition＋スレッドプール＋プランナ改良版と言えるので、無償でMySQLのEnterprise Editionの機能が使える。

• FedoraもOpenSUSEもMariaDBがデフォルトで採用されるようになった。(RedHat Enterprise 7から採用されるという報道もあったようです。正式決定ではないようですが…)

• MySQLと同じストレージエンジンが使用でき、MariaDB独自のストレージエンジンも複数選択可能

• MariaDB Galera Cluster が使える。

5

ストレージエンジン

6

MySQL 5.6

•InnoDB •MyISAM •MEMORY •CSV •ARCHIVE •BLACKHOLE •MRG_MYISAM •FEDERATED

•InnoDB •MyISAM •MEMORY •CSV •ARCHIVE •BLACKHOLE •MRG_MYISAM •FederatedX •Aria

•XtraDB (5.1～5.5)

•OQGRAPH (5.2～)

•SphinxSE (5.2～)

•PBXT (5.1～5.3)

•IBMDB21 (5.1～5.5)

•Cassandra (10.0～)

•Sequence (10.0～)

•CONNECT (10.0～)

•Spider (10.0～)

MariaDB 5.5/10.0

MySQL/MariaDB機能比較

7

機能 MySQL

5.5 MariaDB

5.5 MySQL

5.6 MariaDB 10.0.5(β)

Multi-source Replication - - - ✓ NoSQL Cassandra Storage Engine - - - ✓ NoSQL Handlersocket interface - ✓ - ✓ NoSQL memcache interface - - ✓ - Dynamic Columns - ✓ - ✓ Virtual Columns - ✓ - ✓ Join Optimizations - ✓ - ✓ Engine Independent Statistics - - - ✓ SHOW EXPLAIN of running thread - - - ✓ Explain improvements - - ✓ ✓ Global Transaction ID - - ✓ ✓ Online Alter Table - - ✓ ✓ Parallel Slave Threads - - ✓ - Partitioning Improvement - - ✓ - InnoDB Improvements - - ✓ ✓ Performance Schema Improvements - - ✓ ✓ Optimizer Enhancements - ✓ ✓ ✓ Binlog Group Commit - ✓ ✓ ✓ Disk Access Optimizations - ✓ ✓ ✓ Subquery Optimizations - ✓ ✓ ✓

※ http://www.ashisuto.co.jp/product/category/database/mysql/#tab4

MariaDB Galera Cluster とは

• MariaDBとCodership社が開発するGalera Replicationを組み合わせたもの。

• 特徴

– 完全同期型のレプリケーション

– アクティブ/アクティブのマルチマスター構成

– 全ノードに対してRead/Writeが可能

– ノード追加/削除を自動で行える

– クライアントからみれば普通のMySQLに見える

8

＋ ＝

MariaDB Galera Clusterを触ったきっかけ

• さくらインターネット研究所さんの"MariaDB Galera Clusterを試す(1)～(3)"という記事を読んだのがきっかけ。 – http://research.sakura.ad.jp/2013/02/14/mariadb-galera-cluster-1/

※ ここで紹介されている内容通りに実施すれば環境が作れます。

• 他にも以下の記事が非常に参考になりましたので紹介です。 – http://dogmap.jp/2013/02/21/mariadb-galera-cluster/

– http://tech.gmo-media.jp/post/41837346333/starting-galera

9

MySQL Clusterとは違うの？

• 全くの別物です。

10

MariaDB Galera Cluster MySQL Cluster

Galera Replication

APノード

データ

ノード

・完全同期型レプリケーション

・DBサーバを増やすだけでスケールアウト

・特殊なストレージエンジンは使用しない

がInnoDBしか今のところ使えない

・階層型のインメモリDB

・NDBという特殊なストレージエンジン

を使用する。MySQLの知識が通用しない

基本アーキテクチャ

• wsrep(WriteSet Replication) APIがレプリケーション機能を担当します。

• トランザクションがコミットされた段階でブロードキャストされ他ノードへ適用されます。

• クライアントはGalera Clusterを使用していることを意識する必要はありません。

11

MariaDB

wsrep API

Galera Replication

MariaDB

wsrep API

MariaDB

wsrep API

同期レプリケーション

12 ※ http://www.slideshare.net/Severalnines/galera-cluster-for-mysql-introduction-slides

Node 1

Node 2

Node 3

time

time

time

BEGIN COMMIT(REQ) COMMIT(ACK/returns)

Statements Commit response time

WS

WS

WS Replication event

OK or Conflict

COMMIT or

Rollback

Apply event Certification

Apply event Certification

Trunsaction applied

(Virtually synchronous)

Trunsaction applied

(Virtually synchronous)

ALL Nodes 100% sync

Step 2

ノード追加

13

Step 1 MariaDB

MariaDB

Node 1

Node 2

MariaDB

'Joiner' Node 3

Step 4 Step 3

※ State Snapshot Transfer スクリプト

MariaDB

MariaDB

Node 1

Node 2

MariaDB

'Joiner' Node 3

SST Request

MariaDB

MariaDB

Node 1

Node 2

MariaDB

'Joiner' Node 3

rsync send ※ Node2は"doner mode"になり、書込みが

ブロックされます。

MariaDB

MariaDB

Node 1

Node 2

MariaDB

Catch Up

Node 3

ベンチマーク

14

• さくらインターネットさん（sysbench）

ベンチマーク

15

• もうひとつさくらインターネットさん(tpcc-mysql)

ベンチマーク

16

• アシストさん

– sysbenchによるRead Only処理

ベンチマーク

17

• もう一つアシストさん

– sysbench によるRead/Write処理

それぞれのベンチマーク結果からわかること

18

• 更新処理がはいるとほとんどスケールしない。

せいぜい2～３ノードまで。それ以上になると工夫が必要か。

• sysbench、tpcc-mysql ともにデータ更新の競合によるエラーやデッドロックが発生しているらしく、ちゃんとしたデータが取得できていない可能性がある。 ※ デッドロックはともかく、競合によるエラーはアプリのリトライ等で対処してほしい。。。

• では、単純にmysqlslapを使用して1ノードだけ負荷をかけた場合、ノード数の増加によるオーバーヘッドはどの程度か調べてみた。

mysqlslapによるベンチマーク

19

• 前提：負荷をかけるノードは1台のみで処理内容は同じ。実行時間の推移だけを見る。

0

5

10

15

20

25

30

35

40

45

1 2 3 4

秒

ノード数 HDD[300GB(15k)x6:RAID5] Fusion-io(ioDrive2)

mysqlslapの結果より

20

• 思ったよりも同期処理のオーバーヘッドによる劣化が大きい。

• I/Oが高速なioDrive2を使用することである程度は劣化を抑えることができたが、それでも十分に大きなオーバーヘッドが存在する。

• LVSやAWS使用時にはELB等のロードバランサ配下に配置して。。。という紹介がされていますが、正直それでパフォーマンスが担保できるかどうか不安。

活用するには

21

• ロードバランサ配下に置くのではなく、MariaDB稼働サーバでVirtual IPを立てて処理単位で振り分ける。

– オーバーヘッドは発生するが劣化は最小限に抑えられる。

• ネットワーク障害やMariaDBに障害があった際にはVIPのフェイルオーバーを行い、他ノードに処理を引き継がせる(リトライ処理は必要)。

• 2ノードの場合、別途Split-Brain対策が必要となるので3ノードでの利用を推奨。

• これらはOSSのPacemaker+Corosync or Heartbeatで比較的簡単に実装可能。

構成概要

22

• PacemakerでMariaDBを管理するために、MySQL用のRA(Resource Agent)がそのまま流用可能。

• MariaDBはclone設定にて全ノードで起動するように設定する。

• NIC障害に対しては基本的にbondingで対応するが、ネットワーク監視を使用してVIPのフェイルオーバー等を行えるようにする。

• ノード障害、MariaDBのプロセス障害等が発生した場合はVIPのみフェイルオーバーさせる。(MariaDBはすでに全ノードで起動しているため)

構成イメージ1

23

bonding

heartbeat＆wsrep replication network

VIP1

bonding

VIP2

bonding

VIP3

Service Network

bonding bonding bonding

MariaDB MariaDB MariaDB

構成イメージ2

24

デモ

25

• VMware上にPacemaker+Corosyncの組み合せで3ノードクラスタ環境を構築しています。

• 実際に障害を起こしてみて、どのように動くのか見ていただきます。

• 今回は時間の関係上、クラスタ周りの説明はしません。環境は異なりますが、私が作った環境の簡易説明資料がSlideShare上に公開されていますので参考まで。 – http://www.slideshare.net/jshimi777/case-study-of-high-availability-oracle-by-

using-the-io-drive-and-drbd-16662472