mysql io线程 原理_二十二：从库的IO线程（笔记）

最新推荐文章于 2023-02-10 10:33:32 发布
最新推荐文章于 2023-02-10 10:33:32 发布
阅读量558 收藏
点赞数
文章标签： mysql io线程 原理
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_36403956/article/details/113430131
版权
本文详细介绍了MySQL从库IO线程的工作原理，包括读取主库binlog的位置、写入relay log的过程以及GTID与AUTO_POSITION模式下的不同行为。在异常重启后，从库如何根据不同参数恢复并处理不完整事务，强调了sync_master_info和sync_relay_log参数的重要性。通过对实验数据的分析，展示了不同模式下主从同步的细节和恢复策略。
摘要由CSDN通过智能技术生成

, "\v\000\000\000\a\000\000\000\000\t\000\344\376\177\000\000\340\252U\354\377\177\000\000\242kL\001\000\000\000\000\002\000\000\000\000\000\000\000\346?\001\000\000\000\000\002\000\000\000\000\000\000\000\346?\001\000\000\000\000\300\252U\354\377\177\000\000L?\001\n\000\000\000ЪU\354\377\177\000\000L?\001\000\000\000\000\360\252U\354\377\177\000\000\240\343\221\001\000\000\000\000\000\253U\354\377\177\000\000\340\b\000\344\376\177\000\000\020\253U\354\377\177\000\000\"I\353\001\000\000\000\000\000\t\000\344\376\177\000\000\240\255U\354\377\177\000\000\060\253U\354\377\177\000\000\272~\356\000\000\000\000\000\v\000\000\000\005\000\000\000\240\255U\354\377\177\000\000\000\256U\354\377\177\000\000\246\323M\001\000\000\000\000\221\333/\002\000\000\000\000\030=\000\344\376\177", '\000' , "\002\000\000\000\000\000\000\000\346?\001\000\000\000\000\016\202\036\002\000\000\000\000\250"...

(gdb) p pos

$19 = 4

不是AUTO

- server_id

- MASTER INFO 表的读取位点

- MASTER INFO 表的读取binlog文件名

主库读取 com_binlog_dump

(gdb) p pos

$1 = 3587

(gdb) p packet + 10

$3 = 0x7ffedc00a88b "binlog.000005"

我们可以看到即便开启了GTID不开启AUTO也不会根据GTID来读取。

->循环读取event

进入状态 stage_waiting_for_master_to_send_event

->将读取的event写入到 relay log

进入状态Queueing master event to the relay log

->queue_event 读取的event写入到 relay log

检测GTID event的合法性

Cannot replicate GTID-transaction when @@GLOBAL.GTID_MODE = OFF, at file %.512s, position %lld.

Cannot replicate anonymous transaction when AUTO_POSITION = 1, at file %.512s, position %lld.

Cannot replicate anonymous transaction when @@GLOBAL.GTID_MODE = ON, at file %.512s, position %lld.

->rli->relay_log.append_buffer 进行relay log写入

->MYSQL_BIN_LOG::after_append_to_relay_log //进行写入后处理

->flush_and_sync 函数根据relay log sync参数设置决定是否做sync操作 单位是event个数

->MYSQL_BIN_LOG::sync_binlog_file 判断是否进行刷盘

->can_rotate 根据这个值决定是否计入Retrieved_Gtid_Set 边界分析器

->进行relay log切换

->更改相关被变量

master 位置/master 文件

增加容量log_space_total

mi->set_master_log_pos(mi->get_master_log_pos() + inc_pos);//增加master 位置

rli->relay_log.harvest_bytes_written(&rli->log_space_total);

/*

If this event is GTID_LOG_EVENT we store its GTID to add to the

Retrieved_Gtid_Set later, when the last event of the transaction be

queued.

*/

if (event_type == binary_log::GTID_LOG_EVENT)

{

mi->set_last_gtid_queued(gtid);

}

->flush_master_info(mi, FALSE)

->Rpl_info_table::do_flush_info

