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

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

本日の内容








5

クラスタソフトクラスタソフト

共有ストレージ

• DBの世界では伝統的な方法

• データファイルを共有ストレージに置く

• クラスタソフトでActive/Passive の切り替え

6

共有ストレージ(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

クラスタソフトクラスタソフト



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

本日の内容








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より引用

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

本日の内容








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: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)







マスター(a)

マスター(a)

新マスター

(b)

新マスター

(b)

スレーブ(c)

スレーブ(c)



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)






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

スレッド

リレーログ



SQLスレッド

SQLスレッド


ClientClient

準同期レプリケーション

33








バイナリログ

バイナリログ


スレッドI/O

スレッド

リレーログ



SQLスレッド

SQLスレッド


ClientClient

rpl_semi_sync_master_wait_point=AFTER_COMMIT

準同期する台数を指定できる


ロスレス準同期レプリケーション

34








バイナリログ

バイナリログ


スレッドI/O

スレッド

リレーログ



SQLスレッド

SQLスレッド


ClientClient

rpl_semi_sync_master_wait_point=AFTER_SYNC



フェイルオーバー時のデータロスト

• 非同期レプリケーション– データロストのリスクがあるが、レイテンシがない

• 準同期レプリケーション– データロストのリスクはあるが小さい、レイテンシはある

• ロスレス準同期レプリケーション– データロストのリスクない、レイテンシはある

35

36

マスター昇格メリデメ

マスター昇格メリット

• 切り替わりが早い

• ファイルシステムの破損に対応できる

• 安価に始められる

• 待機系のサーバを利用できる

• 公開されている情報が多め

37

マスター昇格デメリット

• レプリケーション遅延のリスクを考える必要がある

38

本日の内容






• クライアント側で意識すべきこと


39

Group Replication

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

40

高可用性ソリューション

• マルチライター構成が組める

• 高可用性ソリューション

• 性能向上を主目的としたものではない

41

MasterMaster MasterMaster MasterMaster MasterMaster MasterMaster

UPDATE tSET col = ‘B’

WHERE pk = 2


WHERE pk = 2

UPDATE tSET col = ‘A’

WHERE pk = 1


WHERE pk = 1

高可用性ソリューション

• マルチライター構成が組める

• 高可用性ソリューション

• 性能向上を主目的としたものではない

42



WHERE pk = 2


WHERE pk = 2


WHERE pk = 1


WHERE pk = 1

マルチライター

43

マスター(a)

マスター(a)

スレーブスレーブスレーブスレーブ

マスター(a)

マスター(a)

マスターマスターマスターマスター

ReadWriteReadWrite

ReadWriteReadWrite

ReadWriteReadWrite

これまでのレプリケーション Group Replication

WriteWrite

ReadRead ReadRead

障害検知の仕組みがビルドイン

44


• 障害を自動検知し、データ同期対象から切り離す

• 復旧時には差分を自動的にリカバリ

45

Group Replication とロックの挙動

非 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


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)

非 Group Replication 構成の場合

47

時間行の値トランザクション１トランザクション２


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


mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘B' WHERE pk = 1;

T3 - トンラザクション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 構成の場合

48

時間行の値トランザクション１ on ノード1 トランザクション２ on ノード2




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


(ノード１の更新内容が伝わってくる）

T4 A mysql> COMMIT;

ERROR 1180 (HY000):

Got error 149 during COMMIT

Group Replication 構成の場合

49

時間行の値トランザクション１ on ノード1 トランザクション２ on ノード2




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


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

http://lefred.be/content/mysql-group-replication-as-ha-solution/

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

本日の内容








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

ありがとうございました

Technology

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