MySQL Cluster

Size: px

Start display at page:

Download "MySQL Cluster"

まれあすみい
5 years ago
Views:

1 MySQL による HA スケールアウトソリューション松信嘉範 (MATSUNOBU Yoshinori) MySQL 株式会社シニアコンサルタント 1

2 Agenda MySQL 社の紹介 HA スケールアウト技術概要 MySQL による HA スケールアウトソリューションの解説レプリケーション HA 構成パーティショニング MySQL Cluster 2

3 MySQL 社の紹介 1995 年に設立日本法人 (MySQL KK) は 2006 年 2 月に設立社員数約 400 名世界 24 カ国に在籍海外での圧倒的な人気 1,000 万以上のインストールベース 5 万ダウンロード / 日 TCO の削減を実現浮いた費用を用いて品質を向上させるアプローチも可能豊富な周辺ツール多数のパートナー企業住商情報システム様 HP 様 NTT コムウェア様スマートスタイル様 NRI 様他 3

4 MySQL を利用している企業 High Volume Websites Web 2.0 Dynamic content ecommerce Look to Book Session Management Gaming & entertainment Scale Out Enterprise Data Warehousing High-Volume OLTP Scale Out craigslist Embedded Bundled in software applications & hardware components 4

5 中大規模アプリケーションに求められるもの可用性の向上 MTBF( 平均故障間隔 ) / (MTTR( 平均修復間隔 ) + MTBF) の向上停止につながる障害を減らすこと万一障害が発生した場合は回復時間を短く済ませること冗長化構成が基本負荷分散大量のリクエストを一定時間以内に処理する垂直型 ( スケールアップ ) と水平型 ( スケールアウト ) 5

6 スケールアップ対スケールアウトスケールアップ垂直型 CPU メモリディスクの増強によってパフォーマンスを向上価格が高くなる傾向にあるスケールアウト水平型安価なハードウェアの冗長構成マシンの増加によってパフォーマンス向上アプリケーション側での対処も必要電源やスペースの費用価格と性能のバランス 1GB Memory 16 台 vs 16GB Memory 1 台 6

7 HA 構成の種類 Active/Passive(Standby) 型サービスを提供する DB サーバは 1 個 (Active 機 ) Passive 機は Active 機を監視 Active 機の停止を検知したら Passive 機はサービスを起動再開負荷分散にはならない fsck やクラッシュリカバリの時間は停止時間になる起動後はしばらくキャッシュにデータが無い状態が続くサービスレベルとしては Four Nines (99.99%) に相当 Heartbeat + SAN/DRBD + MySQL Active/Passive + Passive/Active の構成もある Active/Active 型同時に複数の DB サーバがサービスを提供停止検知の仕組みは Active/Passive 型と同等だがサービスはすぐ提供できるサービスレベルとしては Five Nines (99.999%) に相当 MySQL Cluster 7

8 MySQL による HA スケールアウトソリューションの紹介 MySQL レプリケーション MySQL の標準機能だけで実現可能参照処理はスケールアウト可能サードベンダーのクラスタソフト等との組み合わせ Heartbeat + MySQL レプリケーション L/B + MySQL レプリケーション Heartbeat + SAN + MySQL Heartbeat + DRBD + MySQL パーティショニング MySQL Cluster MySQL の機能だけで実現可能 HA スケールアウト両方を実現欧米での導入実績が豊富 5.1 で大幅な機能強化 8

9 レプリケーションとはデータベースの複製を別ノード上に作成する技術非同期レプリケーション更新マスタースレーブ同期レプリケーション更新マスターマスター 9

10 レプリケーションの分類片方向レプリケーションか双方向レプリケーションかシングルマスターかマルチマスターか非同期レプリケーションか同期レプリケーションか物理レプリケーションか論理レプリケーションか Active/Passive か Active/Active か 10

11 MySQL レプリケーションの特徴特徴マスター - スレーブ型非同期レプリケーションマスターから SQL 文をスレーブに転送して実行 (5.1 からは行コピー型と選択 / 共存可能 ) 長所追加のソフトウェアが不要参照処理をスケールアウト可能仕組みが単純でアーキテクチャ選択の幅が広い制限事項 1 個のスレーブが持てるマスターは 1 個だけ障害時にスレーブ側への反映が未完了の場合があるフェイルオーバーのための処理が手動 11

