MySQL的并行复制多线程复制MTS【永利皇宫登录网址】,MySQL并行复制的一个坑

中午巡检数据库,开采叁个延缓从库的sql_thread中断了。

MySQL的并行复制四线程复制MTS(Multi-Threaded Slaves)

Last_SQL_Errno: 1755
Last_SQL_Error: Cannot execute the current event group in the parallel
mode. Encountered event Gtid, relay-log name ./oracle-relay-bin.000093,
position 152912092 which prevents execution of this event group in
parallel mode. Reason: The master event is logically timestamped
incorrectly..

检查performance_schema下的replication_applier_status_by_worker表,除了GTID之外也并未有更切实的信息:

 

"root@localhost:mysql3308.sock  [(none)]>select * from performance_schema.replication_applier_status_by_worker;
+--------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME | WORKER_ID | THREAD_ID | SERVICE_STATE | LAST_SEEN_TRANSACTION                          | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
+--------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+
|              |         1 |      NULL | OFF           | 0b961fcc-41c2-11e7-84fd-286ed488c7da:156369774 |                 0 |                    | 0000-00-00 00:00:00  |
|              |         2 |      NULL | OFF           |                                                |                 0 |                    | 0000-00-00 00:00:00  |
|              |         3 |      NULL | OFF           |                                                |                 0 |                    | 0000-00-00 00:00:00  |
|              |         4 |      NULL | OFF           |                                                |                 0 |                    | 0000-00-00 00:00:00  |
|              |         5 |      NULL | OFF           |                                                |                 0 |                    | 0000-00-00 00:00:00  |
|              |         6 |      NULL | OFF           |                                                |                 0 |                    | 0000-00-00 00:00:00  |
|              |         7 |      NULL | OFF           |                                                |                 0 |                    | 0000-00-00 00:00:00  |
|              |         8 |      NULL | OFF           |                                                |                 0 |                    | 0000-00-00 00:00:00  |
+--------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+

姜承饶

既然relay_log的地点新闻皆有了,那就去日志里会见啊:

 

解析Binlog文件:

简单称谓MTS:基于binlog组提交,mysql5.7暗许开启binlog组提交

mysqlbinlog -v --base64-output=decode-rows oracle-relay-bin.000093 >1.sql

找到152912092地方点相近的日志:

 组提交(group
commit)是MYSQL管理日志的豆蔻梢头种优化措施,主要为了解决写日记时频繁刷磁盘的标题。组提交伴随着MYSQL的开发进取不断优化,从前期只扶植redo
log 组提交,到眼下5.6合法版本同不时间辅助redo log
和binlog组提交。组提交的落实大大升高了mysql的事务管理品质

永利皇宫登录网址 1

 

检查了一下数据库中这几个表ID为14816035的数码确实是不真实的。

