イルカさんチームからゾウさんチームに教えたいMySQLレプリケーション

1. この余⽩はタイトルを書くには狭すぎる余⽩じゃなくてタイトル欄なんだけどな 2016/02/20 yoku0825 第2回 MySQL・PostgreSQLユーザーグループ合同DB勉強会 in 東京

2. おしながき「明⽇使えない⾖知識」その1 （予告）「明⽇使えない⾖知識」その2 「明⽇使えない⾖知識」その3 「明⽇使えない⾖知識」その4 「明⽇使えない⾖知識」その1 （本編） 1/133

3. 「明⽇使えない⾖知識」その1（予告） 2/133

4. NOW関数は現在時刻を返さない 3/133

5. 真相は番組の後半、チャンネルはそのまま︕ 4/133

6. 「明⽇使えない⾖知識」その2 5/133

7. MySQL 5.7 2013/04 MySQL 5.7.1 DMR11 2015/03 MySQL 5.7.6 DMR16 2015/04 MySQL 5.7.7 RC 2015/08 MySQL 5.7.8 RC 2015/10 MySQL 5.7.9 GA 2015/12 MySQL 5.7.10 GA 2016/02 MySQL 5.7.11 GA 6/133

8. MySQL 5.7 2015/04 MySQL 5.7.7 RC ここまではまあいい 2015/08 MySQL 5.7.8 RC JSON型, virtual generated columnの拡張, InnoDB Page Compression 2015/10 MySQL 5.7.9 GA innodb_default_row_format, JSON -> operator, innodb_numa_interleave 2015/12 MySQL 5.7.10 GA Bug Fix 2016/02 MySQL 5.7.11 GA InnoDB Tablespace Encryption 7/133

9. MySQL 5.7 2015/04 MySQL 5.7.7 RC ここまではまあいい 2015/08 MySQL 5.7.8 RC 新機能!! 2015/10 MySQL 5.7.9 GA 新機能!! 2015/12 MySQL 5.7.10 GA Bug Fix 2016/02 MySQL 5.7.11 GA 新機能!! 8/133

10. General Available # とは 9/133

11. 「明⽇使えない⾖知識」その3 10/133

12. 講演のタイトル「イルカ㌠からゾウ㌠に伝えたいMySQLのレプリケーションの仕組み」とか話したかったんですけどかじやまさんから5.7にしるって⾔われてるので残念ながら5.7の何かを話します（仮）と思ったんですけどやっぱりイルカ㌠からゾウ㌠に伝えたい MySQLレプリケーションの話をします 11/133

13. 意訳 12/133

14. MySQL 5.7の話はもう飽きたんでレプリケーションの話をします 13/133

15. ことのあらまし 14/133

16. ことのあらまし 15/133

17. ことのあらまし 16/133

18. ことのあらまし 17/133

19. ことのあらまし 18/133

20. ことのあらまし 19/133

21. ことのあらまし 20/133

22. ことのあらまし 21/133

23. ことのあらまし 22/133

24. ことのあらまし 23/133

25. これはレプリケーションでしこたま痛い目を⾒たの先⼈イルカ㌠から 24/133

26. これからレプリケーションで痛い目を⾒るでできることが増えていくゾウ㌠へ 25/133

27. 語らねばなるまい（使命感） 26/133

28. というわけで「明⽇使えない⾖知識」その4 27/133

29. MySQLのレプリケーションについて 28/133

30. ＼こんにちは／ yoku0825＠とある企業のDBA オラクれない- ポスグれない- マイエスキューエる- 家に帰ると妻の夫- せがれの⽗- ムスメの⽗- Twitter: @yoku0825 Blog: ⽇々の覚書 MyNA ML: ⽇本MySQLユーザ会 29/133

31. MyNAステッカーデザインは堤井さん今⽇持ってきてます。声かけてください。 30/133

32. MySQL年表 < 5.0 知らない⼦ですね 5.0 2005/10〜2012/03 5.1 2008/11〜2013/12 5.5 2010/12〜2015/12 5.6 2013/02〜 5.7 31/133

33. レプリケーション年表 < 5.0 3.23の頃から非同期レプリケーションがあった 5.1 ⾏ベースレプリケーションフォーマット追加 5.5 準同期レプリケーションの追加 5.6 GTID、レプリケーション情報のInnoDBテーブル導⼊、マルチスレッドスレーブ(MTS)の追加、binlogのグループコミット 5.7 MTSの機能強化、グループコミットの機能強化、ロスレス準同期レプリケーション 32/133

34. レプリケーションの動作原理同じデータを持ったサーバーがあって同じSQLを同じ順番で適⽤すれば最終的に同じデータに戻るよね︖ という期待に基づいた、結果整合性モデル 33/133

35. レプリケーションのご法度スレーブに更新をかけると「同じデータを持ったサーバー」の前提が崩れる循環レプリケーション…だと…︖- 非決定性関数を使うと「同じSQLを同じ順番で適⽤しても」同じデータに戻らくなるよね︖ 有名どころでSYSDATE, ユニークキーでORDER BYしてないLIMIT - 34/133

