OSC 2017 Osaka MySQL 落ちないDBサーバの作り方

Slide 1

Slide 1 text

MySQL 落ちないDBサーバの作り方～マスター・スレーブ構成だけじゃない～ 2017/01/28 OSC 2017 Osaka 日本MySQL ユーザ会 @mita2

Slide 2

Slide 2 text

自己紹介 2 • 三谷智史（Twitter: @mita2） • 日本MySQLユーザ会（MyNA） • OSCで講演は初めてです • Web系企業で、たくさんのMySQLを管理 • MySQLとの関わり 2002年～主に利用して開発する立場 2010年～主に管理する立場

Slide 3

Slide 3 text

対象者 3 • 本日は冗長構成のパターンや考え方をご紹介します • 具体的な設定方法はあまり書いてないです • クラウドの話は出てきません・・・ • 初心者向け

Slide 4

Slide 4 text

本日の内容 • DBサーバの構成パターンとメリット・デメリット 1. 共有ストレージ 2. ディスク同期（DRBD） 3. スレーブのマスター昇格 4. Group Replication • クライアント側で意識してほしいこと • 日本 MySQLユーザ会のご紹介 4

Slide 5

Slide 5 text

本日の内容 • DBサーバの構成パターンとメリット・デメリット 1. 共有ストレージ 2. ディスク同期（DRBD） 3. スレーブのマスター昇格 4. Group Replication • クライアント側で意識してほしいこと • 日本 MySQLユーザ会のご紹介 5

Slide 6

Slide 6 text

クラスタソフトクラスタソフト共有ストレージ • DBの世界では伝統的な方法 • データファイルを共有ストレージに置く • クラスタソフトでActive/Passive の切り替え 6 共有ストレージ (SAN/NAS) 共有ストレージ (SAN/NAS) DBサーバ DBサーバ DBサーバ（待機） DBサーバ（待機）ファイルファイルファイルファイルファイルファイル mysqld mysqld VIP VIP iSCSI, NFS

Slide 7

Slide 7 text

クラスターソフトウェア • 障害を検知し、リソースをスタンバイ機で立ち上げる • リソース＝プロセスやIP • 代表的なソフトウェア • OSS: Pacemaker+Corosync (Heatbeat) • 商用：Veritas Cluster, SIOS Life Keeper, Oracle Clusterware, NEC CLUSERPRO etc… • 自作しようと思うと案外大変 • リソースの依存関係 • 排他制御 • 半死、スプリットブレインなど綺麗に落ちなかったときの考慮 etc… 7

Slide 8

Slide 8 text

共有ストレージところで、ストレージ落ちたらどうするん？ 8 クラスタソフトクラスタソフト共有ストレージ (SAN/NAS) 共有ストレージ (SAN/NAS) DBサーバ DBサーバ DBサーバ（待機） DBサーバ（待機）ファイルファイルファイルファイルファイルファイル mysqld mysqld VIP VIP iSCSI, NFS

Slide 9

Slide 9 text

共有ストレージ SAN/NAS • 冗長性が担保されているエンタープライズ製品が前提 • NetApp, Dell EMC, HP, IBM etc… • エンタープライズと言っても、比較的、安価なものもある • ブロックIOに強い製品を選ぶ – ファイルサーバ用途は不向き 9 たくさんの DISK たくさんの DISK コントローラコントローラコントローラコントローラたくさんの DISK たくさんの DISK スイッチスイッチスイッチスイッチ DBサーバ DBサーバ DBサーバ DBサーバストレージの構成イメージ

Slide 10

Slide 10 text

