osc 2017 osaka mysql 落ちないdbサーバの作り方
Post on 13-Apr-2017
2.629 Views
Preview:
TRANSCRIPT
MySQL 落ちないDBサーバの作り方~マスター・スレーブ構成だけじゃない~
2017/01/28 OSC 2017 Osaka日本MySQL ユーザ会 @mita2
自己紹介
2
• 三谷 智史(Twitter: @mita2)
• 日本MySQLユーザ会(MyNA)
• OSCで講演は初めてです
• Web系企業で、たくさんのMySQLを管理
• MySQLとの関わり2002年~ 主に利用して開発する立場2010年~ 主に管理する立場
対象者
3
• 本日は冗長構成のパターンや考え方をご紹介します
• 具体的な設定方法はあまり書いてないです
• クラウドの話は出てきません・・・
• 初心者向け
本日の内容
• DBサーバの構成パターンとメリット・デメリット
1. 共有ストレージ
2. ディスク同期(DRBD)
3. スレーブのマスター昇格
4. Group Replication
• クライアント側で意識してほしいこと
• 日本 MySQLユーザ会のご紹介
4
本日の内容
• DBサーバの構成パターンとメリット・デメリット
1. 共有ストレージ
2. ディスク同期(DRBD)
3. スレーブのマスター昇格
4. Group Replication
• クライアント側で意識してほしいこと
• 日本 MySQLユーザ会のご紹介
5
クラスタソフトクラスタソフト
共有ストレージ
• DBの世界では伝統的な方法
• データファイルを共有ストレージに置く
• クラスタソフトでActive/Passive の切り替え
6
共有ストレージ(SAN/NAS)
共有ストレージ(SAN/NAS)
DBサーバDBサーバDBサーバ(待機)DBサーバ(待機)
ファイルファイルファイルファイルファイルファイル
mysqldmysqldVIPVIP
iSCSI, NFS
クラスターソフトウェア
• 障害を検知し、リソースをスタンバイ機で立ち上げる
• リソース=プロセスやIP
• 代表的なソフトウェア• OSS: Pacemaker+Corosync (Heatbeat)
• 商用:Veritas Cluster, SIOS Life Keeper, Oracle Clusterware, NEC CLUSERPRO etc…
• 自作しようと思うと案外大変• リソースの依存関係
• 排他制御
• 半死、スプリットブレインなど綺麗に落ちなかったときの考慮 etc…
7
共有ストレージ
ところで、ストレージ落ちたらどうするん?
8
クラスタソフトクラスタソフト
共有ストレージ(SAN/NAS)
共有ストレージ(SAN/NAS)
DBサーバDBサーバDBサーバ(待機)DBサーバ(待機)
ファイルファイルファイルファイルファイルファイル
mysqldmysqldVIPVIP
iSCSI, NFS
共有ストレージ SAN/NAS
• 冗長性が担保されているエンタープライズ製品が前提
• NetApp, Dell EMC, HP, IBM etc…
• エンタープライズと言っても、比較的、安価なものもある
• ブロックIOに強い製品を選ぶ
– ファイルサーバ用途は不向き
9
たくさんのDISK
たくさんのDISK
コントローラコントローラ コントローラコントローラ
たくさんのDISK
たくさんのDISK
スイッチスイッチ スイッチスイッチ
DBサーバDBサーバ DBサーバDBサーバ
ストレージの構成イメージ
クラッシュリカバリ
• MySQLが異常終了後、起動時に行う処理
• データファイルの整合性を取り戻す
• 時間は iblog(更新ログ)のサイズと更新量に依存する
10
フェイルオーバー時に起動に時間がかかる
11
共有ストレージ メリ・デメ
共有ストレージ メリット
• 障害時のデータロストのリスクがない
• レプリケーション遅延の考慮が不要
• (商用ストレージ便利)
12
MySQL 5.7でロスレス準同期レプリの登場により他の手段でもデータロス
トなく運用可能に
MySQL 5.7でロスレス準同期レプリの登場により他の手段でもデータロス
トなく運用可能に
共有ストレージ デメリット
• 切り替わりに(ほかと比べて)時間がかかる
• 分単位は見込んだほうが良い
• ファイルシステムの破損に対応できない
• バックアップで対応することになる
• Web上に具体的な情報があまりない
• 個人では難しい・・・
13
本日の内容
• DBサーバの構成パターンとメリット・デメリット
1. 共有ストレージ
2. ディスク同期(DRBD)
3. スレーブのマスター昇格
4. Group Replication
• クライアント側で意識してほしいこと
• 日本 MySQLユーザ会のご紹介
14
DRBD+クラスターソフトウェア
• DBサーバのディスクを他筐体にミラー
15
• Distributed Replicated Block Device
• ブロックデバイス(ディスク)をネットワークを通じて複製するOSS
DBサーバDBサーバ DBサーバ(待機)DBサーバ(待機)
mysqldmysqldVIPVIP
DRBD+クラスターソフトウェア
• クラスタソフトでActive/Passive の切り替え
• DRBD + Pacemaker/Corosync
• Oracle も公式にサポート対象
16
https://dev.mysql.com/doc/refman/5.6/ja/ha-drbd.htmlより引用
17
ディスク同期 メリ・デメ
ディスク同期 メリット
• 障害時のデータロストのリスクがない
• レプリケーション遅延の考慮が不要
• 商用ストレージと比較して安価に始められる
18
ディスク同期 デメリット
• 切り替わりに(ほかと比べて)時間がかかる
• ファイルシステムの破損に対応できない
19
参考資料
• CentOS アプライアンスでの DRBD MySQL クラスタ• http://wiki.pandorafms.com/index.php?title=Pandora:Documentation_ja:DRBD_Appliance
20
本日の内容
• DBサーバの構成パターンとメリット・デメリット
1. 共有ストレージ
2. ディスク同期(DRBD)
3. スレーブのマスター昇格
4. Group Replication
• クライアント側で意識してほしいこと
• 日本 MySQLユーザ会のご紹介
21
22
MySQL レプリケーションおさらい
マスター・スレーブ
• レプリケーション=複製を作る
• マスター
• 更新を受け付けるサーバ
• スレーブ
• コピー、読み取り専用
• 用途
• 読み取り性能のスケールアウト
• バックアップ取得用など使い分け
• マスター障害の際の切り替え先
• etc…23
マスターマスター
スレーブスレーブ スレーブスレーブ
クライアントクライアント
Global Transaction ID
• トランザクションに一意のIDを付与
• サーバUUID + 連番
• 08c8c338-f529-11e3-8182-fa163e64b6a2:1
• マスターは「更新内容+GTID」をログファイルに記録
• スレーブは「どのマスター」の「どのトランザクション」までコピーしたかを識別できる
24
実際の更新ログの内容
# 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
レプリケーションの流れ
26
• バイナリログ• 更新ログ
• IOスレッド• 更新ログをマスターか
ら受け取る
• リレーログ• 受け取ったログ
• SQLスレッド• リレーログからSQLを
読み出し、適用する
ストレージエンジン
ストレージエンジン
バイナリログ
バイナリログ
コネクションスレッドコネクションスレッドI/O
スレッドI/O
スレッド
リレーログ
リレーログ ストレージ
エンジンストレージエンジン
SQLスレッド
SQLスレッド
マスター スレーブ
ClientClient
スレーブを使ったフェイルオーバー
マスター(a)
マスター(a)
スレーブ(b)
スレーブ(b)
スレーブ(c)
スレーブ(c)
aaa-aaa:1aaa-aaa:2aaa-aaa:3
aaa-aaa:1aaa-aaa:2aaa-aaa:3
aaa-aaa:1aaa-aaa:2aaa-aaa:3
aaa-aaa:1aaa-aaa:2aaa-aaa:3
aaa-aaa:1aaa-aaa:2aaa-aaa:1aaa-aaa:2
クライアントクライアント
1. 一番進んでいるスレーブを探す
– SHOW GLOBAL VARIABLES LIKE ‘GTID_EXECUTED’
– 新マスターとする
2. スレーブでCHANGE MASTER TO MASTER_HOST=‘<NEW_MASER>’を実行し、新マスターを向ける
3. read_only を解除し、クライアントからのアクセスを新マスターに向ける
マスター(a)
マスター(a)
新マスター
(b)
新マスター
(b)
スレーブ(c)
スレーブ(c)
aaa-aaa:1aaa-aaa:2aaa-aaa:3
aaa-aaa:1aaa-aaa:2aaa-aaa:3
aaa-aaa:1aaa-aaa:2aaa-aaa:3
aaa-aaa:1aaa-aaa:2aaa-aaa:3
aaa-aaa:1aaa-aaa:2aaa-aaa:1aaa-aaa:2
クライアントクライアント
マスター(a)
マスター(a)
新マスター
(b)
新マスター
(b)
スレーブ(c)
スレーブ(c)
aaa-aaa:1aaa-aaa:2aaa-aaa:3
aaa-aaa:1aaa-aaa:2aaa-aaa:3
aaa-aaa:1aaa-aaa:2aaa-aaa:3bbb-bbb:1
aaa-aaa:1aaa-aaa:2aaa-aaa:3bbb-bbb:1
aaa-aaa:1aaa-aaa:2aaa-aaa:3bbb-bbb:1
aaa-aaa:1aaa-aaa:2aaa-aaa:3bbb-bbb:1
クライアントクライアント
一連の動作を自動で行うツールたち
• ツール用のmanager サーバを別で用意
• MHA for MySQL
• Master High Availability Manager and tools for MySQL
• mysqlfailover
• MySQL Utilities
28
マスター(a)
マスター(a)
スレーブ(b)
スレーブ(b)
スレーブ(c)
スレーブ(c)
aaa-aaa:1aaa-aaa:2aaa-aaa:3
aaa-aaa:1aaa-aaa:2aaa-aaa:3
aaa-aaa:1aaa-aaa:2aaa-aaa:3
aaa-aaa:1aaa-aaa:2aaa-aaa:3
aaa-aaa:1aaa-aaa:2aaa-aaa:1aaa-aaa:2
ManagerManager
MHA
• 松信さん がつくったツール
• 豊富な実績、Web上に資料が豊富
• 最近はメンテナンスモード
• クラッシュセーフスレーブと組み合わせて利用できない
• DBサーバへSSHを行う。DBサーバ側にもagentが必要。
29
mysqlfailover
• Oracle 社の公式ツール
• DBサーバへのSSHやagentのインストール不要
• SQLで完結
30
MySQL レプリケーションの種類
1. 非同期レプリケーション
2. 準同期レプリケーション– Ver 5.5~
3. ロスレス準同期レプリケーション– Ver 5.7~
31
非同期レプリケーション
32
1. クライアントがCOMMIT
2. バイナリログに更新内容を記録
3. ストレージエンジンに更新内容を記録
4. クライアントにACKを返す
5. リレーログに記録
ストレージエンジン
ストレージエンジン
バイナリログ
バイナリログ
コネクションスレッドコネクションスレッドI/O
スレッドI/O
スレッド
リレーログ
リレーログ ストレージ
エンジンストレージエンジン
SQLスレッド
SQLスレッド
マスター スレーブ
ClientClient
準同期レプリケーション
33
1. クライアントがCOMMIT
2. バイナリログに更新内容を記録
3. ストレージエンジンに更新内容を記録
4. リレーログに記録
5. クライアントにACKを返す
ストレージエンジン
ストレージエンジン
バイナリログ
バイナリログ
コネクションスレッドコネクションスレッドI/O
スレッドI/O
スレッド
リレーログ
リレーログ ストレージ
エンジンストレージエンジン
SQLスレッド
SQLスレッド
マスター スレーブ
ClientClient
rpl_semi_sync_master_wait_point=AFTER_COMMIT
準同期する台数を指定できる
準同期する台数を指定できる
ロスレス準同期レプリケーション
34
1. クライアントがCOMMIT
2. バイナリログに更新内容を記録
3. リレーログに記録
4. ストレージエンジンに更新内容を記録
5. クライアントにACKを返す
ストレージエンジン
ストレージエンジン
バイナリログ
バイナリログ
コネクションスレッドコネクションスレッドI/O
スレッドI/O
スレッド
リレーログ
リレーログ ストレージ
エンジンストレージエンジン
SQLスレッド
SQLスレッド
マスター スレーブ
ClientClient
rpl_semi_sync_master_wait_point=AFTER_SYNC
準同期する台数を指定できる
準同期する台数を指定できる
フェイルオーバー時のデータロスト
• 非同期レプリケーション– データロストのリスクがあるが、レイテンシがない
• 準同期レプリケーション– データロストのリスクはあるが小さい、レイテンシはある
• ロスレス準同期レプリケーション– データロストのリスクない、レイテンシはある
35
36
マスター昇格 メリデメ
マスター昇格 メリット
• 切り替わりが早い
• ファイルシステムの破損に対応できる
• 安価に始められる
• 待機系のサーバを利用できる
• 公開されている情報が多め
37
マスター昇格 デメリット
• レプリケーション遅延のリスクを考える必要がある
38
本日の内容
• DBサーバの構成パターンとメリット・デメリット
1. 共有ストレージ
2. ディスク同期(DRBD)
3. スレーブのマスター昇格
4. Group Replication
• クライアント側で意識すべきこと
• 日本 MySQLユーザ会のご紹介
39
Group Replication
• 次のメジャーバージョン(8.0) で入ると思いきや、12月の5.7.17で入ってきたヤツ!
40
高可用性ソリューション
• マルチライター構成が組める
• 高可用性ソリューション
• 性能向上を主目的としたものではない
41
MasterMaster MasterMaster MasterMaster MasterMaster MasterMaster
UPDATE tSET col = ‘B’
WHERE pk = 2
UPDATE tSET col = ‘B’
WHERE pk = 2
UPDATE tSET col = ‘A’
WHERE pk = 1
UPDATE tSET col = ‘A’
WHERE pk = 1
高可用性ソリューション
• マルチライター構成が組める
• 高可用性ソリューション
• 性能向上を主目的としたものではない
42
MasterMaster MasterMaster MasterMaster MasterMaster MasterMaster
UPDATE tSET col = ‘B’
WHERE pk = 2
UPDATE tSET col = ‘B’
WHERE pk = 2
UPDATE tSET col = ‘A’
WHERE pk = 1
UPDATE tSET col = ‘A’
WHERE pk = 1
マルチライター
43
マスター(a)
マスター(a)
スレーブスレーブ スレーブスレーブ
マスター(a)
マスター(a)
マスターマスター マスターマスター
ReadWriteReadWrite
ReadWriteReadWrite
ReadWriteReadWrite
これまでのレプリケーション Group Replication
WriteWrite
ReadRead ReadRead
障害検知の仕組みがビルドイン
44
MasterMaster MasterMaster MasterMaster MasterMaster MasterMaster
• 障害を自動検知し、データ同期対象から切り離す
• 復旧時には差分を自動的にリカバリ
45
Group Replication とロックの挙動
非 Group Replication 構成の場合
46
時間 行の値 トランザクション1 トランザクション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;
T3 - トランザクション1のロック開放待ち
T4 A mysql> COMMIT;Query OK, 0 rows affected (0.00 sec)
トランザクション1のロック開放待ち
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)
非 Group Replication 構成の場合
47
時間 行の値 トランザクション1 トランザクション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;
T3 - トンラザクション1のロック開放待ち
T4 A mysql> COMMIT;Query OK, 0 rows affected (0.00 sec)
トランザクション1のロック開放待ち
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)
• 更新は1ノード(マスター)に対してのみ実行可
• ロックが競合した場合、後続は「待つ」
• 更新は1ノード(マスター)に対してのみ実行可
• ロックが競合した場合、後続は「待つ」
Group Replication 構成の場合
48
時間 行の値 トランザクション1 on ノード1 トランザクション2 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)
(ノード1の更新内容が伝わってくる)
T4 A mysql> COMMIT;
ERROR 1180 (HY000):
Got error 149 during COMMIT
Group Replication 構成の場合
49
時間 行の値 トランザクション1 on ノード1 トランザクション2 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構成と同じ挙動
回避方法
50
MasterMasterRead only
MasterRead only
MasterRead only
MasterRead only
Master
Single Primary モード• 従来のマスター/スレーブに相当• 任意の1台のみWriteが可能になる
MasterMaster MasterMaster MasterMaster
Multi Writer モード• 全部に読み書き• 最大限の可用性
group_replication_single_primary_mode=FALSEgroup_replication_single_primary_mode=TRUE
分散方法
• 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 BalancerLoad Balancer
ClientClient
52
flow control
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 |+----------------------------------------------------+-------+
Certification と Apply
54
11 22 33
UPDATE
Certific
atio
nCertific
atio
nhttp://mysqlhighavailability.com/mysql-group-replication-transaction-life-cycle-explained/
Certific
atio
nCertific
atio
n
Apply
Apply
OKOK
更新する内容を伝える
更新する内容を伝える
Apply
Apply
Apply
Apply
テスト
• 3台中1台に向けてベンチマークを流す
• ベンチを流しているノードと違うノードでDISK IOを絞る
55
11 22 33
sysbench
テスト結果
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制限
テスト結果
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
→ 時間
キューが閾値に達するまでの時間
キューが閾値に達するまでの時間
58
MGR 設定手順
STEP1: インストールとユーザ作成
59
• レプリケーションユーザを作成しておく
• この時点でbinlogはまだ有効化してはいけない
mysql> CREATE USER 'rpl_user'@'%' IDENTIFIED BY 'rpl_pass';
mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
STEP2-1:レプリケーション設定
• GTID
• log-slave-updates
• {master,relay}-log-info-repository=TABLE
• binlog-format=row
60
server_id=1gtid_mode=ONenforce_gtid_consistency=ONmaster_info_repository=TABLErelay_log_info_repository=TABLEbinlog_checksum=NONElog_slave_updates=ONlog_bin=binlogbinlog_format=ROW
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= offloose-group_replication_single_primary_mode=FALSEloose-group_replication_enforce_update_everywhere_checks= TRUE
# サーバ間の通信に利用するネットワークを許可する
loose-group_replication_ip_whitelist = 172.21.134.0/23
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 を設定
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台だけ
STEP5:ステータス確認
64
mysql> SELECT * FROM performance_schema.replication_group_members;+---------------------------+----------------------+-------------+--------------+| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_STATE |+---------------------------+----------------------+-------------+--------------+| group_replication_applier | 0cdd0b6a-cd84-<snip> | gr02 | ONLINE || group_replication_applier | 1edf2e1d-cd83-<snip> | gr01 | ONLINE || group_replication_applier | a1c37edb-cd89-<snip> | gr03 | ONLINE |+---------------------------+----------------------+-------------+--------------+3 rows in set (0.00 sec)
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
66
Group Replicationメリデメ
Group Replication メリット
• 構成が最もシンプル
• 物理サーバの役割が平等
• 障害検知の仕組みがビルドインされている
• 切り替わりが高速
• 切り離しだけ
• 待機系のサーバを利用できる
• レプリケーション遅延を最小限に抑えることが可能
67
Group Replication デメリット
• (マルチライターで使う場合)ロックの競合の考慮が必要
• InnoDBしか使えない
68
本日の内容
• DBサーバの構成パターンとメリット・デメリット
1. 共有ストレージ
2. ディスク同期(DRBD)
3. スレーブのマスター昇格
4. Group Replication
• クライアント側で意識してほしいこと
• 日本 MySQLユーザ会のご紹介
69
クライアント側で意識してほしいこと
• どんなにサーバ側で対策してもダウンゼロは無理
• 関係者でSLAを合意しておく
• 実装– 正しくエラーハンドリングをする
– リトライ処理を入れる
70
71
まとめ
結局オススメどれ?
• 今からやるならGroup Replication を試してほしい
72
73
日本MySQL ユーザ会について
ご案内
• MySQL Casual Slack
• https://t.co/QobukOxvUw
74
• 日本MySQL ユーザ会 ML• http://mysql.gr.jp/ml.html
75
ありがとうございました
top related