36. MySQLのレプリケーションアーキテクチャー clientA connection executor storage_engine binlog binlog_dump io_thread relaylog slave_executorsql_thread binlog storage_engine slave_connection clientB master slave 35/133

37. MySQLレプリケーション⽤語バイナリーログ, binlog リレーログ Binlog Dump Thread I/Oスレッド, Receiver Thread SQLスレッド, Applier Thread 36/133

38. MySQLのレプリケーションアーキテクチャー Executorがストレージエンジンに書く1. Executorがバイナリーログに書く2. Binlog Dump Threadがバイナリーログを読む3. I/O ThreadがBinlog Dumpからイベントを受け取ってリレーログに書く 4. SQL Threadがリレーログからイベントを読み取って⾃⾝の Executorを叩く 5. 37/133

40. Executorがストレージエンジンに書くもちろんトランザクション対応はストレージエンジン依存 5.6まではコミットの時点でストレージエンジンのコミットをしてしまっていた 5.7からはこの時点ではまだコミットされない 39/133

42. Executorがバイナリーログに書く Executorから⾒たバイナリーログは binlogストレージエンジン MySQLにもともと実装されているXAトランザクションを使って⼆相コミット binlog̲cacheにXA PREPAREしておいてXA COMMIT- クラッシュしてもXA RECOVERはできない＞＜- 41/133

43. ストレージエンジンとして⾒たbinlog A binlog_cacheとsync_binlogによりアトミックっぽく振る舞えるけど厳密にAtomicじゃない C ストレージエンジン層がコミットをシリアライズしてくれることに依存 I 常にSERIALIZABLE D sync_binlog= 1なら⼀応Durable 42/133

44. バイナリーログのその他の使い道 PITR シリアライズされた更新情報なのでPITRに使う- SQLをパースして⾊々するテーブルごとのUPDATE回数を後追いで集計するとか- 中⾝を取り出して別のデータストアに⼊れるとか- 43/133

46. Binlog Dump Threadがバイナリーログを読む fsyncしててもしてなくてもwriteされた時点から読めるマスターのmysqldではクライアントからのコネクション扱いスレーブでSTART SLAVE => マスターで認証 => ESTABLISH後はマスター側からsendtoできる - 45/133

48. I/O ThreadがBinlog Dumpからイベントを受け取ってリレーログに書くここからスレーブのmysqld Binlog Dumpから送り付けられたイベントをリレーログとして書き込むちなみに、mysqlbinlog -Rも（マスターから⾒ると）I/Oスレッドと同じ様に振る舞う 47/133

49. MySQLのレプリケーションアーキテクチャー Executorがストレージエンジンに書く1. Executorがバイナリーログに書く2. Binlog Dump Threadがバイナリーログを読む3. I/O ThreadがBinlog Dumpからイベントを受け取ってリレーログに書く 4. SQL Threadがリレーログからイベントを読み取って⾃⾝のExecutorを叩く 5. 48/133

50. SQL Threadがリレーログからイベントを読み取って⾃⾝のExecutorを叩くこれによりマスターのExecutorがまるでスレーブの Executorも叩いたかの様にデータが更新される Executorはまたバイナリーログを吐くこともできる 49/133

51. binlogフォーマット SBR Statement Based Replication RBR Row Based Replication MBR（あんまり⾔わない） Mixed Based Replication 50/133

52. SBR いわゆる MySQLのレプリケーションっぽいやつ binlogに記録されるのはエンコードされた SQLステートメントイベントはステートメント単位- MySQL 5.6とそれ以前のデフォルト 51/133

53. SBR $ mysqlbinlog -R -h 127.0.0.1 -P 64057 -uroot --stop-never bin.00 0010 mysql57> SET SESSION binlog_format= 'STATEMENT'; Query OK, 0 rows affected (0.00 sec) mysql57> INSERT INTO t1 VALUES (1, 'one'); Query OK, 1 row affected (0.01 sec) # at 2339 #160201 19:14:40 server id 1057 end_log_pos 2441 CRC32 0xb0e9add 8 Query thread_id=12 exec_time=0 error_code=0 SET TIMESTAMP=1454321680/*!*/; INSERT INTO t1 VALUES (1, 'one') /*!*/; 52/133

54. SBR SQLステートメントが記録されるため、そのステートメントが何百万⾏更新しようと1ステートメントぶんのスペースしか取らない。容量的なワーストケースはINSERTや1⾏UPDATE。- SQLとしてパースされるため、「マスターには存在したけどスレーブには存在しない⾏」へのクエリーはナチュラルに無視される（WHERE句で空振りしたクエリーはエラーじゃなくて空の結果セットを返す） 53/133

55. SBR SQLとしてそれぞれのサーバーで実⾏されるため、非決定性（実⾏するたびに結果が違う）ステートメントを使うと死ぬ。 http://dev.mysql.com/doc/refman/5.6/ja/ replication-rbr-safe-unsafe.html - トリガーはマスターとスレーブで個々に実⾏される（記録されるイベントはトリガー元テーブルに対するもののみ） READ-COMMITTEDだとマスター/スレーブでデータ不整合を起こすのでエラーになる。 54/133

