复制延迟(Seconds_Behind_Master)测试
测试环境: MySQL 5.7.19
测试主从时间差:
检查主从系统时间差,同时在主库和从库执行SELECT NOW()语句:
主库:2019-06-24 10:57:56
从库:2019-06-24 10:58:10
从库比主库提前14秒,主从时间差14秒。
在主库上执行(使用基于语句格式复制BIN):
select now();
update tb003 set c1=SLEEP(20) where id=1;
select now();
主库上上执行效果:
mysql> select now();
+---------------------+
| now() |
+---------------------+
| 2019-06-24 11:01:54 |
+---------------------+
1 row in set (0.00 sec)
mysql> update tb003 set c1=SLEEP(20) where id=1;
Query OK, 1 row affected, 1 warning (20.06 sec)
Rows matched: 1 Changed: 1 Warnings: 1
mysql> select now();
+---------------------+
| now() |
+---------------------+
| 2019-06-24 11:02:14 |
+---------------------+
1 row in set (0.00 sec)
主库上生成的binlog解析结果:
#190624 11:01:54 server id 1614520 end_log_pos 259 CRC32 0xcf2313f1 GTID last_committed=0 sequence_number=1 rbr_only=no
SET @@SESSION.GTID_NEXT= '025fd638-89ea-11e9-a749-40f2e9cf3aaa:9'/*!*/;
# at 259
#190624 11:01:54 server id 1614520 end_log_pos 340 CRC32 0xa14a2bcb Query thread_id=3186 exec_time=20 error_code=0
SET TIMESTAMP=1561345314/*!*/;
BEGIN
/*!*/;
# at 340
#190624 11:01:54 server id 1614520 end_log_pos 456 CRC32 0xc283c9af Query thread_id=3186 exec_time=20 error_code=0
use `db001`/*!*/;
SET TIMESTAMP=1561345314/*!*/;
update tb003 set c1=SLEEP(20) where id=1
/*!*/;
# at 456
#190624 11:01:54 server id 1614520 end_log_pos 487 CRC32 0x0f3bdc57 Xid = 10020
COMMIT/*!*/;
从库上relay log解析结果:
BINLOG '
+zwQXQ+4ohgAdwAAAAAAAAAgAAQANS43LjE5LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
Af0UlBk=
'/*!*/;
# at 313
#190624 11:01:54 server id 1614520 end_log_pos 259 CRC32 0xcf2313f1 GTID last_committed=0 sequence_number=1 rbr_only=no
SET @@SESSION.GTID_NEXT= '025fd638-89ea-11e9-a749-40f2e9cf3aaa:9'/*!*/;
# at 378
#190624 11:01:54 server id 1614520 end_log_pos 340 CRC32 0xa14a2bcb Query thread_id=3186 exec_time=20 error_code=0
SET TIMESTAMP=1561345314/*!*/;
BEGIN
/*!*/;
# at 459
#190624 11:01:54 server id 1614520 end_log_pos 456 CRC32 0xc283c9af Query thread_id=3186 exec_time=20 error_code=0
use `db001`/*!*/;
SET TIMESTAMP=1561345314/*!*/;
update tb003 set c1=SLEEP(20) where id=1
/*!*/;
# at 575
#190624 11:01:54 server id 1614520 end_log_pos 487 CRC32 0x0f3bdc57 Xid = 10020
COMMIT/*!*/;
从库上生成binlog解析结果(从库上默认binlog_format=row):
#190624 11:01:54 server id 1614520 end_log_pos 259 CRC32 0x6e1a971f GTID last_committed=0 sequence_number=1 rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= '025fd638-89ea-11e9-a749-40f2e9cf3aaa:9'/*!*/;
# at 259
#190624 11:01:54 server id 1614520 end_log_pos 332 CRC32 0x063cd6ca Query thread_id=3186 exec_time=54 error_code=0
SET TIMESTAMP=1561345314/*!*/;
BEGIN
/*!*/;
# at 332
#190624 11:01:54 server id 1614520 end_log_pos 396 CRC32 0x405b61c7 Rows_query
# update tb003 set c1=SLEEP(20) where id=1
# at 396
#190624 11:01:54 server id 1614520 end_log_pos 448 CRC32 0x015803f1 Table_map: `db001`.`tb003` mapped to number 232
# at 448
#190624 11:01:54 server id 1614520 end_log_pos 518 CRC32 0xb59069f9 Update_rows: table id 232 flags: STMT_END_F
BINLOG '
Ij0QXR24ohgAQAAAAIwBAACAACh1cGRhdGUgdGIwMDMgc2V0IGMxPVNMRUVQKDIwKSB3aGVyZSBp
ZD0xx2FbQA==
Ij0QXRO4ohgANAAAAMABAAAAAOgAAAAAAAEABWRiMDAxAAV0YjAwMwADCAMRAQAC8QNYAQ==
Ij0QXR+4ohgARgAAAAYCAAAAAOgAAAAAAAEAAgAD///4AQAAAAAAAAABAAAAXRA89fgBAAAAAAAA
AAAAAABdED0i+WmQtQ==
'/*!*/;
### UPDATE `db001`.`tb003`
### WHERE
### @1=1 /* LONGINT meta=0 nullable=0 is_null=0 */
### @2=1 /* INT meta=0 nullable=1 is_null=0 */
### @3=1561345269 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */
### SET
### @1=1 /* LONGINT meta=0 nullable=0 is_null=0 */
### @2=0 /* INT meta=0 nullable=1 is_null=0 */
### @3=1561345314 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */
# at 518
#190624 11:01:54 server id 1614520 end_log_pos 549 CRC32 0xae037515 Xid = 6241
COMMIT/*!*/;
无论时主库binlog事件中还是从库relaylog事件以及从库binlog事件中记录的时间都是事务语句执行开始时间:
SET TIMESTAMP=1561345314/*!*/;
SELECT FROM_UNIXTIME(1561345314);
+---------------------------+
| FROM_UNIXTIME(1561345314) |
+---------------------------+
| 2019-06-24 11:01:54 |
+---------------------------+
exec_time计算:The time from when the query started to when it was logged in the binlog, in seconds.
1、由于SQL语句中使用函数SLEEP(20),因此SQL语句执行时间=SLEEP(20)的执行时间+UPDATE操作的执行时间,而UPDATE操作的执行时间在10ms以内,因此整个SQL语句在主库的执行时间=20S,因此主库binlog的中记录exec_time=20
2、从库的relaylog用来存放主库传递过来的binlog,因此从库relaylog与主库binlog相同,从库relaylog中记录也是exec_time=20
3、由于主库使用binlog_format=statement的复制格式,因此SQL语句被传递到从库并原样执行,同样执行需要20S,但该语句在主库的开始执行时间(the query started)为2019-06-24 11:01:54,而在从库执行结束时间(log in binlog)为2019-06-24 11:02:48,因此从库binlog中记录时间exec_time=54,忽略主从事务日志落盘和网络传输时间,exec_time=54S=主库语句执行时间(20)+从库语句执行时间(20S)+主从时间差(14S)。
标签:11,01,20,log,exec,54,Replication,MySQL,id
来源: https://www.cnblogs.com/gaogao67/p/11078478.html