>

MySQL的并行复制拾2线程复制MTS,并行复制从库更

- 编辑:www.bifa688.com -

MySQL的并行复制拾2线程复制MTS,并行复制从库更

目录

目录

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

  • 背景
  • 版本
  • 分析
  • 测试
  • 背景
  • 版本
  • 分析
  • 测试
  • 结论



 



姜承饶


背景

半联手复制从库在夜幕黎明(英文名:lí míng)二点半发出自动重启,另三个异步复制从库在其次天凌晨三点也时有发生了机关心保养启。

 

背景

开了并行复制的半共同从库SQL 线程报十3贰破绽百出,异步复制从库没有报错,偶尔会出现那种

版本

mysql 5.7.16
redhat 6.8
mysql> show variables like '%slave_para%';
------------------------ ---------------
| Variable_name | Value |
------------------------ ---------------
| slave_parallel_type | LOGICAL_CLOCK |
| slave_parallel_workers | 16 |
------------------------ ---------------

简称MTS:基于binlog组提交,mysql伍.7私下认可开启binlog组提交

版本

mysql 5.7.16
redhat 6.8
mysql> show variables like '%slave_para%';
------------------------ ---------------
| Variable_name | Value |
------------------------ ---------------
| slave_parallel_type | LOGICAL_CLOCK |
| slave_parallel_workers | 16 |
------------------------ ---------------

分析

  1. mysqld服务在以mysqld_safe守护过程运营的情景下,在产生mysqld分外情况(比方OOM)会自动拉起mysqld服务,但已认可七个从库实例messages中无与OOM相关的日记。
  2. 从监察和控制中发掘,七个从库与Seconds_Behind_Master未有很高的特别上涨。
  3. 参数slave_pending_jobs_size_max 在十二线程复制时,在队列中Pending的轩然大波所据有的最大内存,默以为1六M,若是内部存款和储蓄器富余,大概延缓十分大时,可以恰到好处调大;注意那一个值要比主库的max_allowed_packet大。
    参照官方文书档案:slave_pending_jobs_size_max

  4. 多个爆发自动重启的从库日志中都辈出了ibuf record inserted to page x:x ,通过翻看space_id发掘都以呼应的平等张表(a_xxx.join_acct_flow),疑是早上的按时职责对那张表做了大事务的操作。从库的并行复制只有对出现提交的业务才会开始展览互动应用,对1个大事务,惟有2个线程举办利用。
    图片 1
    图片 2

  5. 浅析在从库爆发自动重启的时光段里发掘,爆发了大事务

 mysqlbinlog -v -v --base64-output=decode-rows
--start-datetime='2018-04-03 02:47:22' --stop-datetime='2018-04-03 02:48:26' /data/mysql/mysql-bin.003446 | awk
'/###/{if($0~/UPDATE|INSERT|DELETE/)count[$2""$NF]  }END{for(i in
 count)print i,"t",count[i]}' | column -t | sort -k3nr | more
DELETE`a_xxx`.`xxx_acct_flow`        565330
DELETE`a_xxx`.`xxx_bfj_flow`         23595
DELETE`a_xxx`.`xxx_loan_detail`      24156
DELETE`a_xxx`.`xxx_pay_log`          18475
INSERT`a_xxx`.`xxx_acct_flow_his`    576265
INSERT`a_xxx`.`xxx_bfj_flow_his`     23829
INSERT`a_xxx`.`xxx_loan_detail_his`  24539
INSERT`a_xxx`.`xxx_pay_log_his`      18709
  1. 向看源码的仇人请教了下,获得了MySQL自动重启的Stack Trace
 获取内存地址放入/tmp/err.log 中
[0xf1dff5]
[0x79d3b4]
[0x358c00f7e0]
[0x358bc325e5]
[0x358bc33dc5]
[0x1159d65]
[0x115e8b3]
[0x102b4d1]
[0x102f531]
[0x1033b29]
[0x11a59a1]
[0x1200afb]
[0x110db48]
[0x358c007aa1]
[0x358bce8aad]

nm -D -n /usr/local/mysql/bin/mysqld>/tmp/mysqld.sym
resolve_stack_dump -s /tmp/mysqld.sym -n /tmp/err.log |c  filt | less
0xf1dff5 my_print_stacktrace   53
0x79d3b4 handle_fatal_signal   1188
0x358c00f7e0 _end   -1978652160
0x358bc325e5 _end   -1982703611
0x358bc33dc5 _end   -1982697499
0x1159d65 ut_dbg_assertion_failed(char const*, char const*, unsigned long)   170
0x115e8b3 ib::fatal::~fatal()   179
0x102b4d1 ibuf_print(_IO_FILE*)   881
0x102f531 ibuf_update_free_bits_low(buf_block_t const*, unsigned long, mtr_t*)   3905
0x1033b29 ibuf_merge_or_delete_for_page(buf_block_t*, page_id_t const&, page_size_t const*, unsigned long)   2825
0x11a59a1 buf_page_io_complete(buf_page_t*, bool)   1249
0x1200afb fil_aio_wait(unsigned long)   347
0x110db48 io_handler_thread   200
0x358c007aa1 _end   -1978684223
0x358bce8aad _end   -1981956915

分析

一、疑是对从库实践了立异操作,导致立异的记录不设有
2、查看error log发现

2018-04-03T10:11:47.720156 08:00 16 [ERROR] Slave SQL for channel '': **Worker 13** failed executing transaction **'a272bbcf-874f-11e7-a288-00505695b721:687871861**' at master log mysql-bin.004119, end_log_pos 376471678; **Could not execute Update_rows event** on table anytxn.seq_xxxx; Can't find record in 'seq_xxxx', Error_code: 1032; handler error HA_ERR_END_OF_FILE; the event's master log mysql-bin.004119, end_log_pos 376471678, Error_code: 1032

2018-04-03T10:11:47.720230 08:00 2 [Warning] Slave SQL for channel '': ... The slave coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details). Error_code: 1756
2018-04-03T10:11:47.720959 08:00 2 [Note] Error reading relay log event for channel '': slave **SQL thread was killed**

三、从 SQL线程停止的position分析binlog开采

SET @@SESSION.GTID_NEXT= 'a272bbcf-874f-11e7-a288-00505695b721:687871861'/*!*/;
# at 376471694
#180403 10:11:47 server id 104073  end_log_pos 376471555 CRC32 0x1be91176   Query   thread_id=2086049   exec_time=0 error_code=0
SET TIMESTAMP=1522721507/*!*/;
BEGIN
/*!*/;
# at 376471768
#180403 10:11:47 server id 104073  end_log_pos 376471616 CRC32 0x10644d77   Table_map: `anytxn`.`seq_xxxx` mapped to number 301
# at 376471829
#180403 10:11:47 server id 104073  end_log_pos 376471678 CRC32 0x871a9787   Update_rows: table id 301 flags: STMT_END_F

### UPDATE `anytxn`.`seq_xxxx`
### WHERE
###   @1=7116088 /* LONGINT meta=0 nullable=0 is_null=0 */
###   @2=1 /* INT meta=0 nullable=0 is_null=0 */
### SET
###   @1=7116089 /* LONGINT meta=0 nullable=0 is_null=0 */
###   @2=1 /* INT meta=0 nullable=0 is_null=0 */
# at 376471891
#180403 10:11:47 server id 104073  end_log_pos 376471709 CRC32 0x9eb59238   Xid = 22247621418
COMMIT/*!*/;
# at 376471922
#180403 10:11:47 server id 104073  end_log_pos 376471774 CRC32 0xf7b6ad5d   GTID    last_committed=641254   sequence_number=641259
SET @@SESSION.GTID_NEXT= 'a272bbcf-874f-11e7-a288-00505695b721:687871862'/*!*/;
# at 376471987
#180403 10:11:47 server id 104073  end_log_pos 376471856 CRC32 0x6256de00   Query   thread_id=2085350   exec_time=0 error_code=0
SET TIMESTAMP=1522721507/*!*/;
BEGIN
/*!*/;
# at 376472069
#180403 10:11:47 server id 104073  end_log_pos 376471979 CRC32 0x6c329578   Table_map: `anytxn`.`bm_cc_customer_address_info` mapped to number 1569
# at 376472192
#180403 10:11:47 server id 104073  end_log_pos 376472162 CRC32 0x834cc8b9   Write_rows: table id 1569 flags: STMT_END_F