56. READ-COMMITTEDがSBRを壊す︖ REPEATABLE-READならネクストキーロックでtrx2がブロックされる。 +-----+------+ | num | val | +-----+------+ | 1 | one | +-----+------+ trx1> BEGIN; trx1> UPDATE t1 SET val= 'updated' WHERE num= 2; -- No row update d. trx2> BEGIN; trx2> UPDATE t1 SET num= 2 WHERE num = 1; trx2> COMMIT; trx1> COMMIT; 55/133

57. RBR 5.1から導⼊ binlogに記録されるのは⾏の変更前の値と変更後の値をバイナリーエンコードしたものイベントは⾏単位- ただしDDLは設定に関わらずSBRで記録される MySQL 5.7からのデフォルト 56/133

58. RBR $ mysqlbinlog -R -h 127.0.0.1 -P 64057 -uroot --stop-never bin.000010 mysql57> SET SESSION binlog_format= 'ROW'; Query OK, 0 rows affected (0.00 sec) mysql57> INSERT INTO t1 VALUES (2, 'two'); Query OK, 1 row affected (0.00 sec) # at 2607 #160201 19:23:58 server id 1057 end_log_pos 2653 CRC32 0x424bf80 5 Table_map: `d1`.`t1` mapped to number 108 # at 2653 #160201 19:23:58 server id 1057 end_log_pos 2701 CRC32 0xf946a87 6 Write_rows: table id 108 flags: STMT_END_F BINLOG ' PjKvVhMhBAAALgAAAF0KAAAAAGwAAAAAAAEAAmQxAAJ0MQACCA8CgAACBfhLQg== PjKvVh4hBAAAMAAAAI0KAAAAAGwAAAAAAAEAAgAC//wCAAAAAAAAAAN0d292qEb5 '/*!*/; 57/133

59. RBR 1⾏1イベント。100万⾏更新すると死ぬ。 INSERTや1⾏UPDATEならSBRとそんなに容量変わらない。 - スレーブでも⾏探索と更新は⾏われるので、プライマリーキーが無いとカジュアルに死ぬ - 「マスターには存在したけどスレーブには存在しない⾏」へのクエリーはエラーで⽌まる（更新前の値を持つ⾏が⾒付からないとER̲KEY̲NOT̲FOUND） 58/133

60. RBR 非決定性関数だろうと「実⾏結果が記録」されるため、マスターとスレーブでも値はズレない。マスターでのみトリガーが解釈され、トリガー元テーブルとトリガー先テーブルの両⽅のイベントがbinlogに記録される。マスターとスレーブでトリガーが違うと地獄が⾒える。- バイナリーパックで型が決まっているため、マスターとスレーブでデータ型が違うと死ぬ。⽂字コードが違ってもバイト数が異なって死ぬ。- 59/133

61. MBR 基本はSBR、非決定性ステートメントだけRBRで使い分ける。MBRと呼ぶのは稀。いいとこ尽くしに聞こえなくもないけど、実際は思わぬところでRBRにフォールバックして割とカジュアルに死ぬ。マスタースレーブでトリガーをズラして調整している時にRBRに落ちて泣いたり。 - 何故かWHERE pkey = ?なクエリーにLIMIT 1とか付けられてRBRに落ちて Bug#74118 の洗礼を受けたり。 - MySQL 5.1の⼀部のリビジョンだけこれがデフォルト。弊社はこれです。。 60/133

62. 初⼼者は黙ってRBR(5.7ʼs default) 初⼼者は黙ってRBR サイレントにデータがズレるよりはエラって⽌まった⽅がマシデータのズレを検出＆リカバリーするにはpt-table- checksumとpt-table-syncが有効 pt-slave-restartは使えるけどオススメしない 61/133

63. pt-table-checksum SBRとRBRでそれぞれチェックサムを計算してテーブルに突っ込むクエリーを発⾏マスター上では当然SBRでもRBRでも同じチェックサムになる - スレーブではSBRで来たイベントはスレーブでチェックサムを計算、RBRで来たイベントはマスターで計算されたチェックサムがそのままカラムに⼊るこれを⽐較することができる 62/133

64. pt-online-schema-change 変更元テーブルをコピーして先にALTER TABLEを適⽤する変更元テーブルにトリガーを仕掛けて、変更元テーブルに対する更新がコピーしたテーブルにも反映されるようにする READ-COMMITTEDでゆっくり変更元テーブルからコピーしたテーブルに⾏をコピーするコピーが終わったらロックを取ってRENAME TABLE 63/133

65. pt-online-schema-change InnoDBオンラインDDLが導⼊された5.6以降でも有効何故なら、SQLスレッドは相変わらず1本（あるいは、同じテーブルだとMTS使ってても追い越せない）ので、ALTER TABLEに時間がかかるとその分レプリケーションが遅れる pt-oscは細切れに⾏をコピーして、スレーブの遅れ具合をチェックしながらスリープを⼊れるので、レプリケーション遅延に優しい 64/133

