dbts2013:mariadb galera cluster 活用例
TRANSCRIPT
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~3ノードまで。それ以上になると工夫が必要か。
• 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