通过参数sync_master设置决定多少个event 进行写table

handler->set_sync_period(sync_masterinfo_period);

if (!(force || (sync_period &&

++(sync_counter) >= sync_period)))//如果没有达到 sync的次数(sync_master_info 或者 sync_relay_log_info次数 不做flush 不写表 直接返回)

DBUG_RETURN(0);//但是relay_log_info依赖于是否是table模式如果是table模式则会在commit的时候做相应的flush Slave_worker::flush_info

```

###二、证明sync_master_info单位是Event

设置sync_master_info=1

主库做一个大事务，观察slave_master_info表如下：

```

mysql> select * from slave_master_info \G;

*************************** 1. row ***************************

Number_of_lines: 25

Master_log_name: binlog.000002

Master_log_pos: 1222540

```

主库执行：

```

/mysqldata/mysql3340/bin/mysqlbinlog binlog.000002 --base64-output='decode-rows'|grep -C 10 -E "BEGIN|COMMIT"

```

主库event 可以看到在中间

```

BEGIN

/*!*/;

# at 992468

#190519 13:07:26 server id 413340 end_log_pos 992520 CRC32 0x5d85ea03 Table_map: `testmts`.`testio` mapped to number 111

# at 992520

#190519 13:07:26 server id 413340 end_log_pos 1000735 CRC32 0xfceb6697 Write_rows: table id 111

# at 1000735

#190519 13:07:26 server id 413340 end_log_pos 1008950 CRC32 0x0ca6515c Write_rows: table id 111

# at 1008950

#190519 13:07:26 server id 413340 end_log_pos 1017165 CRC32 0x21d7b17d Write_rows: table id 111

# at 1017165

--

# at 2939475

#190519 13:07:26 server id 413340 end_log_pos 2947690 CRC32 0xcb553fab Write_rows: table id 111

# at 2947690

#190519 13:07:26 server id 413340 end_log_pos 2955905 CRC32 0xd42382c9 Write_rows: table id 111

# at 2955905

#190519 13:07:26 server id 413340 end_log_pos 2964120 CRC32 0xe516b98a Write_rows: table id 111

# at 2964120

#190519 13:07:26 server id 413340 end_log_pos 2967035 CRC32 0x9cbfbc0a Write_rows: table id 111 flags: STMT_END_F

# at 2967035

#190519 13:07:26 server id 413340 end_log_pos 2967066 CRC32 0xb907da17 Xid = 45

COMMIT/*!*/;

SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;

DELIMITER ;

# End of log file

/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

You have mail in /var/spool/mail/root

```

###三、测试AUTO_POSITION=1和POSTION模式下MysqlD异常重启的恢复过程

下面是 recover_relay_log=0 的情况 POS和GTID AUTO_POSITION=1不同的处理。

断点

```

Master_info::set_master_log_pos 设置master info io thread 读取主库的binlog pos

Relay_log_info::set_group_relay_log_pos 设置relay info sql thread 从库读取relay pos的位置

```

- GTID

AUTO_POSITION binlog recover_relay_log=0的情况下：

DUMP线程会重新发送最后一个事务给从库，从库使用Crash前的Relay_Log_Pos进行读取。relay log可能出现不完整的事务。这种情况会触发回滚机制。单线程会在GTID event 中回滚，MTS会由协调线程调用coord_handle_partial_binlogged_transaction回滚

```

change master to

master_host='192.168.99.41',

master_user='repl',

master_password='gelc123',

master_port=3340,

AUTO_POSITION=1;

start slave;

```

主库：

```

# at 912

#190519 21:22:16 server id 413340 end_log_pos 977 CRC32 0x5840ca71 GTID last_committed=1 sequence_number=2 rbr_only=yes

/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;

SET @@SESSION.GTID_NEXT= 'cb7ea36e-670f-11e9-b483-5254008138e4:2'/*!*/;

# at 977

#190519 21:22:16 server id 413340 end_log_pos 1052 CRC32 0xcd8345de Query thread_id=3 exec_time=13 error_code=0

SET TIMESTAMP=1558272136/*!*/;

BEGIN

/*!*/;

# at 1052

#190519 21:22:16 server id 413340 end_log_pos 1104 CRC32 0x782391dd Table_map: `testmts`.`testgp` mapped to number 108

# at 1104

#190519 21:22:16 server id 413340 end_log_pos 9319 CRC32 0x8de0fbdd Write_rows: table id 108

# at 9319

#190519 21:22:16 server id 413340 end_log_pos 17534 CRC32 0xae798162 Write_rows: table id 108

# at 17534

#190519 21:22:16 server id 413340 end_log_pos 25749 CRC32 0x683b9e95 Write_rows: table id 108

# at 25749

--

# at 477574

#190519 21:22:16 server id 413340 end_log_pos 485789 CRC32 0x44e99850 Write_rows: table id 108

# at 485789

#190519 21:22:16 server id 413340 end_log_pos 494004 CRC32 0x280300fd Write_rows: table id 108

# at 494004

#190519 21:22:16 server id 413340 end_log_pos 502219 CRC32 0x075c8ff8 Write_rows: table id 108

# at 502219

#190519 21:22:16 server id 413340 end_log_pos 503274 CRC32 0x08c3f96c Write_rows: table id 108 flags: STMT_END_F

# at 503274

#190519 21:22:16 server id 413340 end_log_pos 503305 CRC32 0x3b6dd31c Xid = 26

COMMIT/*!*/;

SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;

DELIMITER ;

```

```

mysql> show slave status \G

*************************** 1. row ***************************

Slave_IO_State: Queueing master event to the relay log

Master_Host: 192.168.99.41

Master_User: repl

Master_Port: 3340

Connect_Retry: 60

Master_Log_File: binlog.000001

Read_Master_Log_Pos: 165404

Relay_Log_File: relay.000002

Relay_Log_Pos: 1119

Relay_Master_Log_File: binlog.000001

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

```

crash 后

```

mysql> show slave status \G

*************************** 1. row ***************************

Slave_IO_State:

Master_Host: 192.168.99.41

Master_User: repl

Master_Port: 3340

Connect_Retry: 60

Master_Log_File: binlog.000001

Read_Master_Log_Pos: 190049

Relay_Log_File: relay.000002

Relay_Log_Pos: 1119

Relay_Master_Log_File: binlog.000001

```

不完整的事物日志如下：

```

# at 1119

#190519 21:22:16 server id 413340 end_log_pos 977 CRC32 0x5840ca71 GTID last_committed=1 sequence_number=2 rbr_only=yes

/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;

SET @@SESSION.GTID_NEXT= 'cb7ea36e-670f-11e9-b483-5254008138e4:2'/*!*/;

# at 1184

#190519 21:22:16 server id 413340 end_log_pos 1052 CRC32 0xcd8345de Query thread_id=3 exec_time=13 error_code=0

SET TIMESTAMP=1558272136/*!*/;

BEGIN

/*!*/;

# at 1259

#190519 21:22:16 server id 413340 end_log_pos 1104 CRC32 0x782391dd Table_map: `testmts`.`testgp` mapped to number 108

# at 1311

#190519 21:22:16 server id 413340 end_log_pos 9319 CRC32 0x8de0fbdd Write_rows: table id 108

# at 9526

#190519 21:22:16 server id 413340 end_log_pos 17534 CRC32 0xae798162 Write_rows: table id 108

# at 17741

#190519 21:22:16 server id 413340 end_log_pos 25749 CRC32 0x683b9e95 Write_rows: table id 108

# at 25956

WARNING: The range of printed events ends with a row event or a table map event that does not have

the STMT_END_F flag set. This might be because the last statement was not fully written to the log,

or because you are using a --stop-position or --stop-datetime that refers to an event in the middle of a statement.

The event(s) from the partial statement have not been written to output.

```

启动后 IO_THREAD

```

mysql> show slave status \G

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.99.41