12 MySQL レプリケーションの流れ Web/App Web/App 更新 & 参照参照 Master Slave 記録反映レプリケーション ( 時間差 ) 12

13 Web/App 更新参照 Master レプリケーション memcached サーバ memcached サーバ集計分析処理など ( 重たい SQL 文 ) Slave 13

14 更新 & 参照 MySQL レプリケーションの仕組み Web/App 反映 relay log UPDATE tbl1 mysqld index & binlogs I/O Thread SQL Thread data レプリケーション binlog data MySQL Master UPDATE tbl1 mysqld MySQL Slave 14

15 参照処理のスケールアウト Web/App 更新 & 参照参照 ( 複数台 ) Master Slave s Backups 記録レプリケーション反映 Index & Bin Log Rotation スレーブの役割マスターの障害時に新マスターに昇格バックアップの代替参照処理の負荷分散スレーブの動的追加によるさらなる負荷分散 15

16 レプリケーションの手順マスター全体バックアップ InnoDB オンリーであれば $ mysqldump --user=root --password=xx -socket=xx --singletransaction --master-data=2 --flush-logs --hex-blob --default-character-set=cp932 --all-databases > xx.sql スレーブ全体バックアップのコピーリストア mysqld を起動リードオンリーの指定 : read_only サーバー ID を一意に指定 : server-id=n マスターへの接続 mysql> CHANGE MASTER TO MASTER_HOST= hostname', -> MASTER_PORT=port, MASTER_USER='repl_user', -> MASTER_PASSWORD='repl_pass', -> MASTER_LOG_FILE= binlog_file_path'; レプリケーションの開始 mysql> START SLAVE; 16

17 マスターのフェイルオーバー Master X X Web/App 手動フェイルオーバースレーブの 1 つをマスターに昇格更新 & 参照 Slave 記録 X X レプリケーション記録 Index & Bin Log Rotation 17

18 マスターのフェイルオーバーの難しさ障害を検知しフェイルオーバーする仕組みを標準では持っていないクラスタリングソフトを使う手動で作りこむアプリケーションの接続先も変えないといけないマスターの全更新情報 ( バイナリログ ) のスレーブへの転送が完了していない可能性がある非同期レプリケーションの宿命未転送のものを捨てるか手動で転送適用するか捨てる場合フェイルバックが難しい 18

19 Heartbeat + MySQL レプリケーションクラスタソフト (Heartbeat) の使用 Heart-Beat プロトコルノード間で生存確認メッセージの送受信ハートビート送受信の失敗がフェイルオーバー開始の合図シリアルケーブルによるハートビート送受信が可能 Virtual IP の管理 IP アドレスの引継ぎ管理は自動オープンソース自動フェイルオーバーが可能レプリケーションは非同期 19

20 Heartbeat + MySQL レプリケーション Web/App Master Linux Heartbeat = Virtual IP = Slave = Private IP = Replication = Private IP =

21 Heartbeat + MySQL レプリケーション ( フェイルオーバー時 ) Web/App X Master = Private IP = Linux Heartbeat = Virtual IP = X X れレプリケーション Slave フェイルオーバー = Private IP =

22 Load Balancer + MySQL レプリケーション HA とスケールアウトの両方の目的で活用可能スケールアウト目的複数台のスレーブの前に置いて負荷分散 HA 目的クラスタソフト + MySQL レプリケーション構成と類似ハードウェアベースでの Virtual IP 管理 ( ソフトウェア L/B もある ) 特徴 100:0 の振り分けルール自動フェイルオーバー非同期レプリケーション 22

23 L/B + MySQL レプリケーション (HA 目的 ) Web/App Master Load Balancer = Virtual IP = Slave = Private IP = レプリケーション = Private IP =

24 L/B + MySQL レプリケーション (HA 目的 ) Web/App X Master Load Balancer = Virtual IP = Slave フェイルオーバー = Private IP = X X レプリケーション = Private IP =