### INSERT INTO `anytxn`.`bm_xxxxxxxxxxxxxx`
### SET
###   @1=14480779 /* LONGINT meta=0 nullable=0 is_null=0 */
###   @2='0000001002380654' /* STRING(96) meta=65120 nullable=0 is_null=0 */
###   @3='B001' /* VARSTRING(30) meta=30 nullable=1 is_null=0 */
###   @4=NULL /* STRING(12) meta=65036 nullable=1 is_null=1 */
###   @5='10000010001202000000001' /* VARSTRING(96) meta=96 nullable=1 is_null=0 */
###   @6='B00' /* STRING(9) meta=65033 nullable=1 is_null=0 */
###   @7='xxxxxxxxxxx' /* VARSTRING(765) meta=765 nullable=1 is_null=0 */
###   @8=NULL /* STRING(18) meta=65042 nullable=1 is_null=1 */
###   @9=NULL /* STRING(18) meta=65042 nullable=1 is_null=1 */
###   @10=NULL /* STRING(18) meta=65042 nullable=1 is_null=1 */

 mysql@ACSXFDB6.xwbank.com:/home/mysql>  mysqlbinlog -v -v --start-datetime='2018-04-03 10:11:45' --stop-datetime='2018-04-03 10:11:48'  /data/mysql/ACSXFDB6-relay-bin.005477 | grep last_comm | grep 10:11:47 | grep 641254
#180403 10:11:47 server id 104073  end_log_pos 376469618 CRC32 0xb6dc6cef   GTID    last_committed=641227   sequence_number=641254
#180403 10:11:47 server id 104073  end_log_pos 376471774 CRC32 0xf7b6ad5d   GTID    last_committed=641254   sequence_number=641259
#180403 10:11:47 server id 104073  end_log_pos 376472258 CRC32 0x27cf3013   GTID    last_committed=641254   sequence_number=641260

从地方音讯方可观望,发生更新记录不存在是在创新anytxn.seq_customer_id表的标志为711608八的记录
有四个冒出提交的事务last_committed=64125肆 ,与开掘更新的笔录不设有的 GTID *.68787186一 事务还有另三个面世提交的事体 sequence_number=641260(即insert另一张表的操作),难道是master有并发提交的业务,slave多少个work线程去apply的时候出现了难题?

四、查看更新的记录不存在的表和相关记录

show create table seq_xxxx;
| seq_xxxx | CREATE TABLE seq_xxxx (
currentValue bigint(20) NOT NULL,
increment int(11) NOT NULL DEFAULT '1'

mysql> select * from seq_xxxx;
-------------- -----------
| currentValue | increment |
-------------- -----------
| 7116088 | 1 |
-------------- -----------
能够窥见实际数据库中是存在该记录的

测试

主库模拟1个大事务,看从库是否有越发现身
环境
centos 7.4
mysql5.7.19
从库并行复制线程 8
从库slave_pending_jobs_size_max 设置比主库 max_allowed_packet大

主库

mysql> desc sbtest1;
 ----- ----------- ----- ----- ------ ---------------- 
|  id |   int(11) |  NO | PRI | NULL | auto_increment |
|   k |   int(11) |  NO | MUL |    0 |                |
|   c | char(120) |  NO |     |      |                |
| pad |  char(60) |  NO |     |      |                |
| id3 |   int(11) | YES |     | NULL |                |
| id5 |   int(11) | YES |     | NULL |                |
 ----- ----------- ----- ----- ------ ---------------- 

select count(*) from sbtest1;

mysql> show variables like 'max_allowed_packet%';
 -------------------- ---------- 
| max_allowed_packet | 16777216 | 16M
 -------------------- ---------- 

从库

mysql> show variables like '%slave_para%';
 ------------------------ --------------- 
| Variable_name          | Value         |
 ------------------------ --------------- 
| slave_parallel_type    | LOGICAL_CLOCK |
| slave_parallel_workers | 8             |
 ------------------------ --------------- 
mysql> show variables like '%slave_pending_jobs%';
 ----------------------------- ---------- 
| Variable_name               | Value    |
 ----------------------------- ---------- 
| slave_pending_jobs_size_max | 67108864 | 64M
 ----------------------------- ---------- 

主库试行

UPDATE sbtest1 SET c=REPEAT(UUID(),2) where id<100000;

从库出现大量像样生产蒙受中的日志,但绝非模拟出从库自动重启的意况

Note] Multi-threaded slave: Coordinator has waited 208341 times hitting slave_pending_jobs_size_max; current event size = 8044
Note] Multi-threaded slave: Coordinator has waited 208351 times hitting slave_pending_jobs_size_max; current event size = 8044
Note] Multi-threaded slave: Coordinator has waited 208361 times hitting slave_pending_jobs_size_max; current event size = 8044
Note] Multi-threaded slave: Coordinator has waited 208371 times hitting slave_pending_jobs_size_max; current event size = 8044
Note] Multi-threaded slave: Coordinator has waited 208381 times hitting slave_pending_jobs_size_max; current event

 组提交(group commit)是MYSQL管理日志的一种优化措施,重要为了消除写日记时频仍刷磁盘的难题。组提交伴随着MYSQL的上进持续优化,从最初只辅助redo log 组提交,到近期5.陆法定版本同时扶助redo log 和binlog组提交。组提交的贯彻大大升高了mysql的事务处理质量

