イルカさんチームからゾウさんチームに教えたいMySQLレプリケーション
•
19 gostaram•10,434 visualizações
2016/02/20 第2回 MySQL・PostgreSQLユーザーグループ（MyNA・JPUG）合同DB勉強会 in 東京
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a イルカさんチームからゾウさんチームに教えたいMySQLレプリケーション
Semelhante a イルカさんチームからゾウさんチームに教えたいMySQLレプリケーション (20)
Mais de yoku0825
Último
Último (8)
イルカさんチームからゾウさんチームに教えたいMySQLレプリケーション
- 1. この余⽩はタイトルを書くには狭すぎ る 余⽩じゃなくてタイトル欄なんだけどな 2016/02/20 yoku0825 第2回 MySQL・PostgreSQLユーザーグループ合同DB勉強会 in 東京
- 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
- 13. 意訳 12/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
- 30. ＼こんにちは／ yoku0825＠とある企業のDBA オラクれない- ポスグれない- マイエスキューエる- 家に帰ると 妻の夫- せがれの⽗- ムスメの⽗- Twitter: @yoku0825 Blog: ⽇々の覚書 MyNA ML: ⽇本MySQLユーザ会 29/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
- 39. MySQLのレプリケーションアーキテクチャー Executorがストレージエンジンに書く1. Executorがバイナリーログに書く2. Binlog Dump Threadがバイナリーログを読む3. I/O ThreadがBinlog Dumpからイベントを受け取ってリレ ーログに書く 4. SQL Threadがリレーログからイベントを読み取って⾃⾝の Executorを叩く 5. 38/133
- 41. MySQLのレプリケーションアーキテクチャー Executorがストレージエンジンに書く1. Executorがバイナリーログに書く2. Binlog Dump Threadがバイナリーログを読む3. I/O ThreadがBinlog Dumpからイベントを受け取ってリレ ーログに書く 4. SQL Threadがリレーログからイベントを読み取って⾃⾝の Executorを叩く 5. 40/133
- 42. Executorがバイナリーログに書く Executorから⾒たバイナリーログは binlogストレージエン ジン MySQLにもともと実装されているXAトランザクションを使 って⼆相コミット binlog̲cacheにXA PREPAREしておいてXA COMMIT- クラッシュしてもXA RECOVERはできない＞＜- 41/133
- 45. MySQLのレプリケーションアーキテクチャー Executorがストレージエンジンに書く1. Executorがバイナリーログに書く2. Binlog Dump Threadがバイナリーログを読む3. I/O ThreadがBinlog Dumpからイベントを受け取ってリレ ーログに書く 4. SQL Threadがリレーログからイベントを読み取って⾃⾝の Executorを叩く 5. 44/133
- 46. Binlog Dump Threadがバイナリーログを読む fsyncしててもしてなくてもwriteされた時点から読める マスターのmysqldではクライアントからのコネクション扱 い スレーブでSTART SLAVE => マスターで認証 => ESTABLISH後はマスター側からsendtoできる - 45/133
- 47. MySQLのレプリケーションアーキテクチャー Executorがストレージエンジンに書く1. Executorがバイナリーログに書く2. Binlog Dump Threadがバイナリーログを読む3. I/O ThreadがBinlog Dumpからイベントを受け取ってリ レーログに書く 4. SQL Threadがリレーログからイベントを読み取って⾃⾝の Executorを叩く 5. 46/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
- 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
- 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
- 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
- 61. MBR 基本はSBR、非決定性ステートメントだけRBRで使い分け る。MBRと呼ぶのは稀。 いいとこ尽くしに聞こえなくもないけど、実際は思わぬとこ ろでRBRにフォールバックして割とカジュアルに死ぬ。 マスタースレーブでトリガーをズラして調整している時 にRBRに落ちて泣いたり。 - 何故かWHERE pkey = ?なクエリーにLIMIT 1とか付けられ てRBRに落ちて Bug#74118 の洗礼を受けたり。 - MySQL 5.1の⼀部のリビジョンだけこれがデフォルト。 弊社はこれです。。 60/133
- 63. pt-table-checksum SBRとRBRでそれぞれチェックサムを計算してテーブルに突 っ込むクエリーを発⾏ マスター上では当然SBRでもRBRでも同じチェックサム になる - スレーブではSBRで来たイベントは スレーブでチェックサ ムを計算 、RBRで来たイベントは マスターで計算されたチ ェックサムがそのままカラムに⼊る これを⽐較することができる 62/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
- 71. MTSコーディネーター MySQL 5.6ではスキーマが分かれていることで⼲渉しない ことを担保（5.7のslave_parallel_type= DATABASE相当） 5.7ではマスターでbinlogに記録された時の直前のコミット のタイムスタンプをベースに⼲渉しないことを担保するモー ドが登場（slave_parallel_type= LOGICAL_CLOCK） マスター上でロックが競合せずにグループコミットの中 に⼊れたってことはスレーブでも競合しないってことだ よね︖ という理屈 - 70/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
- 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
- 85. relay_log_info_repository= TABLE && innodb_flush_log_at_trx_commit = 1 リレーログ master.info SQLスレッド relay̲log.info 影響 受け取ってない 記録してない 適⽤してない 記録してない なし 受け取ってる 記録してない 適⽤してない 記録してない リレーログ⼆重 受信 受け取ってる 記録してない 適⽤した 記録した リレーログ⼆重 受信 受け取ってる 記録した 適⽤してない 記録してない なし 受け取ってる 記録した 適⽤した 記録した なし 84/133
- 87. relay_log_recovery リレーログ master.info SQLスレッド relay̲log.info 影響 受け取ってない 記録してない 適⽤してない 記録してない なし 受け取ってる 記録してない 適⽤した 記録してない リレーログ⼆重 受信 + リレー ログ⼆重適⽤ = 三重コミッ ト 受け取ってる 記録した 適⽤してない 記録してない なし 受け取ってる 記録した 適⽤した 記録した なし 86/133
- 88. レプリケーションとスレーブクラッシュ 男らしくバックアップからリストアする 割と真⾯目に。 毎回リストアすると割り切れば、ACIDのDは無茶な⽅向 に振れて性能が稼げるお( ＾ω＾) - 87/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
- 97. これまでのレプリケーションの制約 I/Oスレッド - リレーログ - SQLスレッド で1組 5.6からSQLスレッドは並列化可能に- I/Oスレッドが1本しかないということは、「スレーブか ら⾒たマスターは1つしか存在できない」 マスターから⾒たスレーブはいくつあってもいい（た だのクライアントなので、（性能を考えなければ） max_connections未満ならいくらでも） - 96/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
- 105. GTID Global Transaction IDentifier サーバー識別⼦（マスターの@@server_uuid）、ソースを 追っかけるならSIDNO（Source ID NO） datadir/auto.cnfに保管されるので、リストア時に注 意 - トランザクション識別⼦（マスター上でトランザクショ ンがコミットされた連番）、ソースを追っかけるなら GNO（Group NO） - トランザクションを⼀意に識別するだけで、バイナリーログ のイベントを⼀意に識別するわけではない これ意外と⾒落としがち- 104/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
- 111. GTIDの有効化 masterslave OFF OFF̲PERMISSIVE ON̲PERMISSIVE ON OFF ○ ○ ○ × OFF̲PERMIS SIVE ○ ○ ○ × ON̲PERMISS IVE × ○ ○ ○ ON × ○ ○ ○ 110/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
- 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
- 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
- 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
- 125. さあみなさん お待ちかね 124/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
- 133. 楽しい よ︕︕１ 132/133