25 レプリケーションとフェイルオーバーの相性マスタースレーブのフェイルオーバースレーブの状態はマスターと同一になっていない可能性がある未完了状態のスレーブをマスターに昇格すると最新の状態が失われるマルチマスター構成でも同様の問題がある考慮事項が多く難しいマスタースレーブのフェイルオーバーではなく Active/Standby 構成のマスターのフェイルオーバー 25

26 Heartbeat + SAN + MySQL Active/Passive 型クラスタ構成同時に複数の mysqld が同じファイルにアクセスすることは不可負荷分散にならない自動フェイルオーバー Virtual IP ファイルシステムのマウント mysqld の起動データが 1 箇所なので不整合の問題が発生しないフェイルバックもより簡単になるその他の特徴初期設定はより複雑になるハードウェア費用が高価クラッシュリカバリに関わるリカバリ時間の考慮が必要フェイルオーバー直後はキャッシュが無いためパフォーマンスに注意多くの SAN ベンダーによる実績がある 26

27 Heartbeat + SAN + MySQL Web/App Active Cluster Management = Virtual IP = Passive Cluster Agent Cluster Agent = Private IP = = Private IP = SAN 27

28 Heartbeat + SAN + MySQL Web/App X Active Cluster Agent Cluster Management = Virtual IP = X X Passive Active Cluster Agent = Private IP = SAN = Private IP =

29 Heartbeat + DRBD + MySQL ディスクミラーソフト (DRBD) ディスクをマシンごとに分散配置し片方向物理レプリケーション ( ネットワーク RAID1) 特別なハードウェアが不要 ( 通常の IP ネットワーク上で動作 ) 同期レプリケーションオープンソース MySQL Enterprise ではオプションでサポートレプリケーション性能は良い (SQL 文のレイヤーを回避 ) Active/Passive 型クラスタ構成と同等で負荷分散にはならないミラーされている側はファイルシステムのマウントすらできない自動フェイルオーバーが可能同期レプリケーションなので不整合の問題が発生しないフェイルバックもより簡単になる 29

30 Heartbeat + DRBD + MySQL Web/App Active Linux Heartbeat = Virtual IP = Passive = Private IP = = Private IP = Primary DRBD DRBD Secondary DRBD 30

31 Heartbeat + DRBD + MySQL Web/App X Active Linux Heartbeat = Virtual IP = Passive Active = Private IP = Primary DRBD X X DRBD = Private IP = Secondary DRBD Primary DRBD 31

32 Active/Passive + Passive/Active 2 台のマシンに Active/Passive アプリと Passive/Active アプリを用意それぞれのマシン上でそれぞれアプリが動いている状態マシンが無駄になることが無いフェイルオーバー時には 2 つのアプリが 1 台のマシン上で同時に動く 32

33 まとめと応用参照処理のスケールアウトのために MySQL レプリケーションマスターの自動フェイルオーバーのためにクラスタソフトマスターの不整合回避のために共有ディスク (SAN) または同期レプリケーション (DRBD) これらの組み合わせも可能 ( 次項 ) 33

34 Heartbeat + DRBD + MySQL レプリケーション + L/B Web/App Writes & Reads Web/App Active Master Linux Heartbeat Passive Master Primary DRBD Secondary DRBD Slave Slave Slave Load Balancer Web/App Web/App Reads Web/App Web/App 34

35 ストレージエンジンによる違い InnoDB NDB Falcon mysqld の起動時に自動でリカバリ ( クラッシュリカバリ ) リカバリ時間はデータ量には依存しない通常は非常に高速 Falcon も同様仕組みは違うが NDB も自動でリカバリする MyISAM テーブルが破損している場合がある myisamchk rq REPAIR TABLE で復旧自動でのリカバリはしない (my.cnf で --myisam-recover の設定 ) リカバリ時間はデータ量に比例する MEMORY mysqld の停止によってレコードは消失する 35

36 MySQL Enterprise によるサポート Heartbeat + DRBD のサポートを MySQL より提供 DRBDについてはビルド済みバイナリを提供 MySQLが問い合わせを一次受け開発元のLinbitにリダイレクト 24 時間 7 MySQL Enterprise Gold 以上でオプションとして提供サブスクリプション費用は50% 増 MySQL Enterprise Gold: 2,999USD/Year 1.5 MySQL Enterprise Platinum: 4,999USD/Year

