mysql exec_time很长,MySQL Replication--复制延迟之exec_time测试

复制延迟(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

你可能感兴趣的:(mysql,exec_time很长)