66. バイナリーログの⼀⽣マスター上でコミットされた順にbinlogにエンコード binlogからrelaylogにシングルスレッドで転送（順序は保証される） relaylogはシングルスレッドまたはマルチスレッドで適⽤ MySQL 5.5とそれ以前はシングルスレッド固定- MySQL 5.6とそれ以降はslave_parallel_workers > 1で MTS（Multi Threaded Slave） - 65/133

67. MTSのアーキテクチャー clientA connection executor storage_engine binlog binlog_dump io_thread relaylog slave_executor1 slave_executor2 slave_executor3 coordinator slave_worker1 slave_worker2 slave_worker3 storage_engine binlog slave_connection clientB master slave 66/133

68. MTSのアーキテクチャーマスターのバイナリーログがリレーログに記録されるところまでは⼀緒 1. SQL Thread(coordinator)がリレーログからイベントを取り出す 2. coordinatorがslave̲worker̲threadにイベントを渡す3. slave̲worker̲threadはそれぞれExecutorを叩いてストレージとバイナリーログを更新する 4. 67/133

70. MTSコーディネーター前後のイベントが互いに⼲渉しない（順序を⼊れ替えても問題ない）かどうかの責任を持つただし順序が⼊れ替わる（線形でない）ことが⼤前提のため、シングルスレッドレプリケーションよりも結果整合性の⾊が強い - 69/133

71. MTSコーディネーター MySQL 5.6ではスキーマが分かれていることで⼲渉しないことを担保（5.7のslave_parallel_type= DATABASE相当） 5.7ではマスターでbinlogに記録された時の直前のコミットのタイムスタンプをベースに⼲渉しないことを担保するモードが登場（slave_parallel_type= LOGICAL_CLOCK）マスター上でロックが競合せずにグループコミットの中に⼊れたってことはスレーブでも競合しないってことだよね︖ という理屈 - 70/133

73. slave̲worker̲thread 独⽴して動作するため、RR（Repeatable-Read）でもマスターと同⼀のデータベース全体のスナップショットを保証できない 5.6ではスレーブ側のバイナリーログの中⾝は順序を保証できない（5.7ではslave_preserve_commit_orderで LOGICAL̲CLOCKベースの順序を保証できるようになった） 72/133

74. イベントの識別たとえばInnoDBログならLSN バイナリーログはファイル名とファイルの先頭からのオフセットバイト数これらはマスター上でのみ⼀意に識別されるものなのでカスケードすると変わる - MySQL 5.6とそれ以降のGTIDもこれらをマッピングするだけで、本質的には相変わらずこれで⾒ている - 73/133

75. CHANGE MASTER TO mysql> CHANGE MASTER TO master_log_file= '..', master_log_pos = ..; このバイナリーログのこのポジションから先を寄越せ、というクライアントからのリクエスト。ポジションの指定はイベントの先頭でないといけない（イベントの先頭でないポジションを指定するとSTART SLAVEでI/O スレッドがエラる）バイナリーログの固定ヘッダ⻑はバージョンによって違うけど、どうせ読み⾶ばされるので「先頭から読ませたい」時はmaster_log_pos= 1でどのバージョンでもイケる。 - 74/133

76. master.info マスターの情報を保持するための構造。コード追う時は mi。 CHANGE MASTER TOで与えられた情報 + αが⼊ってる。 relay_log_recovery != 1の時はここからファイルとポジションの情報を復元してレプリケーションを再開する 5.6とそれ以降ではInnoDBなテーブルに記録することが可能（master_info_repository= {TABLE|FILE} 75/133

77. master.info slave1 [localhost] {msandbox} ((none)) > SELECT * FROM mysql.slave_master_infoG *************************** 1. row *************************** Number_of_lines: 23 Master_log_name: mysql-bin.000001 Master_log_pos: 3089 Host: 127.0.0.1 User_name: rsandbox User_password: rsandbox Port: 22494 Connect_retry: 60 Enabled_ssl: 0 Ssl_ca: Ssl_capath: Ssl_cert: Ssl_cipher: Ssl_key: Ssl_verify_server_cert: 0 Heartbeat: 1800 Bind: Ignored_server_ids: 0 Uuid: 00022494-1111-1111-1111-111111111111 Retry_count: 86400 Ssl_crl: Ssl_crlpath: Enabled_auto_position: 0 1 row in set (0.00 sec) 76/133

78. relay̲log.info リレーログ（SQLスレッド, slave̲worker̲thread）の情報を保持するための構造。コード追う時はrli。 Relay̲log̲fileとかRelay̲log̲posとか Relay̲Master̲Log̲FileとかExec̲master̲log̲posとか⼊ってる（SQLスレッド側の使う情報） 5.6とそれ以降ではInnoDBなテーブルに記録することが可能（relay_log_info_repository= {TABLE|FILE}） 77/133

79. relay̲log.info slave1 [localhost] {msandbox} ((none)) > SELECT * FROM mysql.slav e_relay_log_infoG *************************** 1. row *************************** Number_of_lines: 7 Relay_log_name: ./mysql-relay.000002 Relay_log_pos: 3061 Master_log_name: mysql-bin.000001 Master_log_pos: 2898 Sql_delay: 0 Number_of_workers: 0 Id: 1 1 row in set (0.00 sec) 78/133