Master_User: repl

Master_Port: 3340

Connect_Retry: 60

Master_Log_File: binlog.000001

Read_Master_Log_Pos: 503305

Relay_Log_File: relay.000002

Relay_Log_Pos: 1119

Relay_Master_Log_File: binlog.000001

Slave_IO_Running: Yes

Slave_SQL_Running: No

```

启动IO TRHEAD后 重新传输了，但是老的没有完全传输完成的日志还在relay log

新的日志已经有了 ，老的也还在。

```

# at 445

#190519 21:22:16 server id 413340 end_log_pos 977 CRC32 0x5840ca71 GTID last_committed=1 sequence_number=2 rbr_only=yes

/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;

SET @@SESSION.GTID_NEXT= 'cb7ea36e-670f-11e9-b483-5254008138e4:2'/*!*/;

# at 510

#190519 21:22:16 server id 413340 end_log_pos 1052 CRC32 0xcd8345de Query thread_id=3 exec_time=13 error_code=0

SET TIMESTAMP=1558272136/*!*/;

SET @@session.pseudo_thread_id=3/*!*/;

SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;

SET @@session.sql_mode=1075838976/*!*/;

SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;

/*!\C utf8 *//*!*/;

SET @@session.character_set_client=83,@@session.collation_connection=83,@@session.collation_server=33/*!*/;

SET @@session.lc_time_names=0/*!*/;

SET @@session.collation_database=DEFAULT/*!*/;

BEGIN

/*!*/;

# at 585

#190519 21:22:16 server id 413340 end_log_pos 1104 CRC32 0x782391dd Table_map: `testmts`.`testgp` mapped to number 108

# at 637

#190519 21:22:16 server id 413340 end_log_pos 9319 CRC32 0x8de0fbdd Write_rows: table id 108

# at 8852

#190519 21:22:16 server id 413340 end_log_pos 17534 CRC32 0xae798162 Write_rows: table id 108

# at 17067

#190519 21:22:16 server id 413340 end_log_pos 25749 CRC32 0x683b9e95 Write_rows: table id 108 (以上本来已经传输了)

# at 25282

--

# at 477107

#190519 21:22:16 server id 413340 end_log_pos 485789 CRC32 0x44e99850 Write_rows: table id 108

# at 485322

#190519 21:22:16 server id 413340 end_log_pos 494004 CRC32 0x280300fd Write_rows: table id 108

# at 493537

#190519 21:22:16 server id 413340 end_log_pos 502219 CRC32 0x075c8ff8 Write_rows: table id 108

# at 501752

#190519 21:22:16 server id 413340 end_log_pos 503274 CRC32 0x08c3f96c Write_rows: table id 108 flags: STMT_END_F

# at 502807

#190519 21:22:16 server id 413340 end_log_pos 503305 CRC32 0x3b6dd31c Xid = 26

COMMIT/*!*/;

```

- POSITION

在 recover_relay_log=0的情况下从库会从Read_Master_Log_Pos的位置接着拉取replay log，一旦Read_Master_Log_Pos和replay log出现问题那么将会导致从库异常。主库只需要从Relay_Log_Pos的位置应用即可。因此参数

- sync_relay_log=1

- sync_master_info=1

是必须的。

```

change master to

master_host='192.168.99.41',

master_user='repl',

master_password='gelc123',

master_port=3340,

MASTER_LOG_FILE='binlog.000001',

MASTER_LOG_POS=154;

start slave;

```

```

mysql> show slave status \G;

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.99.41

Master_User: repl

Master_Port: 3340

Connect_Retry: 60

Master_Log_File: binlog.000001

Read_Master_Log_Pos: 912

Relay_Log_File: relay.000002

Relay_Log_Pos: 1075

Relay_Master_Log_File: binlog.000001

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

```

写入途中：

```

mysql> show slave status \G;

*************************** 1. row ***************************

Slave_IO_State: Queueing master event to the relay log

Master_Host: 192.168.99.41

Master_User: repl

