Download as PDF, PPTX
![mysqlslapによるベンチマーク
• 前提：負荷をかけるノードは1台のみで処理内容は同じ。
実行時間の推移だけを見る。
秒 45
40
35
30
25
20
15
10
5
0
1
2
HDD[300GB(15k)x6:RAID5]
3
4 ノード数
Fusion-io(ioDrive2)
19](https://image.slidesharecdn.com/mariadbgaleracluster-131118030112-phpapp02/85/dbts2013-MariaDB-Galera-Cluster-19-320.jpg)
dbts2013:MariaDB Galera Cluster 活用例
- 1.
- 2.
- 3.
- 4. MariaDBってなに？ • MySQL派生のオープンソースデータベース。 • MySQLABの創設者 Michael "Monty" Widenius氏 が立ち上げたプロジェクト。 • MySQL5.5とMariaDB5.5はほぼ同じだけど、次バー ジョンのMySQL5.6とMariaDB10はだいぶ異なる。 • これはMariaDB5.5の次期バージョン(現在はベータ バージョン10.0.5がリリースされています)では、 MySQL5.6と同じ機能を移植、あるいは別実装する 予定だがMySQL5.6には無い新機能を備えたリリー スを行うのでMariaDB5.6としてはリリースしないとのこ とらしいです。 4
- 5. MariaDBを選択する理由 • バージョン5.5で比較すれば、MariaDBはMySQLの Community Edition＋スレッドプール＋プランナ改良 版と言えるので、無償でMySQLのEnterpriseEdition の機能が使える。 • 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 MariaDB 5.5/10.0 •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～) 6
- 7. MySQL/MariaDB機能比較 機能 Multi-source Replication NoSQL CassandraStorage 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 MySQL 5.5 - MariaDB 5.5 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ MySQL 5.6 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ MariaDB 10.0.5(β) ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ※ http://www.ashisuto.co.jp/product/category/database/mysql/#tab4 7
- 8. MariaDB Galera Clusterとは • MariaDBとCodership社が開発するGalera Replicationを 組み合わせたもの。 ＋ ＝ • 特徴 – – – – – 完全同期型のレプリケーション アクティブ/アクティブのマルチマスター構成 全ノードに対してRead/Writeが可能 ノード追加/削除を自動で行える クライアントからみれば普通のMySQLに見える 8
- 9. 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
- 10. MySQL Clusterとは違うの？ • 全くの別物です。 MariaDBGalera Cluster MySQL Cluster APノード Galera Replication ・完全同期型レプリケーション ・DBサーバを増やすだけでスケールアウト ・特殊なストレージエンジンは使用しない がInnoDBしか今のところ使えない データ ノード ・階層型のインメモリDB ・NDBという特殊なストレージエンジン を使用する。MySQLの知識が通用しない 10
- 11. 基本アーキテクチャ MariaDB MariaDB MariaDB wsrep API wsrep API wsrepAPI Galera Replication • wsrep(WriteSet Replication) APIがレプリケーション機 能を担当します。 • トランザクションがコミットされた段階でブロードキャスト され他ノードへ適用されます。 • クライアントはGalera Clusterを使用していることを意識 する必要はありません。 11
- 12. 同期レプリケーション BEGIN Node 1 COMMIT(REQ) Statements COMMIT(ACK/returns) Commit responsetime time WS Replication event COMMIT or Rollback OK or Conflict Node 2 WS time Certification Node 3 Trunsaction applied (Virtually synchronous) Apply event Trunsaction applied (Virtually synchronous) WS time Certification Apply event ALL Nodes 100% sync ※ http://www.slideshare.net/Severalnines/galera-cluster-for-mysql-introduction-slides 12
- 13. ノード追加 Step 1 Node 1 Node2 Step 2 Node 1 MariaDB 'Joiner' Node 3 MariaDB MariaDB Node 2 MariaDB 'Joiner' Node 3 MariaDB MariaDB SST Request ※ State Snapshot Transfer スクリプト Step 3 Node 1 Node 2 MariaDB Step 4 Node 1 MariaDB 'Joiner' Node 3 rsync send MariaDB ※ Node2は"doner mode"になり、書込みが ブロックされます。 Node 2 MariaDB MariaDB Node 3 MariaDB Catch Up 13
- 14.
- 15.
- 16. ベンチマーク • アシストさん – sysbenchによるReadOnly処理 16
- 17. ベンチマーク • もう一つアシストさん – sysbenchによるRead/Write処理 17
- 18. それぞれのベンチマーク結果からわかること • 更新処理がはいるとほとんどスケールしない。 せいぜい2～３ノードまで。それ以上になると工夫が必要か。 • sysbench、tpcc-mysqlともにデータ更新の競合による エラーやデッドロックが発生しているらしく、ちゃんとし たデータが取得できていない可能性がある。 ※ デッドロックはともかく、競合によるエラーはアプリのリトライ等で対処してほしい。。。 • では、単純にmysqlslapを使用して1ノードだけ負 荷をかけた場合、ノード数の増加によるオー バーヘッドはどの程度か調べてみた。 18
- 19.
- 20. mysqlslapの結果より • 思ったよりも同期処理のオーバーヘッドによる劣化が大 きい。 • I/Oが高速なioDrive2を使用することである程度は劣化 を抑えることができたが、それでも十分に大きなオー バーヘッドが存在する。 •LVSやAWS使用時にはELB等のロードバランサ配下に 配置して。。。という紹介がされていますが、正直それ でパフォーマンスが担保できるかどうか不安。 20
- 21. 活用するには • ロードバランサ配下に置くのではなく、MariaDB稼働 サーバでVirtual IPを立てて処理単位で振り分ける。 –オーバーヘッドは発生するが劣化は最小限に抑えられる。 • ネットワーク障害やMariaDBに障害があった際にはVIP のフェイルオーバーを行い、他ノードに処理を引き継が せる(リトライ処理は必要)。 • 2ノードの場合、別途Split-Brain対策が必要となるので 3ノードでの利用を推奨。 • これらはOSSのPacemaker+Corosync or Heartbeatで比 較的簡単に実装可能。 21
- 22. 構成概要 • PacemakerでMariaDBを管理するために、MySQL用の RA(Resource Agent)がそのまま流用可能。 •MariaDBはclone設定にて全ノードで起動するように設 定する。 • NIC障害に対しては基本的にbondingで対応するが、 ネットワーク監視を使用してVIPのフェイルオーバー等 を行えるようにする。 • ノード障害、MariaDBのプロセス障害等が発生した場 合はVIPのみフェイルオーバーさせる。(MariaDBはす でに全ノードで起動しているため) 22
- 23.
- 24.
- 25. デモ • VMware上にPacemaker+Corosyncの組み合せで3ノー ドクラスタ環境を構築しています。 • 実際に障害を起こしてみて、どのように動くのか見てい ただきます。 •今回は時間の関係上、クラスタ周りの説明はしません。 環境は異なりますが、私が作った環境の簡易説明資料 がSlideShare上に公開されていますので参考まで。 – http://www.slideshare.net/jshimi777/case-study-of-high-availability-oracle-byusing-the-io-drive-and-drbd-16662472 25