测试

mysql> select @@version;
------------
| @@version |
------------
| 5.7.19-log |
------------
1 row in set (0.00 sec)
mysql> show variables like '%para%';
------------------------ ---------------
| Variable_name | Value |
------------------------ ---------------
| slave_parallel_type | LOGICAL_CLOCK |
| slave_parallel_workers | 4 |
------------------------ ---------------

sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua --mysql-host=10.186.30.73 --mysql-socket=/opt/mysql/data/3307/mysqld.sock --mysql-port=3307  --db-driver=mysql  --mysql-db=test --mysql-user=admin --mysql-password=admin --table_size=100000 --tables=5 --threads=100 --time=120 --report-interval=5  run

有出现提交的作业,但从未模拟重现出革新的笔录不设有,但在库中却存在的动静
图片 3

相关bug链接
Repeated multi-threaded slave replication failures

结论

从库开启并行复制,主库实践大事务,从库日志会出现多量中 Coordinator has waited。但绝非复现出从库发生自动重启的情状。
建议:

  1. 尽量收缩大事务的实行,拆分为小事情
  2. 从库slave_pending_jobs_size_max 变量设置比主库max_allowed_packet大些
  3. 可设置binlog_rows_query_log_events = 壹(能够动态开启),DDL,DML会以语句情势在binlog中记录,方便分析binlog
  4. crash难点持续可以多保留部分日志,再度复现时好分析些
  5. 已给合法提了bug了,链接地址为

参考:

 