Master_Port: 3340

Connect_Retry: 60

Master_Log_File: binlog.000001

Read_Master_Log_Pos: 124329

Relay_Log_File: relay.000002

Relay_Log_Pos: 1075

Relay_Master_Log_File: binlog.000001

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

```

主库binlog：

```

BEGIN

/*!*/;

# at 1052

#190519 16:43:43 server id 413340 end_log_pos 1104 CRC32 0x1b959719 Table_map: `testmts`.`testgp` mapped to number 108

# at 1104

#190519 16:43:43 server id 413340 end_log_pos 9319 CRC32 0x98ff5e73 Write_rows: table id 108

# at 9319

#190519 16:43:43 server id 413340 end_log_pos 17534 CRC32 0xbb6624cc Write_rows: table id 108

# at 17534

#190519 16:43:43 server id 413340 end_log_pos 25749 CRC32 0x7d243b3b Write_rows: table id 108

# at 25749

--

# at 477574

#190519 16:43:43 server id 413340 end_log_pos 485789 CRC32 0x51f63dfe Write_rows: table id 108

# at 485789

#190519 16:43:43 server id 413340 end_log_pos 494004 CRC32 0x3d1ca553 Write_rows: table id 108

# at 494004

#190519 16:43:43 server id 413340 end_log_pos 502219 CRC32 0x12432a56 Write_rows: table id 108

# at 502219

#190519 16:43:43 server id 413340 end_log_pos 503274 CRC32 0x4373f461 Write_rows: table id 108 flags: STMT_END_F

# at 503274

#190519 16:43:43 server id 413340 end_log_pos 503305 CRC32 0xe33a6266 Xid = 60

COMMIT/*!*/;

```

Crash启动后日志如下：

```

# at 321652

#190519 16:43:43 server id 413340 end_log_pos 329704 CRC32 0xbf87ced1 Write_rows: table id 108

# at 329867

#190519 16:43:43 server id 413340 end_log_pos 337919 CRC32 0x2f3bd840 Write_rows: table id 108

# at 338082

#190519 16:43:43 server id 413340 end_log_pos 346134 CRC32 0xe317c093 Write_rows: table id 108

# at 346297

#190519 16:43:43 server id 413340 end_log_pos 354349 CRC32 0x81e3ea0d Write_rows: table id 108

# at 354512

#190519 16:43:43 server id 413340 end_log_pos 362564 CRC32 0x7f51fc3a Write_rows: table id 108

# at 362727

#190519 16:25:17 server id 953340 end_log_pos 362770 CRC32 0xb6611a85 Rotate to relay.000003 pos: 4

WARNING: The range of printed events ends with a row event or a table map event that does not have the STMT_END_F flag set. This might be because the last statement was not fully written to the log, or because you are using a --stop-position or --stop-datetime that refers to an event in the middle of a statement. The event(s) from the partial statement have not been written to output.

ROLLBACK /* added by mysqlbinlog */ /*!*/;

SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;

DELIMITER ;

# End of log file

/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

[root@gp1 log]# /mysqldata/mysql3340/bin/mysqlbinlog --base64-output='decode-rows' relay.000003

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;

/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;

DELIMITER /*!*/;

# at 4

#190519 16:25:17 server id 953340 end_log_pos 123 CRC32 0xe6fd01bf Start: binlog v 4, server v 5.7.22-22-debug-log created 190519 16:25:17

# This Format_description_event appears in a relay log and was generated by the slave thread.

# at 123

#190519 16:25:17 server id 953340 end_log_pos 154 CRC32 0xde5482b5 Previous-GTIDs

# [empty]

# at 154

#700101 8:00:00 server id 413340 end_log_pos 0 CRC32 0x86e86060 Rotate to binlog.000001 pos: 362564

# at 198

#190519 16:42:31 server id 413340 end_log_pos 0 CRC32 0x5361aca0 Start: binlog v 4, server v 5.7.22-22-debug-log created 190519 16:42:31

# at 317

#190519 16:43:43 server id 413340 end_log_pos 370779 CRC32 0x8b7abae8 Write_rows: table id 108

# at 8532

#190519 16:43:43 server id 413340 end_log_pos 378994 CRC32 0x28e1279c Write_rows: table id 108

# at 16747

#190519 16:43:43 server id 413340 end_log_pos 387209 CRC32 0x278d98ed Write_rows: table id 108

# at 24962

#190519 16:43:43 server id 413340 end_log_pos 395424 CRC32 0x85d21655 Write_rows: table id 108

# at 33177

#190519 16:43:43 server id 413340 end_log_pos 403639 CRC32 0x156e00c4 Write_rows: table id 108

# at 41392

#190519 16:43:43 server id 413340 end_log_pos 411854 CRC32 0xed83b3ac Write_rows: table id 108

# at 49607

#190519 16:43:43 server id 413340 end_log_pos 420069 CRC32 0x465939b4 Write_rows: table id 108

# at 57822

#190519 16:43:43 server id 413340 end_log_pos 428284 CRC32 0xaab146d2 Write_rows: table id 108

# at 66037

#190519 16:43:43 server id 413340 end_log_pos 436499 CRC32 0x97f1428f Write_rows: table id 108

WARNING: The range of printed events ends with a row event or a table map event that does not have the STMT_END_F flag set. This might be because the last statement was not fully written to the log, or because you are using a --stop-position or --stop-datetime that refers to an event in the middle of a statement. The event(s) from the partial statement have not been written to output.

SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;

DELIMITER ;

# End of log file

/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

[root@gp1 log]# /mysqldata/mysql3340/bin/mysqlbinlog --base64-output='decode-rows' relay.000005

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;

/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;

DELIMITER /*!*/;

# at 4

#190519 16:31:57 server id 953340 end_log_pos 123 CRC32 0xecc598ac Start: binlog v 4, server v 5.7.22-22-debug-log created 190519 16:31:57

# This Format_description_event appears in a relay log and was generated by the slave thread.

# at 123

#190519 16:31:57 server id 953340 end_log_pos 154 CRC32 0x21c8a43a Previous-GTIDs

# [empty]

# at 154

#700101 8:00:00 server id 413340 end_log_pos 0 CRC32 0xeed34528 Rotate to binlog.000001 pos: 428284

# at 198

#190519 16:42:31 server id 413340 end_log_pos 0 CRC32 0x5361aca0 Start: binlog v 4, server v 5.7.22-22-debug-log created 190519 16:42:31

# at 317

#190519 16:43:43 server id 413340 end_log_pos 436499 CRC32 0x97f1428f Write_rows: table id 108

# at 8532

#190519 16:43:43 server id 413340 end_log_pos 444714 CRC32 0xfd447f7d Write_rows: table id 108

# at 16747

#190519 16:43:43 server id 413340 end_log_pos 452929 CRC32 0xc4c67bff Write_rows: table id 108

# at 24962

#190519 16:43:43 server id 413340 end_log_pos 461144 CRC32 0x6dbd096a Write_rows: table id 108

# at 33177

#190519 16:43:43 server id 413340 end_log_pos 469359 CRC32 0xb42d58b6 Write_rows: table id 108

# at 41392

#190519 16:43:43 server id 413340 end_log_pos 477574 CRC32 0x7a2e502d Write_rows: table id 108

# at 49607

#190519 16:43:43 server id 413340 end_log_pos 485789 CRC32 0x51f63dfe Write_rows: table id 108

# at 57822

#190519 16:43:43 server id 413340 end_log_pos 494004 CRC32 0x3d1ca553 Write_rows: table id 108

# at 66037

#190519 16:43:43 server id 413340 end_log_pos 502219 CRC32 0x12432a56 Write_rows: table id 108

# at 74252

#190519 16:43:43 server id 413340 end_log_pos 503274 CRC32 0x4373f461 Write_rows: table id 108 flags: STMT_END_F

# at 75307