80. レプリケーションとマスタークラッシュバイナリーログマスターストレージリレーログ影響残ってない未更新受信してないなし（︖）残ってない未更新受信したデータ不整合（スレーブにあってマスターにない）しかもエラー（ER̲MASTER̲FATAL̲ERROR̲REA DING̲BINLOG）残ってない更新済み受信してないデータ不整合（マスターにあってスレーブにない）残ってない更新済み受信したなしだがエラー（ER̲MASTER̲FATAL̲ERROR̲REA DING̲BINLOG）残ってる未更新受信してないトランザクションロスト残ってる未更新受信したデータ不整合（スレーブにあってマスターにない）残ってる更新済み受信してないなし（リトライで救われる）残ってる更新済み受信したなしバイナリーログが残っていない場合、その期間のPITR不可 79/133

81. レプリケーションとマスタークラッシュ sync_binlog= 1だと起こり得る範囲がぐっと狭くバイナリーログマスターストレージリレーログ影響残ってる未更新受信してないトランザクションロスト残ってる未更新受信したデータ不整合（スレーブにあってマスターにない）残ってる更新済み受信してないなし（リトライで救われる）残ってる更新済み受信したなし 80/133

82. レプリケーションとマスタークラッシュまたはsemisync + log_slave_updatesでマスター切り替えバイナリーログマスターストレージリレーログ影響残ってない未更新受信したデータ不整合（スレーブにあってマスターにない）しかもエラー（ER̲MASTER̲FATAL̲ERROR̲REA DING̲BINLOG）残ってない更新済み受信したなしだがエラー（ER̲MASTER̲FATAL̲ERROR̲REA DING̲BINLOG）残ってる未更新受信したデータ不整合（スレーブにあってマスターにない）残ってる更新済み受信したなし 81/133

83. レプリケーションとスレーブクラッシュリレーログ master.info SQLスレッド relay̲log.info 影響受け取ってない記録してない適⽤してない記録してないなし受け取ってる記録してない適⽤してない記録してないリレーログ⼆重受信受け取ってる記録してない適⽤した記録してないリレーログ⼆重受信 + ⼆重適⽤ = 三重コミット受け取ってる記録してない適⽤した記録したリレーログ⼆重受信受け取ってる記録した適⽤してない記録してないなし受け取ってる記録した適⽤した記録してないリレーログ⼆重適⽤受け取ってる記録した適⽤した記録したなし 82/133

84. レプリケーションとスレーブクラッシュ relay_log_info_repository= TABLE ただしInnoDB前提（innodb_flush_log_at_trx_commit = 1で次の表） - SQLスレッドのイベント適⽤と mysql.slave̲relay̲log̲infoへのUPDATEを1つのコミットにまとめる - 83/133

85. relay_log_info_repository= TABLE && innodb_flush_log_at_trx_commit = 1 リレーログ master.info SQLスレッド relay̲log.info 影響受け取ってない記録してない適⽤してない記録してないなし受け取ってる記録してない適⽤してない記録してないリレーログ⼆重受信受け取ってる記録してない適⽤した記録したリレーログ⼆重受信受け取ってる記録した適⽤してない記録してないなし受け取ってる記録した適⽤した記録したなし 84/133

86. レプリケーションとスレーブクラッシュ relay_log_recovery レプリケーションの再開時にmaster.infoのポジション情報をアテにせず、relaylog.infoの情報を元にレプリケーションを復元する - 受信済みだけど未適⽤の（relaylog.infoに適⽤済みと記録されてない）リレーログは捨てる - 85/133

87. relay_log_recovery リレーログ master.info SQLスレッド relay̲log.info 影響受け取ってない記録してない適⽤してない記録してないなし受け取ってる記録してない適⽤した記録してないリレーログ⼆重受信 + リレーログ⼆重適⽤ = 三重コミット受け取ってる記録した適⽤してない記録してないなし受け取ってる記録した適⽤した記録したなし 86/133

88. レプリケーションとスレーブクラッシュ男らしくバックアップからリストアする割と真⾯目に。毎回リストアすると割り切れば、ACIDのDは無茶な⽅向に振れて性能が稼げるお( ＾ω＾) - 87/133

89. レプリケーションとスレーブクラッシュ sync̲relay̲log? syncされていようとsyncされていまいと、リレーログからレプリケーション再開位置を特定するわけではない sync̲master̲info? relay_log_recoveryならrelay̲log.infoから再開位置を特定するのであまり重要じゃない sync̲relay̲log̲info? relay_log_info_repository != TABLEやトランザクション非対応テーブルの場合にのみ効いてくる。ややこしいので注意。 http://dev.mysql.com/doc/refman/5.6/ja/replication- options-slave.html#sysvar̲sync̲relay̲log̲info 88/133

90. マスター側のフィルターに関するパラメーター server_id, replicate_same_server_id フィルター関連っぽくないけど。- ⾃分と同じサーバーIDのイベントは読み⾶ばすカスケードすると同じサーバーIDのmysqldがいても⼀⾒問題なさげに⾒えてしまう - binlog_do_db, binlog_ignore_db そもそもバイナリーログに記録されなくなる。- カレントデータベース基準。- 個⼈的に推奨しない。- 89/133