支撑八线程复制(Multi-Threaded Slaves, 简称MTS:基于binlog组提交 不是redolog组提交,1个组提交的作业都以足以并行重放,因为这么些职业都已进入到业务的prepare阶段,则申明事情之间一向不其余争论(不然就不容许付出)。
SQL线程就崩溃为coordinator线程和worker线程,worker线程对组提交的业务进行交互重播

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

DATABASE:暗中同意值,基于库的并行复制模式
LOGICAL_CLOCK:基于组提交的并行复制格局

支撑并行复制的GTID
何以晓得事情是不是在1组中,又是1个难点,因为原版的MySQL并从未提供这么的音信。在MySQL 5.7本子中,其安排艺术是将组提交的新闻寄存在GTID中。那么只要用户并未有开启GTID作用,将要参数gtid_mode设置为OFF呢?故MySQL 伍.7又引进了称之为Anonymous_Gtid的2进制日志event类型,如:

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 五.七本子中不怕不开启GTID,各类工作起头前也是会存在多个Anonymous_Gtid ,而那GTID中就存在着组提交的新闻。

LOGICAL_CLOCK

但是,通过上述的SHOW BINLOG EVENTS,我们并从未察觉有关组提交的别的音信。可是经过mysqlbinlog工具,用户就能够发掘组提交的里边音信:

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
...
能够窥见相比较原来的2进制日志内容多了last_committed和sequence_number,last_committed表示事情提交的时候,上次事务提交的号子,假若事情有着一样的last_committed,表示这一个工作都在一组内,能够开始展览交互的重放。

诸如上述last_committed为0的业务有陆个,表示组提交时交由了八个业务,而那多个业务在从机是可以进行互动重播的。

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

class Logical_clock
{
  private:
  int64 state;
  /*
  Offset is subtracted from the actual "absolute time" value at
  logging a replication event. That is the event holds logical
  timestamps in the "relative" format. They are meaningful only in
  the context of the current binlog.
  The member is updated (incremented) per binary log rotation.
  */
  int64 offset;
  ......
state是3个自增的值,offset在历次二进制日志产生rotate时更新,记录发生rotate时的state值。其实state和offset记录的是大局的计数值,而存在2进制日志中的仅是当前文件的相对值。使用LOGICAL_CLOCK的场景如下:

class MYSQL_BIN_LOG: public TC_LOG
{
  ...
  public:
  /* Committed transactions timestamp */
  Logical_clock max_committed_transaction;
  /* "Prepared" transactions timestamp */
  Logical_clock transaction_counter;
  ...
可以观看在类MYSQL_BIN_LOG中定义了三个Logical_clock的变量:

max_committed_transaction:记录上次组提交时的logical_clock,代表上述mysqlbinlog中的last_committed
transaction_counter:记录当前组提交中各专门的职业的logcial_clock,代表上述mysqlbinlog中的sequence_number

并行复制测试

下图展现了张开MTS后,slave服务器的QPS。测试的工具是sysbench的单表全update测试,测试结果突显在14个线程下的脾气最佳,从机的QPS能够高达2四千以上,进一步增添并行推行的线程至3二并不曾带来更加高的进步。
而原单线程重放的QPS仅在伍仟左右,可见MySQL 五.七MTS带来的性质提高,而出于测试的是单表,所以MySQL 5.陆的MTS机制则完全不能了。

并行复制配置与调优

master_info_repository

敞开MTS功效后,务必将参数master_info_repostitory设置为TABLE,那样性能能够有5/十~八成的提高。那是因为并行复制开启后对于元master.info那个文件的翻新将会急剧晋级,财富的竞争也会变大。在前头 InnoSQL 的本子中,增多了参数来调控刷新master.info那几个文件的频率,以至能够不刷新那个文件。因为刷新这一个文件是不曾必要的,即依照master-info.log这一个文件苏醒自个儿就是不可信的。在MySQL 五.7中,Inside君推荐将master_info_repository设置为TABLE,来减小那部分的付出。

slave_parallel_workers

若将slave_parallel_workers设置为0,则MySQL 伍.7后退为原单线程复制,但将slave_parallel_workers设置为1,则SQL线程成效转化为coordinator线程,不过唯有叁个worker线程举行重放,也是单线程复制。
可是,那两种属性却又有点的区分,因为多了1次coordinator线程的转速,因而slave_parallel_workers=一的品质反而比0还要差,在Inside君的测试下还有伍分之一左右的性质降低,如下图所示:
这里其中引进了另多少个题目,假设主机上的负荷非常的小,那么组提交的频率就不高,很有极大希望爆发每组提交的事务数量仅有三个,那么在从机的回看时, 纵然开启了并行复制,但晤面世质量反而比原先的单线程还要差的意况,即延迟反而增大了 。聪明的伙伴们,有想过对那些举行优化吗?

Enhanced Multi-Threaded Slave配置

说了如此多,要开启enhanced multi-threaded slave其实很轻巧,只需依赖如下设置:

# slave
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON
并行复制监察和控制

复制的监察和控制仍旧能够因此SHOW SLAVE STATUSG,但是MySQL 5.7在performance_schema架构下多了那么些表,用户可以更加细力度的进展监督检查:

mysql> show tables like 'replication%';
---------------------------------------------
| Tables_in_performance_schema (replication%) |
---------------------------------------------
| replication_applier_configuration           |
| replication_applier_status                  |
| replication_applier_status_by_coordinator   |
| replication_applier_status_by_worker        |
| replication_connection_configuration        |
| replication_connection_status               |
| replication_group_member_stats              |
| replication_group_members                   |
---------------------------------------------
8 rows in set (0.00 sec)
总结

MySQL 伍.7推出的Enhanced Multi-Threaded Slave消除了麻烦MySQL长达数十年的复制延迟难题,再一次提示部分混沌的PostgreSQL用户,不要再停留在前头对于MySQL的纪念,物理复制也不必然确定比逻辑复制有优势,而MySQL 5.七的MTS已经完全可以消除延迟主题素材。anyway,和Inside君一齐见证划时期MySQL 伍.七 GA版本的亲临吧。

 

MySQL伍.7并行复制中并行的着实含义

大家精晓MySQL5.七并行复制引进了三个值last_committed和sequence_number。last_committed表示事情提交的时候,上次事务提交的号子,在主库上还要提交的业务设置成一样的last_committed。假若专门的学问有着同等的last_committed,表示那个业务都在一组内,能够实行互动的重播。那个机制也是Commit-Parent-Based SchemeWL#63第11四中学的完毕方式。可是以往,官方对那种格局做了改进,所以新型的相互重播机制和WL#631四有了差异,详细情形见Lock-Based SchemeWL#7165

本条参数设置为yes是为了保证,在slave上业务的交给顺序与relay log中千篇一律。
然则透过测试,这一个参数在MySQL五.7.1第88中学装置之后,也无能为力确认保证slave上作业提交的顺序与relay log一致。
在MySQL5.柒.1玖设置后,slave上业务的交给顺序与relay log中同样。
For multi-threaded slaves, enabling this variable ensures that transactions are externalized on the slave in the same order as they appear in the slave's relay log. Setting this variable has no effect on slaves for which multi-threading is not enabled. All replication threads (for all replication channels if you are using multiple replication channels) must be stopped before changing this variable. --log-bin and --log-slave-updates must be enabled on the slave. In addition --slave-parallel-type must be set to LOGICAL_CLOCK.

本文由88bifa必发唯一官网发布,转载请注明来源:MySQL的并行复制拾2线程复制MTS,并行复制从库更