クラッシュリカバリ • MySQLが異常終了後、起動時に行う処理 • データファイルの整合性を取り戻す • 時間は iblog(更新ログ）のサイズと更新量に依存する 10 フェイルオーバー時に起動に時間がかかる

Slide 11

Slide 11 text

11 共有ストレージメリ・デメ

Slide 12

Slide 12 text

共有ストレージメリット • 障害時のデータロストのリスクがない • レプリケーション遅延の考慮が不要 • （商用ストレージ便利） 12 MySQL 5.7でロスレス準同期レプリの登場により他の手段でもデータロストなく運用可能に MySQL 5.7でロスレス準同期レプリの登場により他の手段でもデータロストなく運用可能に

Slide 13

Slide 13 text

共有ストレージデメリット • 切り替わりに（ほかと比べて）時間がかかる • 分単位は見込んだほうが良い • ファイルシステムの破損に対応できない • バックアップで対応することになる • Web上に具体的な情報があまりない • 個人では難しい・・・ 13

Slide 14

Slide 14 text

本日の内容 • DBサーバの構成パターンとメリット・デメリット 1. 共有ストレージ 2. ディスク同期（DRBD） 3. スレーブのマスター昇格 4. Group Replication • クライアント側で意識してほしいこと • 日本 MySQLユーザ会のご紹介 14

Slide 15

Slide 15 text

DRBD＋クラスターソフトウェア • DBサーバのディスクを他筐体にミラー 15 • Distributed Replicated Block Device • ブロックデバイス（ディスク）をネットワークを通じて複製するOSS DBサーバ DBサーバ DBサーバ（待機） DBサーバ（待機） mysqld mysqld VIP VIP

Slide 16

Slide 16 text

DRBD＋クラスターソフトウェア • クラスタソフトでActive/Passive の切り替え • DRBD + Pacemaker/Corosync • Oracle も公式にサポート対象 16 https://dev.mysql.com/doc/refman/5.6/ja/ha-drbd.html より引用

Slide 17

Slide 17 text

17 ディスク同期メリ・デメ

Slide 18

Slide 18 text

ディスク同期メリット • 障害時のデータロストのリスクがない • レプリケーション遅延の考慮が不要 • 商用ストレージと比較して安価に始められる 18

Slide 19

Slide 19 text

ディスク同期デメリット • 切り替わりに（ほかと比べて）時間がかかる • ファイルシステムの破損に対応できない 19

Slide 20

Slide 20 text

参考資料 • CentOS アプライアンスでの DRBD MySQL クラスタ • http://wiki.pandorafms.com/index.php?title=Pandora:Documentation_ja:DRBD_Appliance 20

Slide 21

Slide 21 text

本日の内容 • DBサーバの構成パターンとメリット・デメリット 1. 共有ストレージ 2. ディスク同期（DRBD） 3. スレーブのマスター昇格 4. Group Replication • クライアント側で意識してほしいこと • 日本 MySQLユーザ会のご紹介 21

Slide 22

Slide 22 text

22 MySQL レプリケーションおさらい

Slide 23

Slide 23 text

マスター・スレーブ • レプリケーション＝複製を作る • マスター • 更新を受け付けるサーバ • スレーブ • コピー、読み取り専用 • 用途 • 読み取り性能のスケールアウト • バックアップ取得用など使い分け • マスター障害の際の切り替え先 • etc… 23 マスターマスタースレーブスレーブスレーブスレーブクライアントクライアント

Slide 24

Slide 24 text

Global Transaction ID • トランザクションに一意のIDを付与 • サーバUUID + 連番 • 08c8c338-f529-11e3-8182-fa163e64b6a2:1 • マスターは「更新内容＋GTID」をログファイルに記録 • スレーブは「どのマスター」の「どのトランザクション」までコピーしたかを識別できる 24

Slide 25

Slide 25 text

実際の更新ログの内容 # at 248449 #161202 14:46:59 server id 2759935033 end_log_pos 248497 CRC32 0xc9775906 GTID [commit=yes] SET @@SESSION.GTID_NEXT= '8b4227e8-b841-11e6-845c-448a5bf50581:269'/*!*/; # at 248497 #161202 14:46:59 server id 2759935033 end_log_pos 248590 CRC32 0x0892442a Query thread_id=179 exec_time=0 error_code=0 SET TIMESTAMP=1480657619/*!*/; BEGIN /*!*/; # at 248590 #161202 14:46:59 server id 2759935033 end_log_pos 248740 CRC32 0x83437cc8 Query thread_id=179 exec_time=0 error_code=0 SET TIMESTAMP=1480657619/*!*/; insert into tbl(col1) values ('Fri Dec 2 14:46:59 2016') /*!*/; # at 248740 #161202 14:46:59 server id 2759935033 end_log_pos 248771 CRC32 0x132b63f8 Xid = 1051 COMMIT/*!*/; 25

Slide 26

Slide 26 text

レプリケーションの流れ 26 • バイナリログ • 更新ログ • IOスレッド • 更新ログをマスターから受け取る • リレーログ • 受け取ったログ • SQLスレッド • リレーログからSQLを読み出し、適用するストレージエンジンストレージエンジンバイナリログバイナリログコネクションスレッドコネクションスレッド I/O スレッド I/O スレッドリレーログリレーログストレージエンジンストレージエンジン SQL スレッド SQL スレッドマスタースレーブ Client Client

Slide 27

Slide 27 text

スレーブを使ったフェイルオーバーマスター (a) マスター (a) スレーブ (b) スレーブ (b) スレーブ (c) スレーブ (c) aaa-aaa:1 aaa-aaa:2 aaa-aaa:3 aaa-aaa:1 aaa-aaa:2 aaa-aaa:3 aaa-aaa:1 aaa-aaa:2 aaa-aaa:3 aaa-aaa:1 aaa-aaa:2 aaa-aaa:3 aaa-aaa:1 aaa-aaa:2 aaa-aaa:1 aaa-aaa:2 クライアントクライアント 1. 一番進んでいるスレーブを探す – SHOW GLOBAL VARIABLES LIKE ‘GTID_EXECUTED’ – 新マスターとする 2. スレーブでCHANGE MASTER TO MASTER_HOST=‘’を実行し、新マスターを向ける 3. read_only を解除し、クライアントからのアクセスを新マスターに向けるマスター (a) マスター (a) 新マスター (b) 新マスター (b) スレーブ (c) スレーブ (c) aaa-aaa:1 aaa-aaa:2 aaa-aaa:3 aaa-aaa:1 aaa-aaa:2 aaa-aaa:3 aaa-aaa:1 aaa-aaa:2 aaa-aaa:3 aaa-aaa:1 aaa-aaa:2 aaa-aaa:3 aaa-aaa:1 aaa-aaa:2 aaa-aaa:1 aaa-aaa:2 クライアントクライアントマスター (a) マスター (a) 新マスター (b) 新マスター (b) スレーブ (c) スレーブ (c) aaa-aaa:1 aaa-aaa:2 aaa-aaa:3 aaa-aaa:1 aaa-aaa:2 aaa-aaa:3 aaa-aaa:1 aaa-aaa:2 aaa-aaa:3 bbb-bbb:1 aaa-aaa:1 aaa-aaa:2 aaa-aaa:3 bbb-bbb:1 aaa-aaa:1 aaa-aaa:2 aaa-aaa:3 bbb-bbb:1 aaa-aaa:1 aaa-aaa:2 aaa-aaa:3 bbb-bbb:1 クライアントクライアント

Slide 28

Slide 28 text

一連の動作を自動で行うツールたち • ツール用のmanager サーバを別で用意 • MHA for MySQL • Master High Availability Manager and tools for MySQL • mysqlfailover • MySQL Utilities 28 マスター (a) マスター (a) スレーブ (b) スレーブ (b) スレーブ (c) スレーブ (c) aaa-aaa:1 aaa-aaa:2 aaa-aaa:3 aaa-aaa:1 aaa-aaa:2 aaa-aaa:3 aaa-aaa:1 aaa-aaa:2 aaa-aaa:3 aaa-aaa:1 aaa-aaa:2 aaa-aaa:3 aaa-aaa:1 aaa-aaa:2 aaa-aaa:1 aaa-aaa:2 Manager Manager

Slide 29

Slide 29 text

MHA • 松信さんがつくったツール • 豊富な実績、Web上に資料が豊富 • 最近はメンテナンスモード • クラッシュセーフスレーブと組み合わせて利用できない • DBサーバへSSHを行う。DBサーバ側にもagentが必要。 29

Slide 30

Slide 30 text

mysqlfailover • Oracle 社の公式ツール • DBサーバへのSSHやagentのインストール不要 • SQLで完結 30

Slide 31

Slide 31 text

MySQL レプリケーションの種類 1. 非同期レプリケーション 2. 準同期レプリケーション – Ver 5.5～ 3. ロスレス準同期レプリケーション – Ver 5.7～ 31

Slide 32

Slide 32 text

非同期レプリケーション 32 1. クライアントがCOMMIT 2. バイナリログに更新内容を記録 3. ストレージエンジンに更新内容を記録 4. クライアントにACKを返す 5. リレーログに記録ストレージエンジンストレージエンジンバイナリログバイナリログコネクションスレッドコネクションスレッド I/O スレッド I/O スレッドリレーログリレーログストレージエンジンストレージエンジン SQL スレッド SQL スレッドマスタースレーブ Client Client

Slide 33

Slide 33 text

準同期レプリケーション 33 1. クライアントがCOMMIT 2. バイナリログに更新内容を記録 3. ストレージエンジンに更新内容を記録 4. リレーログに記録 5. クライアントにACKを返すストレージエンジンストレージエンジンバイナリログバイナリログコネクションスレッドコネクションスレッド I/O スレッド I/O スレッドリレーログリレーログストレージエンジンストレージエンジン SQL スレッド SQL スレッドマスタースレーブ Client Client rpl_semi_sync_master_wait_point=AFTER_COMMIT 準同期する台数を指定できる準同期する台数を指定できる

Slide 34

Slide 34 text

ロスレス準同期レプリケーション 34 1. クライアントがCOMMIT 2. バイナリログに更新内容を記録 3. リレーログに記録 4. ストレージエンジンに更新内容を記録 5. クライアントにACKを返すストレージエンジンストレージエンジンバイナリログバイナリログコネクションスレッドコネクションスレッド I/O スレッド I/O スレッドリレーログリレーログストレージエンジンストレージエンジン SQL スレッド SQL スレッドマスタースレーブ Client Client rpl_semi_sync_master_wait_point=AFTER_SYNC 準同期する台数を指定できる準同期する台数を指定できる

Slide 35

Slide 35 text

フェイルオーバー時のデータロスト • 非同期レプリケーション – データロストのリスクがあるが、レイテンシがない • 準同期レプリケーション – データロストのリスクはあるが小さい、レイテンシはある • ロスレス準同期レプリケーション – データロストのリスクない、レイテンシはある 35

Slide 36

Slide 36 text

36 マスター昇格メリデメ

Slide 37

Slide 37 text

マスター昇格メリット • 切り替わりが早い • ファイルシステムの破損に対応できる • 安価に始められる • 待機系のサーバを利用できる • 公開されている情報が多め 37

Slide 38

Slide 38 text

マスター昇格デメリット • レプリケーション遅延のリスクを考える必要がある 38

Slide 39

Slide 39 text

本日の内容 • DBサーバの構成パターンとメリット・デメリット 1. 共有ストレージ 2. ディスク同期（DRBD） 3. スレーブのマスター昇格 4. Group Replication • クライアント側で意識すべきこと • 日本 MySQLユーザ会のご紹介 39

Slide 40

Slide 40 text

Group Replication • 次のメジャーバージョン(8.0) で入ると思いきや、12月の 5.7.17で入ってきたヤツ！ 40

Slide 41

Slide 41 text

高可用性ソリューション • マルチライター構成が組める • 高可用性ソリューション • 性能向上を主目的としたものではない 41 Master Master Master Master Master Master Master Master Master Master UPDATE t SET col = ‘B’ WHERE pk = 2 UPDATE t SET col = ‘B’ WHERE pk = 2 UPDATE t SET col = ‘A’ WHERE pk = 1 UPDATE t SET col = ‘A’ WHERE pk = 1

Slide 42

Slide 42 text

高可用性ソリューション • マルチライター構成が組める • 高可用性ソリューション • 性能向上を主目的としたものではない 42 Master Master Master Master Master Master Master Master Master Master UPDATE t SET col = ‘B’ WHERE pk = 2 UPDATE t SET col = ‘B’ WHERE pk = 2 UPDATE t SET col = ‘A’ WHERE pk = 1 UPDATE t SET col = ‘A’ WHERE pk = 1

Slide 43

Slide 43 text

マルチライター 43 マスター (a) マスター (a) スレーブスレーブスレーブスレーブマスター (a) マスター (a) マスターマスターマスターマスター Read Write Read Write Read Write Read Write Read Write Read Write これまでのレプリケーション Group Replication Write Write Read Read Read Read

Slide 44

Slide 44 text

障害検知の仕組みがビルドイン 44 Master Master Master Master Master Master Master Master Master Master • 障害を自動検知し、データ同期対象から切り離す • 復旧時には差分を自動的にリカバリ

Slide 45

Slide 45 text

45 Group Replication とロックの挙動

Slide 46

Slide 46 text

非 Group Replication 構成の場合 46 時間行の値トランザクション１トランザクション２ T1 - mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘A' WHERE pk = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 T2 - mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘B' WHERE pk = 1; T3 - トランザクション１のロック開放待ち T4 A mysql> COMMIT; Query OK, 0 rows affected (0.00 sec) トランザクション１のロック開放待ち T5 A Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 T6 B mysql> COMMIT; Query OK, 0 rows affected (0.00 sec)

Slide 47

Slide 47 text

非 Group Replication 構成の場合 47 時間行の値トランザクション１トランザクション２ T1 - mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘A' WHERE pk = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 T2 - mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘B' WHERE pk = 1; T3 - トンラザクション1のロック開放待ち T4 A mysql> COMMIT; Query OK, 0 rows affected (0.00 sec) トランザクション１のロック開放待ち T5 A Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 T6 B mysql> COMMIT; Query OK, 0 rows affected (0.00 sec) • 更新は１ノード（マスター）に対してのみ実行可 • ロックが競合した場合、後続は「待つ」 • 更新は１ノード（マスター）に対してのみ実行可 • ロックが競合した場合、後続は「待つ」

Slide 48

Slide 48 text

Group Replication 構成の場合 48 時間行の値トランザクション１ on ノード1 トランザクション２ on ノード2 T1 - mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘A' WHERE pk = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 T2 - mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘B' WHERE pk = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 T3 A mysql> COMMIT; Query OK, 0 rows affected (0.00 sec) (ノード１の更新内容が伝わってくる） T4 A mysql> COMMIT; ERROR 1180 (HY000): Got error 149 during COMMIT

Slide 49

Slide 49 text

Group Replication 構成の場合 49 時間行の値トランザクション１ on ノード1 トランザクション２ on ノード2 T1 - mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘A' WHERE pk = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 T2 - mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘B' WHERE pk = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 T3 A mysql> COMMIT; Query OK, 0 rows affected (0.00 sec) T4 A mysql> COMMIT; ERROR 1180 (HY000): Got error 149 during COMMIT • 異なるノードでロックが競合した場合、「先取り」 • 更新量が少なければ多くはリトライで解決する • 同じノードであれば、非GR構成と同じ挙動 • 異なるノードでロックが競合した場合、「先取り」 • 更新量が少なければ多くはリトライで解決する • 同じノードであれば、非GR構成と同じ挙動

Slide 50

Slide 50 text

回避方法 50 Master Master Read only Master Read only Master Read only Master Read only Master Single Primary モード • 従来のマスター/スレーブに相当 • 任意の1台のみWriteが可能になる Master Master Master Master Master Master Multi Writer モード • 全部に読み書き • 最大限の可用性 group_replication_single_primary_mode=FALSE group_replication_single_primary_mode=TRUE

Slide 51

Slide 51 text

分散方法 • MySQL Router • Oracle 純正 • Version 2.1 でサポートされる予定 • まだ正式リリースされてない • HA Proxy • OSSのソフトウェアロードバランサ • Group Replication 用のヘルスチェックスクリプトがある • http://lefred.be/content/mysql-group-replication-as-ha- solution/ 51 マスター (a) マスター (a) マスターマスターマスターマスター Load Balancer Load Balancer Client Client

Slide 52

Slide 52 text

52 flow control

Slide 53

Slide 53 text

flow control • ノード間の遅延を最小限にする仕組み • 遅れたノードがほかのノードに「待った」をかける • 閾値の設定 53 mysql> SHOW GLOBAL VARIABLES LIKE '%flow%threshold%'; +----------------------------------------------------+-------+ | Variable_name | Value | +----------------------------------------------------+-------+ | group_replication_flow_control_applier_threshold | 1000 | | group_replication_flow_control_certifier_threshold | 2000 | +----------------------------------------------------+-------+

Slide 54

Slide 54 text

Certification と Apply 54 1 1 2 2 3 3 UPDATE Certification Certification http://mysqlhighavailability.com/mysql-group-replication-transaction-life-cycle-explained/ Certification Certification Apply Apply OK OK 更新する内容を伝える更新する内容を伝える Apply Apply Apply Apply

Slide 55

Slide 55 text

テスト • 3台中1台に向けてベンチマークを流す • ベンチを流しているノードと違うノードでDISK IOを絞る 55 1 1 2 2 3 3 sysbench

Slide 56

Slide 56 text

テスト結果 56 0 50 100 150 200 250 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 73 75 77 79 81 sysbench oltp TPS → 時間 IO制限

Slide 57

Slide 57 text

テスト結果 57 0 50 100 150 200 250 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 73 75 77 79 81 sysbench oltp TPS → 時間キューが閾値に達するまでの時間キューが閾値に達するまでの時間

Slide 58

Slide 58 text

58 MGR 設定手順

Slide 59

Slide 59 text

STEP1: インストールとユーザ作成 59 • レプリケーションユーザを作成しておく • この時点でbinlogはまだ有効化してはいけない mysql> CREATE USER 'rpl_user'@'%' IDENTIFIED BY 'rpl_pass'; mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';

Slide 60

Slide 60 text

STEP2-1：レプリケーション設定 • GTID • log-slave-updates • {master,relay}-log-info-repository=TABLE • binlog-format=row 60 server_id=1 gtid_mode=ON enforce_gtid_consistency=ON master_info_repository=TABLE relay_log_info_repository=TABLE binlog_checksum=NONE log_slave_updates=ON log_bin=binlog binlog_format=ROW

Slide 61

Slide 61 text

STEP2-2：Group Replication 設定 61 # Group Replication の設定 transaction_write_set_extraction=XXHASH64 # SELECT UUID() で生成した任意のUUIDを指定 loose-group_replication_group_name="87e5ed8c-cd83-11e6-bc3c-fa163e83e8e7" loose-group_replication_start_on_boot=off # 自分のIPアドレス loose-group_replication_local_address= "172.21.134.26:24901" # すべてのサーバを並べる loose-group_replication_group_seeds= "172.21.134.26:24901,172.21.134.27:24901,172.21.134.28:24901" loose-group_replication_bootstrap_group= off loose-group_replication_single_primary_mode=FALSE loose-group_replication_enforce_update_everywhere_checks= TRUE # サーバ間の通信に利用するネットワークを許可する loose-group_replication_ip_whitelist = 172.21.134.0/23

Slide 62

Slide 62 text

STEP3：Group Replication 開始 62 mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='rpl_pass' FOR CHANNEL 'group_replication_recovery'; Query OK, 0 rows affected, 2 warnings (0.02 sec) mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so'; Query OK, 0 rows affected (0,01 sec) mysql> SHOW PLUGINS; | group_replication | ACTIVE | GROUP REPLICATION | group_replication.so | | validate_password | ACTIVE | VALIDATE PASSWORD | validate_password.so | +--------------------+--------+-------------------+----------------------+ 46 rows in set (0.01 sec) • group_replication_recovery を設定

Slide 63

Slide 63 text

STEP4：Group Replication 開始 63 mysql> SET GLOBAL group_replication_bootstrap_group=ON; Query OK, 0 rows affected (0.00 sec) mysql> START GROUP_REPLICATION; Query OK, 0 rows affected (1.76 sec) mysql> SET GLOBAL group_replication_bootstrap_group=OFF; Query OK, 0 rows affected (0.00 sec) • group_replication_bootstrap_group=ON は最初の1台だけ

Slide 64

Slide 64 text

Slide 65

Slide 65 text

MGR 制限事項 • InnoDB のみサポート • PK or UNIQUE キーが必須 • GTID + ROW ベースレプリケーション • トランザクション分離レベルはREAD-COMMITED • 複数の同じテーブルに対するDDLとDMLはサポート外 65 ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin

Slide 66

Slide 66 text

66 Group Replicationメリデメ

Slide 67

Slide 67 text

Group Replication メリット • 構成が最もシンプル • 物理サーバの役割が平等 • 障害検知の仕組みがビルドインされている • 切り替わりが高速 • 切り離しだけ • 待機系のサーバを利用できる • レプリケーション遅延を最小限に抑えることが可能 67

Slide 68

Slide 68 text

Group Replication デメリット • （マルチライターで使う場合）ロックの競合の考慮が必要 • InnoDBしか使えない 68

Slide 69

Slide 69 text

本日の内容 • DBサーバの構成パターンとメリット・デメリット 1. 共有ストレージ 2. ディスク同期（DRBD） 3. スレーブのマスター昇格 4. Group Replication • クライアント側で意識してほしいこと • 日本 MySQLユーザ会のご紹介 69

Slide 70

Slide 70 text

クライアント側で意識してほしいこと • どんなにサーバ側で対策してもダウンゼロは無理 • 関係者でSLAを合意しておく • 実装 – 正しくエラーハンドリングをする – リトライ処理を入れる 70

Slide 71

Slide 71 text

71 まとめ

Slide 72

Slide 72 text

結局オススメどれ？ • 今からやるならGroup Replication を試してほしい 72

Slide 73

Slide 73 text

73 日本MySQL ユーザ会について

Slide 74

Slide 74 text

ご案内 • MySQL Casual Slack • https://t.co/QobukOxvUw 74 • 日本MySQL ユーザ会 ML • http://mysql.gr.jp/ml.html

Slide 75

Slide 75 text

75 ありがとうございました