91. スレーブ側のフィルターに関するパラメーター SQLスレッドでフィルターなので、I/Oスレッドはフツーに受信してリレーログまで吐く - replicate_do_db, replicate_ignore_db- replicate_do_table, replicate_ignore_table- replicate_wild_do_table, replicate_wild_ignore_table- replicate_rewrite_db 90/133

92. レプリケーションフィルターの評価順フローチャートになってるので⾒やすい MySQL :: MySQL 5.6 リファレンスマニュアル :: 17.2.3 サーバーがレプリケーションフィルタリングルールをどのように評価するかマスターとスレーブで意図的に不整合を起こさせようっていうんだから業が深い 91/133

93. レプリケーションで垂直シャード table1 table2 table3 binlog replicate_do_table= t able1 table1 replicate_do_table= t able2, table3 table2 table3 master slave slave 92/133

94. マスターとスレーブでバージョンが違ってもいい（レプリケーションがサポートされるのは原則リリース系列1世代）スレーブを先にバージョンアップするパターンのみ全部のスレーブを先にバージョンアップしてマスター切り替えして、旧マスターをバージョンアップして新マスターにぶら下げるとローリングアップグレードとか 93/133

95. マスターとスレーブでストレージエンジンが違ってもいい（だがマスターを BLACKHOLEはやめておけ）マスターはInnoDBでトランザクション保護、集計⽤スレーブはMyISAMでスキャンしまくる遊び（あるいは、MyISAM は容量効率がいいし）マスターはInnoDBで保護、参照⽤スレーブにMroonga（参照ロックフリー、全⽂検索、カラムナー）ローリングアップグレードと同じ要領で、MyISAMから InnoDBに変更したり 94/133

96. マスターとスレーブでインデックスがあったりなかったりしていい（カラムはやめておいた⽅が無難） RSU（Rolling Schema Update）って呼ぶこともある。呼ばないこともある。 - 5.6のInnoDBオンラインDDLでRSUがかなりやりやすく- ただしあんまり差があると管理が⾯倒 95/133

97. これまでのレプリケーションの制約 I/Oスレッド - リレーログ - SQLスレッドで1組 5.6からSQLスレッドは並列化可能に- I/Oスレッドが1本しかないということは、「スレーブから⾒たマスターは1つしか存在できない」マスターから⾒たスレーブはいくつあってもいい（ただのクライアントなので、（性能を考えなければ） max_connections未満ならいくらでも） - 96/133

98. 複数のマスターを持ちたい理由集計⽤スレーブあっちのサーバーのデータとこっちのサーバーのデータをJOINしたい - 集計⽤と割り切ればHDDのRAID5で容量を稼ぐという選択肢もありだし - シャードの集約複数のシャードをまとめてサーバー削減したい- 97/133

99. N対1レプリケーション通称えぬいちレプリケーションまたはどあきレプリケーション「1つのマスターしか設定できないなら、定期的にマスターを切り替えればいいじゃない」 do-aki/N1Repl: master n : slave 1 replication for mysql 98/133

100. N対1レプリケーション master1 slave master2 START SLAVE Binlog Dump Applying CHANGE MASTER TO Binlog Dump Applying CHANGE MASTER TO Binlog Dump 99/133

101. N対1レプリケーション実はMySQL UtilitiesにもmysqlrplmsというどあきレプリケーションスクリプトがあるただしこちらはGTID必須 mysqlrplms ̶ Set Up and Start Replication Among a Slave and Multiple Masters 100/133

102. (Native) Multi Source Replication MySQLでは5.7、MariaDBでは10.0から「1つのI/Oスレッドが1つのマスターしか設定できないなら、I/Oスレッドごと横に増やせばいいじゃない」 I/Oスレッド, リレーログ, SQLスレッド(MTS可)を「チャンネル」（MariaDBは「コネクション」）という単位で複数起動するもちろんチャンネル間のデータ競合や順序の保証はユーザーがしなければいけない - 101/133

103. (Native) Multi Source Replication master1 slave_channel_1 slave_channel_2 master2 START SLAVE FOR CHANNE L 1 Binlog Dump Applying START SLAVE FOR CHANNE L 2 Binlog Dump Applying 102/133

104. お⼿軽シャード集約スキーマが分かれている場合インポートだけ間違えなければ⼤丈夫スキーマは同じだけどテーブルが分かれている場合インポートだけ間違えなければ⼀応⼤丈夫同じ名前空間のテーブルがあるユニークキーは本当にユニーク︖ サロゲートキーは︖ MySQLやSSDとかの話前編 103/133

105. GTID Global Transaction IDentifier サーバー識別⼦（マスターの@@server_uuid）、ソースを追っかけるならSIDNO（Source ID NO） datadir/auto.cnfに保管されるので、リストア時に注意 - トランザクション識別⼦（マスター上でトランザクションがコミットされた連番）、ソースを追っかけるなら GNO（Group NO） - トランザクションを⼀意に識別するだけで、バイナリーログのイベントを⼀意に識別するわけではないこれ意外と⾒落としがち- 104/133