37 大規模環境でよく使われるソリューション Heartbeat + DRBD + MySQL レプリケーション + L/B パーティショニング MySQL Cluster 37

38 パーティショニング Web/App Web/App 1. アクセス先ルックアップ 2. 対象サーバにアクセス ID 範囲 1~100 万 ~200 万 ~300 万 ( 以下同様 ) 対象サーバ Master/Slave1 Master/Slave2 Master/Slave3 ( 以下同様 ) Master1 Master2,3, マッピングテーブルハッシュ機能別 Slave Slave レコード数による分割テーブルの種類による分割アプリの種類による分割 38

39 パーティショニングの考慮事項いつパーティショニングするかタイミングを決めるレスポンスタイムの平均値ロードアベレージタイミングを遅らせる工夫アプリが複雑になり障害切り分けも難しくなるのでパーティショニングを避けられるのであれば避ける ( 遅らせる ) ある程度のスケールアップをする ( 特にメモリ ) 32bit 機の 2GB Memory <<<< 64bit 機の 16GB Memory RAID 1+0 パフォーマンスチューニングをする 50%~100% の性能向上は珍しくない my.cnf のパラメータによる影響は大きい SQL 文の処理効率 5.1 のパーティショニング機能ハッシュ主キーレンジリスト複合型すべてのストレージエンジンでサポートディスク I/O ボトルネックの軽減に効果的 39

40 5.1 のパーティショニング機能の効果 mysql> CREATE TABLE part_tab -> ( c1 int,c2 varchar(30),c3 date ) -> PARTITION BY RANGE (year(c3)) (PARTITION p0 VALUES LESS THAN (1995), -> PARTITION p1 VALUES LESS THAN (1996), PARTITION p2 VALUES LESS THAN (1997), -> PARTITION p3 VALUES LESS THAN (1998), PARTITION p4 VALUES LESS THAN (1999), -> PARTITION p5 VALUES LESS THAN (2000), PARTITION p6 VALUES LESS THAN (2001), -> PARTITION p7 VALUES LESS THAN (2002), PARTITION p8 VALUES LESS THAN (2003), -> PARTITION p9 VALUES LESS THAN (2004), PARTITION p10 VALUES LESS THAN (2010), -> PARTITION p11 VALUES LESS THAN MAXVALUE ); mysql> create table no_part_tab (c1 int,c2 varchar(30),c3 date); *** 800 万行をロード *** mysql> select count(*) from no_part_tab where c3 > date ' ' and c3 < date ' '; count(*) row in set (38.30 sec) mysql> select count(*) from part_tab where c3 > date ' ' and c3 < date ' '; count(*) row in set (3.88 sec) 90% の性能改善 40

41 MySQL Cluster シェアードナッシング型クラスタ同期レプリケーションインメモリで動作するため非常に高速 5.1 からはデータ領域をディスクに置くことも可能スケールアウト可能高速なフェイルオーバー ( 秒単位のレベル ) 追加のソフトウェアが不要クラスタソフトの機能を MySQL Cluster 自身が実装している特殊なハードウェアが不要詳しくは次のセッションで 41

42 MySQL コンサルティングサービス MySQLアーキテクチャデザイン MySQL Scale-out, HA and Replication Jumpstart MySQL Cluster Jumpstart MySQLパフォーマンスチューニング MySQLデータベース管理 MySQLマイグレーション MySQL Time Hire その他 MySQLの専門知識が必要なもの全般 42

43 MySQL User Conference Tokyo 2007 年 9 月 11 日 ( 火 ) 12 日 ( 水 ) 日本科学未来館 ( 東京お台場 ) にて開催 Marten Mickos Brian Aker らが来日予定事前登録無料間もなく申込み開始 43

Microsoft PowerPoint - MySQL-backup.ppt

Microsoft PowerPoint - MySQL-backup.ppt MySQL バックアップリカバリ概要オープンソースコンピテンシコンピテンシセンター日本ヒューレットパッカードヒューレットパッカード株式会社 2006 年 12 月 6 日 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice