original_committed_timestampはマスターで実行された時のタイムスタンプが、immediate_commit_timestampはそのサーバーで実際に実行された時のタイムスタンプがそれぞれ入る。
単位はいずれもマイクロ秒。
マスターで実行した
CREATE DATABASE d1
のバイナリーログ。$ /usr/mysql/8.0.1/bin/mysqlbinlog master/data/mysql-bin.000002
..
#170428 17:54:25 server id 1 end_log_pos 226 CRC32 0xe0efd740 GTID last_committed=0 sequence_number=1 original_committed_timestamp=1493369665593157 immediate_commit_timestamp=1493369665593157
# original_commit_timestamp=1493369665593157 (2017-04-28 17:54:25.593157 JST)
# immediate_commit_timestamp=1493369665593157 (2017-04-28 17:54:25.593157 JST)
/*!80001 SET @@session.original_commit_timestamp=1493369665593157*//*!*/;
SET @@SESSION.GTID_NEXT= '00012009-1111-1111-1111-111111111111:1'/*!*/;
# at 226
#170428 17:54:25 server id 1 end_log_pos 323 CRC32 0xc5704ebe Query thread_id=8 exec_time=0 error_code=0 Xid = 44
..
CREATE DATABASE d1
/*!*/;
それがレプリケートされたスレーブのバイナリーログ。
$ /usr/mysql/8.0.1/bin/mysqlbinlog node2/data/mysql-bin.000002
..
# at 154
#170428 17:54:25 server id 1 end_log_pos 233 CRC32 0xddb16cfd GTID last_committed=0 sequence_number=1 original_committed_timestamp=1493369665593157 immediate_commit_timestamp=1493369665643968
# original_commit_timestamp=1493369665593157 (2017-04-28 17:54:25.593157 JST)
# immediate_commit_timestamp=1493369665643968 (2017-04-28 17:54:25.643968 JST)
/*!80001 SET @@session.original_commit_timestamp=1493369665593157*//*!*/;
SET @@SESSION.GTID_NEXT= '00012009-1111-1111-1111-111111111111:1'/*!*/;
# at 233
#170428 17:54:25 server id 1 end_log_pos 330 CRC32 0x1ced03f5 Query thread_id=8 exec_time=0 error_code=0 Xid = 11
..
CREATE DATABASE d1
/*!*/;
これに合わせて、 performance_schema.replication_applier_status_by_worker にも
LAST_APPLIED_TRANSACTION_*_TIMESTAMP
と APPLYING_TRANSACTION_*_TIMESTAMP
が追加されてる。
これを使えば5.7とそれまでの Seconds_Behind_Master みたいにがんばって現在時刻との差とかを求めなくても良くなるようになる(んだと思う)
mysql> SELECT * FROM replication_applier_status_by_worker\G
*************************** 1. row ***************************
CHANNEL_NAME:
WORKER_ID: 0
THREAD_ID: 39
SERVICE_STATE: ON
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_APPLIED_TRANSACTION: 00012009-1111-1111-1111-111111111111:1
LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 2017-04-28 17:54:25.593157
LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 2017-04-28 17:54:25.593157
LAST_APPLIED_TRANSACTION_START_APPLY_TIMESTAMP: 2017-04-28 17:54:25.596175
LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP: 2017-04-28 17:54:25.645874
APPLYING_TRANSACTION:
APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
APPLYING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
APPLYING_TRANSACTION_START_APPLY_TIMESTAMP: 0000-00-00 00:00:00.000000
1 row in set (0.01 sec)
ところで、スレーブのバイナリーログ上の
immediate_commit_timestamp
が p_s. replication_applier_status_by_worker
の LAST_APPLIED_TRANSACTION_*_TIMESTAMP
のどれとも合わないんだけど、これってこれでいいの…?
0 件のコメント :
コメントを投稿