106. GTIDとマスターバイナリーログにGTIDを埋め込むようになる…くらいしか違いはないとはいえgtid_mode= ONにはenforce_gtid_consistency= ON が必要なので、マスターの振る舞いとしては違いは少なくともサーバーとしての振る舞いはちょっと違う明らかにトランザクションアンセーフなステートメントの実⾏を拒否するようになる - 105/133

107. GTIDとI/Oスレッド master_auto_position= 1の場合、「このファイルのこのポジションから寄越せ︕」の代わりに、「この（=スレーブが既に適⽤済みの）GTID 以外のバイナリーログを頼む」になるサーバー側が動的にファイル名とポジションに変換して送信してくれる。 - Commandが”Binlog Dump”から”Binlog Dump GTID”になる。⾖。 - マスターに伝える「適⽤済みのGTID」はgtid_executed変数に⼊っている。 106/133

108. gtid̲executedの保管バージョン log̲bin 保存先再起動時の gtid̲executedの復元 5.6 OFF N/A N/A(GTIDが有効化できない) 5.6 ON バイナリーログ最新のバイナリーログの Previous̲gtids̲lo g̲eventと最新のバイナリーログの Gtid̲log̲eventを全部⾜したもの 107/133

109. gtid̲executedの保管バージョン log̲bin 保存先再起動時の gtid̲executedの復元 5.7 OFF mysql.gtid̲excute d テーブルから（COMMITのたびに mysql.gtid̲execut edに保存） 5.7 ON バイナリーログ＆テーブルバイナリーログから。テーブルへの記録はバイナリーログのフラッシュの時だけ 108/133

110. GTIDとSQLスレッド GTIDの連番部分（GNO）は気にしないこれから実⾏するトランザクションのGTID（gtid_next）が実⾏済み（gtid_executedに含まれる）の場合、実⾏しない（スキップする）これによってスレーブクラッシュ時の「リレーログの⼆重適⽤」が完全に回避できる - sql/sql̲parse.cc:mysql̲execute̲commandの中で分岐するので、エグゼキューターがそもそも（ほぼ）動かない。 - エグゼキューターなので、SQLスレッドに限らずフツーのスレッドでも同じ動作。 - 109/133

111. GTIDの有効化 masterslave OFF OFF̲PERMISSIVE ON̲PERMISSIVE ON OFF ○ ○ ○ × OFF̲PERMIS SIVE ○ ○ ○ × ON̲PERMISS IVE × ○ ○ ○ ON × ○ ○ ○ 110/133

112. GTIDの有効化 OFF GTIDを振らない。GTIDの振られたイベントが来るとエラる OFF̲PERMISSIVE (5.7から) GTIDを振らないけど、GTIDの振られたイベントが来ても⽂句を⾔わない ON̲PERMISSIVE (5.7から) GTIDを振るけど、GTIDの振られてないイベントが来ても⽂句を⾔わない ON GTIDを振るし、GTIDの振られてないイベントが来るとエラる 111/133

113. 準同期レプリケーション通称semisync ここを同期にする Executorがストレージエンジンに書くa. Executorがバイナリーログに書くb. Binlog Dump Threadがバイナリーログを読むc. I/O ThreadがBinlog Dumpからイベントを受け取ってリレーログに書く d. I/O ThreadからBinlog DumpにACKを返すe. SQL Threadがリレーログからイベントを読み取って⾃⾝のExecutorを叩く f. 112/133

114. 準同期レプリケーションのパラメーター rpl_semi_sync_master_timeout デフォルトが10000（ミリ秒、つまり10秒）と⼤きい- rpl_semi_sync_master_wait_no_slave OFFにすると、スレーブが全滅すると⾃動でAsyncレプリケーションにフォールバックする - 113/133

115. 準同期レプリケーションの拡張 at 5.7 rpl_semi_sync_master_wait_for_slave_count いくつのI/O ThreadがACKを返したらマスター上でOKとされるかを指定可能に - rpl_semi_sync_master_wait_point= {AFTER_SYNC| AFTER_COMMIT} マスター上で、ACKを待ってからストレージエンジンに書き込むか、ストレージエンジンに書き込んでからACK を待つか - 「ロスレス準同期」と⾔ってるやつ- 114/133

116. その他のレプリケーション︖ 115/133

117. 仮想完全同期レプリケーション通称Galera Cluster 本家codershipのGalera Cluster for MySQL, Percona実装のPercona XtraDB Cluster, MariaDB実装のMariaDB Galera Clusterがある - バイナリーログモジュールを使ってるけどバイナリーログとは別のファイルを吐き出す InnoDBストレージエンジンのみサポート binlog̲format= ROW固定 Deadlock detectionじゃなくてLocal certification failureなんだっ⼿⽻先 116/133

118. Galera Cluster ローカルノードにトランザクションを展開1. COMMIT前にGalera Cacheに書き込み2. Galera Cacheのプロパゲート3. 他ノードからACK4. ローカルノードでCOMMIT完了5. 他ノードでCOMMIT6. 117/133