支撑四线程复制(Multi-Threaded Slaves, 简单的称呼MTS:基于binlog组提交
不是redolog组提交,叁个组提交的业务都以足以并行重放,因为这一个专门的职业都已经步入到专业的prepare阶段,则证实事情之间从未别的冲突(不然就不容许付出卡塔 尔(阿拉伯语:قطر‎。
SQL线程就解体为coordinator线程和worker线程,worker线程对组提交的事务实行人机联作重放

别的除了那条日志,其余日志的last_committed和sequence_number都为0,last_committed表示事情提交的时候,上次事务提交的数码。last_committed和sequence_number代表的正是所谓的LOGICAL_CLOCK。

为了包容MySQL
5.6基于库的并行复制,5.7引进了新的变量slave-parallel-type,其能够配备的值有:

测度借使手动把那条数据插入延迟从库,何况使用流入一个空事务跳过那些GTID的秘籍重启sql_thread,相信那一个乖谬也能被解决。

DATABASE:默许值,基于库的并行复制方式
LOGICAL_CLOCK:基于组提交的并行复制情势

但既然带了LOGICAL_CLOCK的事务就能出错,跳过工作的艺术很难保险今后不会出错。

支撑并行复制的GTID
哪些知道事情是或不是在意气风发组中,又是二个主题素材,因为原版的MySQL并不曾提供那样的新闻。在MySQL
5.7本子中,其设计形式是将组提交的讯息存放在GTID中。那么生机勃勃旦客商并未有拉开GTID功效,就要参数gtid_mode设置为OFF呢?故MySQL
5.7又引进了称之为Anonymous_Gtid的二进制日志event类型,如:

留心到那条日志的last_committed是一个非常的大的值,且错误信息中有涉及The
master event is logically timestamped
incorrectly。小编猜忌是否相互配置的主题材料。

mysql> SHOW BINLOG EVENTS in ‘mysql-bin.000006’;
+——————+—–+—————-+———–+————-+———————————————–+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+——————+—–+—————-+———–+————-+———————————————–+
| mysql-bin.000006 | 4 | Format_desc | 88 | 123 | Server ver:
5.7.7-rc-debug-log, Binlog ver: 4 |
| mysql-bin.000006 | 123 | Previous_gtids | 88 | 194 |
f11232f7-ff07-11e4-8fbb-00ff55e152c6:1-2 |
| mysql-bin.000006 | 194 | Anonymous_Gtid | 88 | 259 | SET
@@SESSION.GTID_NEXT= ‘ANONYMOUS’ |
| mysql-bin.000006 | 259 | Query | 88 | 330 | BEGIN |
| mysql-bin.000006 | 330 | Table_map | 88 | 373 | table_id: 108
(aaa.t) |
| mysql-bin.000006 | 373 | Write_rows | 88 | 413 | table_id: 108
flags: STMT_END_F

从库配置:

那表示在 MySQL
5.7本子中不怕不开启GTID,每一个职业开头前也是会存在多少个Anonymous_Gtid
,而那GTID中就存在着组提交的音讯。

"root@localhost:mysql3308.sock  [(none)]>show variables like '%para%';
+------------------------+---------------+
| Variable_name          | Value         |
+------------------------+---------------+
| slave_parallel_type    | LOGICAL_CLOCK |
| slave_parallel_workers | 8             |
+------------------------+---------------+

LOGICAL_CLOCK

 再检查主库配置:

可是,通过上述的SHOW BINLOG
EVENTS,大家并从未开掘成关组提交的别样新闻。不过通过mysqlbinlog工具,客商就能够发掘组提交的中间新闻:

(root@localhost:mysql.sock) [(none)]>show variables like '%para%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| slave_parallel_workers | 0     |
+------------------------+-------+

root@localhost:~# mysqlbinlog mysql-bin.0000006 | grep
last_committed
#150520 14:23:11 server id 88 end_log_pos 259 CRC32 0x4ead9ad6 GTID
last_committed=0 sequence_number=1
#150520 14:23:11 server id 88 end_log_pos 1483 CRC32 0xdf94bc85 GTID
last_committed=0 sequence_number=2
#150520 14:23:11 server id 88 end_log_pos 2708 CRC32 0x0914697b GTID
last_committed=0 sequence_number=3
#150520 14:23:11 server id 88 end_log_pos 3934 CRC32 0xd9cb4a43 GTID
last_committed=0 sequence_number=4
#150520 14:23:11 server id 88 end_log_pos 5159 CRC32 0x06a6f531 GTID
last_committed=0 sequence_number=5
#150520 14:23:11 server id 88 end_log_pos 6386 CRC32 0xd6cae930 GTID
last_committed=0 sequence_number=6
#150520 14:23:11 server id 88 end_log_pos 7610 CRC32 0xa1ea531c GTID
last_committed=6 sequence_number=7
#150520 14:23:11 server id 88 end_log_pos 8834 CRC32 0x96864e6b GTID
last_committed=6 sequence_number=8
#150520 14:23:11 server id 88 end_log_pos 10057 CRC32 0x2de1ae55 GTID
last_committed=6 sequence_number=9
#150520 14:23:11 server id 88 end_log_pos 11280 CRC32 0x5eb13091 GTID
last_committed=6 sequence_number=10
#150520 14:23:11 server id 88 end_log_pos 12504 CRC32 0x16721011 GTID
last_committed=6 sequence_number=11
#150520 14:23:11 server id 88 end_log_pos 13727 CRC32 0xe2210ab6 GTID
last_committed=6 sequence_number=12
#150520 14:23:11 server id 88 end_log_pos 14952 CRC32 0xf41181d3 GTID
last_committed=12 sequence_number=13

能够发现相比较原本的二进制日志内容多了last_committed和sequence_number,last_committed表示事情提交的时候,上次事务提交的号码,若是事情有着同样的last_committed,表示这一个业务都在后生可畏组内,能够开展相互影响的重播。

 发掘主库根本就从不slave_parallel_type那项安排。想起来主库是mysql5.6了。

比方上述last_committed为0的事务有6个,表示组提交时交由了6个事情,而这6个职业在从机是能够张开互相重播的。

(root@localhost:mysql.sock) [(none)]>select version();
+------------+
| version()  |
+------------+
| 5.6.35-log |
+------------+

上述的last_committed和sequence_number代表的正是所谓的LOGICAL_CLOCK。先来看源码中对于LOGICAL_CLOCK的定义:

网站地图xml地图