#190519 16:43:43 server id 413340 end_log_pos 503305 CRC32 0xe33a6266 Xid = 60

COMMIT/*!*/;

SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;

```

从 end_log_pos 可以看到他们凑成了一个完整的事务日志。

七焱
关注
Debezium报错处理系列之第118篇：Cannot replicate anonymous transaction when @@GLOBAL.GTID_MODE = ON
zhengzaifeidelushang的博客
10-02 142
Debezium报错处理系列之第118篇：Cannot replicate anonymous transaction when @@GLOBAL.GTID_MODE = ON
mysql aio与并发执行线程_mysql 原理 ~ 线程与IO
weixin_32968007的博客
01-19 571
一 简介:今天来聊聊具体的线程和IO二 具体线程与作用1 master thread mysql的主要工作触发线程1 redo and binlog日志2 合并插入缓冲。3 脏页的刷新4 undo页回收5 产生一个ckp点2 IO THREAD 处理AIO模式的回调部分具体说明 AIO模式, 就是后台处理逻辑,然后先返回状态给前台,等后台处理完成,会调用回调函数进行二次操作,也就...
MySQL 5.7 在线更改gtid_mode
灯火觅阑珊
09-12 4401
在MySQL 5.7.6以前，gtid_mode是只读参数，修改值只能通过重启实例生效。 在MySQL 5.7.6开始，gtid_mode支持在线动态修改。 在MySQL里事务分为两种，一种是匿名事务（anonymous），一种是GTID事务。GTID事务即该事务带有GTID信息，而匿名事务即使没有GTID信息的事务，在主从复制中只能指定binlog文件和位点的方式来搭建。 从MySQL 5.7....
技术分享丨 关于MySQL binlog解析那些事
最新发布
GreatDB的博客
02-10 548
高效解析 binlog
mysql binlog 日志详解，恢复测试
cdrcsy的专栏
09-18 630
二进制日志常用参数： max_binlog_size ：单个二进制日志文件的最大值，超过该值，则产生新的二进制日志文件，并记录到.index文件，默认1G。 binlog_cache_size:  使用InnoDB时，所有未提交的事务会记录到一个缓存中，等待事务提交时，直接将缓冲中的二进制日志写入二进制日志文件， 而该缓冲的大小由binlog_cache_size决定，binlog_cache_...
十七：主库的DUMP线程（笔记）
cri5768的博客
07-09 1129
本文是我《深入理解MySQL主从原理》 系列的笔记部分，具体可以点击：ttps://j.youzan.com/yEY_Xi ...
mysql多线程回放_技术分享 | 从库 MTS 多线程并行回放（一）
weixin_34534456的博客
01-30 623
作者：高鹏(八怪)一、综述与单 SQL 线程的回放不同，MTS 包含多个工作线程，原有的 SQL 线程蜕变为协调线程。SQL 协调线程同时还承担了检查点的工作。我们知道并行回放的方式有两种，包含 LOGICAL_CLOCK 和 DATABASE，体现在判定哪些事物能够并行回放的规则不同。实际上源码对应两个不同的类：Mts_submode_logical_clockMts_submode_datab...
mysql5.7 system lock_MySQL：从库出现system lock的原因分析与解决方法
weixin_35216188的博客
01-21 1276
本文为笔者之前写一篇说明性文章，发现很多同学都在问这个问题，因此做一次分享。本文基于5.7.17源码本文只考虑row格式binlog主要考虑DML语句，DDL语句比较简单不做考虑以单sql线程为例(非MTS)一、延迟的计算方式其实每次show slave status命令的时候后台会调用函数show_slave_status_send_data进行及时计算，这个延迟并不是保存在哪里的。栈帧如下：#...
linux运维学习笔记：MySQL主从复制原理和实战.pdf
08-18
IO线程运行在从服务器上，负责接收二进制日志并将其写入中继日志。SQL线程也运行在从服务器上，负责读取并执行中继日志中的事件。 在开始配置复制之前，需要确保满足以下前提条件： 1. 主服务器必须打开二进制日志...
corejava_mysql:corejava_mysql笔记预习资料。需要源码的加扣扣849962874
03-23
此外，深入理解Java集合框架如ArrayList、LinkedList、HashMap等，以及IO流、网络编程、多线程等高级特性也是必不可少的。 接下来，转向MySQL。MySQL的核心优势在于其高效的查询性能、简单易用的SQL语法以及良好的...
书生笔记-mysql主库dump线程
魏书生的博客
12-15 947
每一个mysql的从库slave都会对于一个 dump线程，如上图的 Binlog Dump GTID .
mysql主从切换gtid不一致_【MySQL】Mysql5.7.21 传统复制切换到gtid复制遇到的一个现象...
weixin_39586353的博客
02-02 361
说明：系统：centos7主库 M：192.168.16.12：3306从库 S：192.168.16.15：3306主从复制：传统复制一、场景M、S目前基于log、pos点的复制，想要将其在线切换为基于GTID的复制，操作步骤(M、S都需执行，哪个先不影响)：1、M、S：mysql> set @@global.enforce_gtid_consistency=warn;2、M、S：mysq...
mysql差异备份
weixin_44435237的博客
02-22 1855
mysql差异备份 开启mysql服务器的二进制日志功能 [root@jun ~]# vim /etc/my.cnf [root@jun ~]# service mysqld restart Shutting down MySQL.. SUCCESS! Starting MySQL. SUCCESS! [root@jun ~]# tail -15 /etc/my.cnf [mysqld] ...
mysql数据库逻辑备份与恢复_[数据库]mysql 开发进阶篇系列 43 逻辑备份与恢复(基于时间和位置的不完全恢复)...
weixin_39726873的博客
02-02 141
[数据库]mysql 开发进阶篇系列 43 逻辑备份与恢复(基于时间和位置的不完全恢复)0 2018-09-27 03:00:54一. 概述在上篇讲到了逻辑备份，使用mysqldump工具来备份一个库,并使用完全恢复还原了数据库。在结尾也讲到了误操作是不能用完全恢复的。解决办法是:我们需要恢复到误操作之前的状态，然后跳过误操作语句。再恢复后面执行的语句，完成我们的恢复，这种恢复叫“不...
二十二：从库的IO线程（笔记）
cri5768的博客
07-09 649
本文是我《深入理解MySQL主从原理》 系列的笔记部分，具体可以点击：ttps://j.youzan.com/yEY_Xi ...
mysql 数据库主从复制、双主复制集群产生的问题以及mysql常见的错误代码
Shallow的博客
01-04 3257
mysql 数据库主从复制、双主复制集群产生的问题以及mysql常见的错误代码
mysql匿名事务gtid_MySQL Replication--开启GTID模式下匿名事务异常
weixin_28785657的博客
02-03 451
错误环境：OS:CentOS release 6.5 (Final)MySQL: MySQL 5.7.19主从参数配置：master_info_repository = TABLErelay_log_info_repository = TABLEgtid_mode = onenforce-gtid-consistency = truelog_slave_updates ...
binlog——逻辑复制的基础
weixin_30673715的博客
05-04 729
Ⅰ、binlog定义和作用 1.1 定义 记录每次数据库的逻辑操作(包括表结构变更和表数据修改) 包含：binlog文件和index文件 1.2 作用 复制：从库读取主库binlog,本地回放实现复制 备份恢复：最近逻辑备份数据+binlog实现最大可能恢复 innodb恢复：开启binlog的情况下,innodb事务提交是二阶段提交,发生crash的时候,innodb中事务有两种状态,一种是c...
MySQL学习笔记：InnoDB后台进程与高可用实践
"MySQL学习笔记包含了关于MySQL内存结构、后台进程、InnoDB特性和高可用实践的详细内容，适合提升至中级MySQL水平的学习者参考。" MySQL数据库中的InnoDB存储引擎有着复杂的后台工作流程，这些流程确保了数据的一致...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值