119. Percona XtraBackup レプリケーション︖ グローバルロックをかけてLSNを取り出すa. テーブルスペースファイルのコピーb. コピー中、InnoDBログをスキャンして、開始時以降の LSNのログを全て記録する c. コピーしたテーブルスペースにコピーしたログファイルを適⽤する（クラッシュリカバリー相当） d. これができるってことは頑張ればInnoDBログのストリームによるレプリケーションもできるんじゃ…︖ 俺はがんばらない- 118/133

120. mysqlbinlog -R –stop-never –raw マスターから⾒るとI/Oスレッドに⾒えるmysqlbinlog -Rにバイナリーログの末尾まで⾏っても終了しない--stop-never オプションを付け binlogデコードをかけずにそのままファイルに落とす--raw オプションを付けるとバイナリーログのストリームバックアップができます 119/133

121. Facebook MySQLのmysqlbinlog semisyncスレーブになれるようなオプションが拡張されてるマスターとスレーブは複数の違うDCに配置されてるらしくてマスターと同じDCにバイナリーログ保管⽤のmysqlbinlog さんがいる DC間はAsync, DC内(mysqlbinlog)はSemisyncにすることで、レイテンシーとバイナリーログの保全を両⽅担保 Yoshinori Matsunobuʼs blog: Semi-Synchronous Replication at Facebook 120/133

122. Binlog Events I/Oスレッド相当の実装とbinlogデコーダーの実装ライブラリー地雷が埋まってるらしい。- MySQL Binlog Events でストリーム処理してみた #MySQLUC15 - Labs にある”Hadoop Applier”はこれを使った実装に書き換えるとか書き換えないとか 121/133

123. InnoDB Memcached Plugin 122/133

124. InnoDB Memcached Plugin innodb_api_enable_binlogを有効にするとbinlog吐けるイベントは全てRBR がんばれば「トランザクション対応永続化分散 memcached」が出来るかも知れない innodb_api_trx_levelのデフォルトはREAD- UNCOMMITTEDなので要変更 - innodb_api_bk_commit_intervalのデフォルト5秒も変えた⽅が良さそう - 123/133

125. さあみなさんお待ちかね 124/133

126. 「NOW関数は現在時刻を返さない」の謎に迫る 125/133

127. NOW関数 NOW() は、ステートメントが実⾏を開始する時刻を⽰す定数時間を返します。さらに、SET TIMESTAMP ステートメントによって、 ..snip.. タイムスタンプをゼロ以外の値に設定すると、後続の NOW() が起動されるたびに、その値が返されます。 http://dev.mysql.com/doc/refman/5.6/ja/date-and-time- functions.html#function̲now 126/133

128. NOW関数 mysql56> SELECT NOW(); 2016-02-18 19:37:18 mysql56> SELECT NOW(); 2016-02-18 19:37:19 mysql56> SET timestamp= 1455791802.172832; mysql56> SELECT NOW(); 2016-02-18 19:36:42 mysql56> SELECT NOW(); 2016-02-18 19:36:42 127/133

129. NOW関数とバイナリーログ安全でないと⾒なされない非決定的関数。これらの関数は決定的ではありませんが、ロギングおよびレプリケーション目的の場合は安全として処理されます: CONNECTION̲ID()、CURDATE()、CURRENT̲DATE ()、CURRENT̲TIME()、CURRENT̲TIMESTAMP()、 CURTIME()、LAST̲INSERT̲ID()、LOCALTIME()、 LOCALTIMESTAMP()、NOW()、UNIX̲TIMESTAMP ( )、U T C ̲ D A T E ( )、U T C ̲ T I M E ( )、および UTC̲TIMESTAMP()。 http://dev.mysql.com/doc/refman/5.6/ja/replication-rbr- safe-unsafe.html 128/133

130. NOW関数とバイナリーログ # at 4381 #160212 17:23:20 server id 1056 end_log_pos 4466 Query thread_i d=43 exec_time=0 error_code=0 SET TIMESTAMP=1455265400/*!*/; BEGIN /*!*/; # at 4466 #160212 17:23:20 server id 1056 end_log_pos 4710 Query thread_i d=43 exec_time=0 error_code=0 SET TIMESTAMP=1455265400/*!*/; INSERT INTO t1 VALUES (1691643253,'JBbKOfG7O3qp66Aa5yY8QelD4WL77eKIpneDJ nCbq2Oo0QM6Pm6jOrxLDASCpgXWS1cnooMXjeJj5ahMCnxTXuqkxIxmyK8QLk52PJZ8ykjvA P9N46sbtiKq09SqTc') /*!*/; # at 4710 #160212 17:23:20 server id 1056 end_log_pos 4737 Xid = 943518 COMMIT/*!*/; 129/133

131. レプリケーションでしこたま痛い目を⾒たの先⼈イルカ㌠から 130/133

132. これからレプリケーションで痛い目を⾒るでできることが増えていくゾウ㌠へ 131/133

133. 楽しいよ︕︕１ 132/133

134. Questions and/or Suggestions? 133/133