将这个参数配置在my.必威:cnf配置文件中,半同

早上巡检数据库,发现一个延迟从库的sql_thread中断了。

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

传统复制线程

必威 1

复制线程图

  • master
    • Dump_thread
  • slave
    • IO_Thread
    • SQL_Thread
  • 纠结的问题
    • MySQL Replication是主库把日志推给Slave,还是Slave从主库把日志拉过来的?
    • 可以这么理解,延迟时间过长,比如用备份恢复时就是拉取,正常主从没有延迟或延迟比较低时是推
    • 主从结构的瓶颈是什么?
    • sql_thread是单线程重放,master是多线程写入,容易造成瓶颈

Contents [hide]

在搭建复制中,有些参数需要我们留意,在这里罗列出来,供大家参考一下,以GTID为基础

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..

GTID原理

  • GTID
    • 事务唯一编号,全剧唯一(一个复制Group里)
    • 同时和事物记录到binlog中,用来标识事务
    • binlog中多一个:Gtid_log_event
  • 构成
    • UUID:sequence_number
    • sequence_number是MySQL内部的一个事务编号,一个MySQL不会重复的顺序号(保证服务器内唯一)
    • 每个MySQL有一个全局唯一的UUID:$datadir/auto.cnf中存储
    • GTID复制中出现断点,估计是使用:master_auto_position=0
  • master_auto_position=1
    • MySQL可以记录执行过的事务ID,可以通过show master status -> gtid_executed查看
    • MySQL5.6依赖于binlog和gtid_purge;MySQL5.7依赖于mysql.gtid_executed表
    • slave上记录了接收和执行的gtid,可以通过show slave status:
      • Retrieve_gtid_set
      • Execute_gtid_set
    • slave连接Master时,会把gtid_executed中的gtid发给Master,Master会Skip过executed_gtid_set,把没有执行过的GTID事务发送给slave
    • BUG:slave_net_timeout 参数设置过小,造成MySQL Master Dump thread增多,主库会认为自己多了从库,其实是频繁的从库连接又断开造成的
  • MySQL5.6从非GTID到GTID切换,需要重启
  • MySQL5.7支持在线启用GTID
    • 不用重启mysqld
    • 在启用GTID过程,可以对外提供服务
    • 不需要改变复制结构
    • 如果需要GTID,又不想太多停机时间:升级到MySQL5.7在线启用就OK
  • MySQL5.7GTID启动过程
    • gtid_mode
gitd_mode 解释
OFF 不产生GTID,Slave只接收不带GTID的事务
OFF_PERMISSIVE 不产生GTID,Slave接收不带GTID的事务也接收带GTID的事务
ON_PERMISSIVE 产生GTID,Slave接收不带GTID的事务也接收带GTID的事务
ON 产生GTID,Slave只接收带GTID的事务
  • 5.7GTID的切换流程
gitd_mode 执行对象
set global gtid_mode='OFF_PERMISSIVE'; 在Group中每个MySQL上执行
set global gtid_mode='ON_PERMISSIVE'; 在Group中每个MySQL上执行,为了安全尽量现在从库上执行
确认每个Group中binlog非GTID的执行完毕
set global gtid_mode='ON'; 在Group中每个MySQL上执行
  • MySQL5.7GTID会存储到表里
    • 支持slave不用开启binlog(log_slave_status),建议还是开启
CREATE TABLE `gtid_executed` (
  `source_uuid` char(36) NOT NULL COMMENT 'uuid of the source where the transaction was originally executed.',
  `interval_start` bigint(20) NOT NULL COMMENT 'First number of interval.',
  `interval_end` bigint(20) NOT NULL COMMENT 'Last number of interval.',
  PRIMARY KEY (`source_uuid`,`interval_start`)
  • 如何记录gtid

    • 如果开启binlog,在binlog日志文件切换时,将当前的gtid插入到gtid_executed表中
      • insert into mysql.gtid_executed(UUID,1000,2000);
    • 如果没有开启binlog,每个事务提交前,会执行一个insert操作
      • Begin
      • 事务操作
      • insert into mysql.gtid_executed(UUID,1000,2000); #隐式MySQL内部添加
      • commit
  • gtid_executed表压缩

    • 控制压缩频率
      • mysql>set global gtid_executed_compression_period=N;(N事务个数,默认是1000)
        ![](https://upload-images.jianshu.io/upload_images/9520647-e8d8de8fe3db46c7.png)

        压缩前后对比
  • enforce-gtid-consistency

    • OFF 不检测是否有GTID不知的语句/事务
    • WARN 当发现不支持语句/事务,返回警告,并在日志中记录警告信息
    • ON 当发现语句/事务不支持GTID时,返回错误
  • TIPS

    • 在线上从非GTID到GTID切换过程中,可以先设置成:WARN
  • GTID Limit

    • 不能使用 create table ... select ...
    • 事务中更新非事务表
      • begin:update no_trx_tabe set col1=xxx where xxx;update trx_tb set col1=xxx where ....;commit;
    • 事务中创建/删除临时表
      • begin:update trx_tb set xxx;create temporary table ...;commit;
    • sql_slave_skip_counter 不支持
    • 如果在传统复制到GTID复制切换时,主从卡住了,可以用start slave sql_thread试一下看能不能过去,要是过不去只能使用enforce-gtid-consistency=off先让主从能跑通
  • GTID跳过错误

    • stop slave sql_thread;
    • set gtid_next='uuid:N';
    • begin;commit;
    • set gtid_next='automatic';
    • start slave sql_thread;
  • 1 MySQL 5.7并行复制时代
  • 2 MySQL 5.6并行复制架构
  • 3 MySQL 5.7并行复制原理
    • 3.1 MySQL 5.7基于组提交的并行复制
    • 3.2 支持并行复制的GTID
    • 3.3 LOGICAL_CLOCK
  • 4 并行复制测试
  • 5 并行复制配置与调优
    • 5.1 master_info_repository
    • 5.2 slave_parallel_workers
    • 5.3 Enhanced Multi-Threaded Slave配置
  • 6 并行复制监控
  • 7 总结
  • 8 参考文献:
  1. --server-id

检查performance_schema下的replication_applier_status_by_worker表,除了GTID之外也没有更具体的信息:

 

半同步复制

MySQL 5.7并行复制时代

众所周知,MySQL的复制延迟是一直被诟病的问题之一,然而在Inside君之前的两篇博客中(1,2)中都已经提到了MySQL 5.7版本已经支持“真正”的并行复制功能,官方称为为enhanced multi-threaded slave(简称MTS),因此复制延迟问题已经得到了极大的改进,甚至在Inside君所在的网易电商应用中已经完全消除了之前延迟长达几小时的问题。然而,Inside君发现还是有很多小伙伴不了解这个足以载入史册的“伟大”的特性,故作分享。总之,5.7版本后,复制延迟问题永不存在。

server-id:这是一个全局的可动态调整的变量,取值范围为0-4294967295,也就是2的32次方减1,这个选项必须在master和slave中都分别进行设置,如果不设置保持默认,则在连接过程中会产生错误。从而复制失败,将这个参数配置在my.cnf配置文件中,然后重启生效

"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  |
+--------------+-----------+-----------+---------------+------------------------------------------------+-------------------+--------------------+----------------------+

姜承饶

MySQL5.7无数据丢失的半同步复制

必威 2

半同步复制

  • 半同步复制里面主从会不会存在延迟?
    • 会存在延迟,半同步只能保证写入到relay log,也就是IO_thread同步的部分,sql_thread重放有可能会出现延迟
  • 在Master接收到slave的ACK应答后才Commit事务(5.6上是Master在Commit后,才等待Slave应答)
    • 因此在事务复制到slave之前,并发的事务看不到当前的事务的数据(5.6这有点问题)
    • 当Master故障时,所有已提交的事务都会复制到slave上
    • 缺省采用无数据丢失的应答等待机制,用户可以选择使用5.6的应答待机制
    • mysql>set rpl_semi_sync_master_wait_point={AFTER_SYNC|AFTER_COMMIT}

MySQL 5.6并行复制架构

诚然,MySQL 5.6版本也支持所谓的并行复制,但是其并行只是基于schema的,也就是基于库的。如果用户的MySQL数据库实例中存在多个schema,对于从机复制的速度的确可以有比较大的帮助。MySQL 5.6并行复制的架构如下所示:

必威 3

在上图的红色框框部分就是实现并行复制的关键所在。在MySQL 5.6版本之前,Slave服务器上有两个线程I/O线程和SQL线程。I/O线程负责接收二进制日志(更准确的说是二进制日志的event),SQL线程进行回放二进制日志。如果在MySQL 5.6版本开启并行复制功能,那么SQL线程就变为了coordinator线程,coordinator线程主要负责以前两部分的内容:

  • 若判断可以并行执行,那么选择worker线程执行事务的二进制日志
  • 若判断不可以并行执行,如该操作是DDL,亦或者是事务跨schema操作,则等待所有的worker线程执行完成之后,再执行当前的日志

这意味着coordinator线程并不是仅将日志发送给worker线程,自己也可以回放日志,但是所有可以并行的操作交付由worker线程完成。coordinator线程与worker是典型的生产者与消费者模型。

上述机制实现了基于schema的并行复制存在两个问题,首先是crash safe功能不好做,因为可能之后执行的事务由于并行复制的关系先完成执行,那么当发生crash的时候,这部分的处理逻辑是比较复杂的。从代码上看,5.6这里引入了Low-Water-Mark标记来解决该问题,从设计上看(WL#5569),其是希望借助于日志的幂等性来解决该问题,不过5.6的二进制日志回放还不能实现幂等性。另一个最为关键的问题是这样设计的并行复制效果并不高,如果用户实例仅有一个库,那么就无法实现并行回放,甚至性能会比原来的单线程更差。而单库多表是比多库多表更为常见的一种情形。

  2. --server_uuid

既然relay_log的位置信息都有了,那就去日志里看看吧:

 

增强半同步

  • mysql>set rpl_semi_sync_master_wait_point=AFTER_SYNC;
    [图片上传失败...(image-e3c6a6-1513426634210)]

MySQL 5.7并行复制原理

server_uuid:这是一个全局只读的变量,非动态变量,以一个字符串的形式存在

解析Binlog文件:

简称MTS:基于binlog组提交,mysql5.7默认开启binlog组提交

半同步

  • mysql>set rpl_semi_sync_master_wait_point=AFTER_COMMIT;
![](https://upload-images.jianshu.io/upload_images/9520647-d094f02d43c86bb7.jpg)

半同步

MySQL 5.7基于组提交的并行复制

MySQL 5.7才可称为真正的并行复制,这其中最为主要的原因就是slave服务器的回放与主机是一致的即master服务器上是怎么并行执行的slave上就怎样进行并行回放。不再有库的并行复制限制,对于二进制日志格式也无特殊的要求(基于库的并行复制也没有要求)。

从MySQL官方来看,其并行复制的原本计划是支持表级的并行复制和行级的并行复制,行级的并行复制通过解析ROW格式的二进制日志的方式来完成,WL#4648。但是最终出现给小伙伴的确是在开发计划中称为:MTS: Prepared transactions slave parallel applier,可见:WL#6314。该并行复制的思想最早是由MariaDB的Kristain提出,并已在MariaDB 10中出现,相信很多选择MariaDB的小伙伴最为看重的功能之一就是并行复制。

MySQL 5.7并行复制的思想简单易懂,一言以蔽之:一个组提交的事务都是可以并行回放,因为这些事务都已进入到事务的prepare阶段,则说明事务之间没有任何冲突(否则就不可能提交)。

为了兼容MySQL 5.6基于库的并行复制,5.7引入了新的变量slave-parallel-type,其可以配置的值有:

  • DATABASE:默认值,基于库的并行复制方式
  • LOGICAL_CLOCK:基于组提交的并行复制方式
+---------------+--------------------------------------+
| Variable_name | Value                                |
+---------------+--------------------------------------+
| server_uuid   | a0c06ec7-fef0-11e6-9f85-525400a7d662 |
+---------------+--------------------------------------+
1 row in set (0.00 sec)
mysqlbinlog -v --base64-output=decode-rows oracle-relay-bin.000093 >1.sql

更快的半同步复制

  • MySQL5.6
![](https://upload-images.jianshu.io/upload_images/9520647-3a3164607962b8c1.png)

mysql5.6半同步复制

-   mysql5.6半同步复制两个事务中间有三个流程要走,所以两个事务之间存在时间间隔
  • MySQL5.7
    • 创建单独的应答接收线程
    • 变成双工模式:发送和接收互不影响
    ![](https://upload-images.jianshu.io/upload_images/9520647-f1c47ffd00a38f79.png)

    mysql5.7半同步复制

支持并行复制的GTID

如何知道事务是否在一组中,又是一个问题,因为原版的MySQL并没有提供这样的信息。在MySQL 5.7版本中,其设计方式是将组提交的信息存放在GTID中。那么如果用户没有开启GTID功能,即将参数gtid_mode设置为OFF呢?故MySQL 5.7又引入了称之为Anonymous_Gtid的二进制日志event类型,如:

1
2
3
4
5
6
7
8
9
10
11
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中就存在着组提交的信息。

这个字符串,在服务器启动的时候,是直接去读数据目录中的auto.cnf文件,即

找到152912092位置点附近的日志:

 组提交(group commit)是MYSQL处理日志的一种优化方式,主要为了解决写日志时频繁刷磁盘的问题。组提交伴随着MYSQL的发展不断优化,从最初只支持redo log 组提交,到目前5.6官方版本同时支持redo log 和binlog组提交。组提交的实现大大提高了mysql的事务处理性能

5.7半同步

  • Master接收到N个Slave应答后,才Commit事务
  • 用户可以设置应答的Slave数量
mysql>set global rpl_semi_sync_master_wait_for_slave_count=2;
  • 特别提示:
    • 低于5.7版本,在从库关闭一段时间后,刚启动时,注意先用异步复制,复制追上后,在用半同步复制
    • master:
      • set global rpl_semi_sync_master_enabled=ON|OFF;
    • slave:
      • set global rpl_semi_sync_slave_enabled=ON|OFF;
  • 增强半同步mysqld creash recovery
    • 扫描最后一个binlog提取其中Xid
    • 扫描InnoDB维持状态在Prepare的事务链表,和Binlog中的Xid比较,如果Binlog中存在,则提交,否则回滚事务
    • 提交到InnoDB中处于Prepare,并且写入Binlog的,就可以从崩溃中恢复事务
    • 三种场景
      • redo中有Xid,filename,position 执行Commit
      • redo中有prepare_mutex_lock,Xid
        • 在last binlog中找到对应的事务 执行Commit
        • 反之rollback
      • redo只有事务本身,没有Xid,prepare_mutex_lock 执行rollback

LOGICAL_CLOCK

然而,通过上述的SHOW BINLOG EVENTS,我们并没有发现有关组提交的任何信息。但是通过mysqlbinlog工具,用户就能发现组提交的内部信息:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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,表示这些事务都在一组内,可以进行并行的回放。例如上述last_committed为0的事务有6个,表示组提交时提交了6个事务,而这6个事务在从机是可以进行并行回放的。

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

1
2
3
4
5
6
7
8
9
10
11
12
13
classLogical_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是一个自增的值,offset在每次二进制日志发生rotate时更新,记录发生rotate时的state值。其实state和offset记录的是全局的计数值,而存在二进制日志中的仅是当前文件的相对值。使用LOGICAL_CLOCK的场景如下:

1
2
3
4
5
6
7
8
9
classMYSQL_BIN_LOG: publicTC_LOG
{
  ...
  public:
  /* Committed transactions timestamp */
  Logical_clock max_committed_transaction;
  /* "Prepared" transactions timestamp */
  Logical_clock transaction_counter;
  ...

可以看到在类MYSQL_BIN_LOG中定义了两个Logical_clock的变量:

  • max_c ommitted_transaction:记录上次组提交时的logical_clock,代表上述mysqlbinlog中的last_committed
  • transaction_counter:记录当前组提交中各事务的logcial_clock,代表上述mysqlbinlog中的sequence_number
[root@gzx-db-01 ~]# cat /data/mysql/mysql3306/data/auto.cnf 
[auto]
server-uuid=a0c06ec7-fef0-11e6-9f85-525400a7d662

必威 4

 

并行复制

并行复制测试

下图显示了开启MTS后,slave服务器的QPS。测试的工具是sysbench的单表全update测试,测试结果显示在16个线程下的性能最好,从机的QPS可以达到25000以上,进一步增加并行执行的线程至32并没有带来更高的提升。而原单线程回放的QPS仅在4000左右,可见MySQL 5.7 MTS带来的性能提升,而由于测试的是单表,所以MySQL 5.6的MTS机制则完全无能为力了。

必威 5

可以看到,跟客户端查出来的是等值的。如果auto.cnf文件并不存在的时候,则会生成一个新的UUID,同时创建auto.cnf文件,这个文件属于自动生成,不要去写或者更改里面的内容,在SLAVE端开始start slave后,用SHOW SLAVE STATUS可查看到MASTER的UUID,而在MASTER中,使用SHOW SLAVE HOTS可查看SLAVE中的UUID

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

支持多线程复制(Multi-Threaded Slaves, 简称MTS:基于binlog组提交 不是redolog组提交,一个组提交的事务都是可以并行回放 ,因为这些事务都已进入到事务的prepare阶段,则说明事务之间没有任何冲突(否则就不可能提交)。
SQL线程就分裂为coordinator线程和worker线程,worker线程对组提交的事务进行并行回放

并发复制

  • 在MySQL5.6的并发复制是基于库级别
  • 实质上需要:
    • 让在Master上能并发执行的事务,在Slave上也并发执行
    • 在Binlog中记录事务并发执行的相关信息
    • Slave上根据以上这些信息,让这些事务在Slave上多个线程中并发执行
  • MySQL5.7的并发复制是基于事务级别(Logical Clock)
  • 在Master上并发COMMIT事务越多,slave上并发性能越好
  • 微调参数
    • binlog_group_commit_sync_delay #group_commit等待时间,建议20微妙
    • binlog_group_commit_sync_no_delay_count #group_commit等待时间内到达多少个事务,比如这个参数是50个,当等待时间内已经有50个事务在等待,就直接提交,不在等待了,建议设置20
    • slave_preserve_commit_order=ON|OFF
      • 开启binlog
      • Logical_clock有作用

并行复制配置与调优

 

另外除了这条日志,其它日志的last_committed和sequence_number都为0,last_committed表示事务提交的时候,上次事务提交的编号。last_committed和sequence_number代表的就是所谓的LOGICAL_CLOCK。

为了兼容MySQL 5.6基于库的并行复制,5.7引入了新的变量slave-parallel-type,其可以配置的值有:

基于锁的并行复制

  • 事务能不能并发是锁来决定的.如果有锁冲突,则一个事务要等待另一个事务执行完毕
  • 如何判断并行事务没有锁冲突
    • 如果两个事务(操作)可以并行执行,这两个事务没有锁的冲突
    • 当事务开始执行Commit语句时,它已经获取了所有的锁
    • 当事务进入到prepare阶段时,它已经获取了所有的锁
  • 并发信息以逻辑的时间方式写入gtid_log_event中,共记录两个逻辑时间
    • sequence_number
      • 当事务写入binlog时,事务自己的逻辑时间,按照事务记录binlog的顺序递增
    • commit_parent
      • 当事务进行prepare阶段时,已经提交的事务的最大逻辑时间
  • 事务在Slave上执行
动作 事务 依赖关系
insert commit T1 (1,0)
update commit T2 (2,0)
delete commit T3 (3,1)
  • commit_parent之前执行的事务全部提交以后,才开始执行
  • T1和T2同事开始执行,T1 Commit后,T3开始执行

master_info_repository

开启MTS功能后,务必将参数master_info_repostitory设置为TABLE,这样性能可以有50%~80%的提升。这是因为并行复制开启后对于元master.info这个文件的更新将会大幅提升,资源的竞争也会变大。在之前InnoSQL的版本中,添加了参数来控制刷新master.info这个文件的频率,甚至可以不刷新这个文件。因为刷新这个文件是没有必要的,即根据master-info.log这个文件恢复本身就是不可靠的。在MySQL 5.7中,Inside君推荐将master_info_repository设置为TABLE,来减小这部分的开销。

  3. 变量大杂烩---参数众多,直接从官网拷贝下来

猜测如果手动把这条数据插入延迟从库,并且使用注入一个空事务跳过这个GTID的方法重启sql_thread,相信这个错误也能被解决。

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

启用并行复制

  • 启用GTID!!!
mysql>stop slave sql_thread;
mysql>set global slave_parallel_workers=4|8|max_cpu_core/2;  #最多可以设成cpu核数,不过不建议,一般4个或8个就够了
mysql>set global slave_parallel_type='LOGICAL_CLOCK'; #OR DATABASE
mysql>start slave sql_thread;
  • MySQL 5.7并行复制的思想简单易懂,一言以蔽之: 一个组提交的事务都是可以并行回放 ,因为这些事务都已进入到事务的prepare阶段,则说明事务之间没有任何冲突(否则就不可能提交)。
  • DATABASE:默认值,基于库的并行复制方式
  • LOGICAL_CLOCK:基于组提交的并行复制方式
  • 最好配置binlog group commit
    • binlog_group_commit_sync_delay
    • binlog_group_commit_sync_no_delay_count

slave_parallel_workers

若将slave_parallel_workers设置为0,则MySQL 5.7退化为原单线程复制,但将slave_parallel_workers设置为1,则SQL线程功能转化为coordinator线程,但是只有1个worker线程进行回放,也是单线程复制。然而,这两种性能却又有一些的区别,因为多了一次coordinator线程的转发,因此slave_parallel_workers=1的性能反而比0还要差,在Inside君的测试下还有20%左右的性能下降,如下图所示:

必威 6

这里其中引入了另一个问题,如果主机上的负载不大,那么组提交的效率就不高,很有可能发生每组提交的事务数量仅有1个,那么在从机的回放时,虽然开启了并行复制,但会出现性能反而比原先的单线程还要差的现象,即延迟反而增大了。聪明的小伙伴们,有想过对这个进行优化吗?

Option or Variable Name

但既然带了LOGICAL_CLOCK的事务就会出错,跳过事务的方法很难保证以后不会出错。

支持并行复制的GTID
如何知道事务是否在一组中,又是一个问题,因为原版的MySQL并没有提供这样的信息。在MySQL 5.7版本中,其设计方式是将组提交的信息存放在GTID中。那么如果用户没有开启GTID功能,即将参数gtid_mode设置为OFF呢?故MySQL 5.7又引入了称之为Anonymous_Gtid的二进制日志event类型,如:

延迟复制

  • 让从库和主库保持固定时间的延迟
  • 使用场景
    • 利用延迟复制做误操作恢复
    • 利用延迟复制做统计分析环境处理
mysql>stop slave sql_thread;
mysql>change master to master_delay=N;  #N单位秒
mysql>start slave sql_thread;
  • 从库在某一个复制位置停住
    • start slave中有个参数为until可以实现这个功能
    • start slave sql_thread until master_log_file='xxx',master_log_pos=xxx;
    • 或者可以用GTID模式,{SQL_BEFORE_GTIDS|SQL_AFTER_GTIDS}=gtid_set

Enhanced Multi-Threaded Slave配置

说了这么多,要开启enhanced multi-threaded slave其实很简单,只需根据如下设置:

1
2
3
4
5
6
# slave
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON

Command Line

注意到这条日志的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

多源复制

  • Slave 可以同时从多个Master复制
  • 每个DB中的名字不能一样,否则有可能复制出错
    [图片上传失败...(image-6f90e6-1513426634210)]
  • 场景
    • 集中备份
    • 数据分析聚合
    • 分片数据聚合
    ![](https://upload-images.jianshu.io/upload_images/9520647-7b244ef4563f90fa.png)
  • 多个channels(channels包含:recevier thread ,relay logs ,applier threads)每个channel能独立的运行和停止
  • 通过P_S表进行状态监控:
  • 下列表中添加了channel_name字段,不同的Channel的信息在不同的行中显示
    • replication_applier_status_by_coordinator
    • replication_applier_status_by_worker
    • replication_connection_status

并行复制监控

复制的监控依旧可以通过SHOW SLAVE STATUSG,但是MySQL 5.7在performance_schema架构下多了以下这些元数据表,用户可以更细力度的进行监控:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
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                   |
+---------------------------------------------+
8rowsin set (0.00 sec)

System Variable

从库配置:

这意味着在 MySQL 5.7版本中即使不开启GTID,每个事务开始前也是会存在一个Anonymous_Gtid ,而这GTID中就存在着组提交的信息。

group replication

必威 7

group replication

  • Group Replication的实质是:
    • 二进制日志
    • 基于Row格式+GTID
    • 一个通信框架+事务排序控制(atomic message delivery & total ordering of message)
    • 增强半同步 & 并行复制
  • Group Replication是一个趋势
  • 备份不好搞定
    • mysqldump不支持一致性备份(5.7.18后支持)
    • xtrabackup备份,造成性能损失比较严重
  • 新的节点加入过程对原有集群性能有影响

总结

MySQL 5.7推出的Enhanced Multi-Threaded Slave解决了困扰MySQL长达数十年的复制延迟问题,再次提醒一些无知的PostgreSQL用户,不要停留在之前对于MySQL的印象,物理复制也不一定肯定比逻辑复制有优势,而MySQL 5.7的MTS已经完全可以解决延迟问题了。anyway,和Inside君一起见证划时代MySQL 5.7 GA版本的降临吧。

Status Variable

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

LOGICAL_CLOCK

5.7复制其他方面的增强

  • 动态变更filter
    • 不需要重启MySQL
    • 支持所有的Filter选项
    • 支持各种字符集
mysql>stop slave sql_thread;
mysql>CHANGE REPLICATION FILTER REPLICATE_DO_DB= (db1,db2);
mysql>start slave sql_thread;
  • 切换主时不用停sql_tread
  • 切换master时,只需停止io_thread,不需要停止sql_thread
mysql>stop slave io_thread;
mysql>change master to master_host='master-2',...;
mysql>start slave io_thread;
  • Replication的信息添加到了Performance Schema中
    • 通过SQL进行监控
    • 逻辑上无关的信息被放在不同的表中
  • 配置信息表
    • replication_connection_configuration
    • replication_applier_configuration
  • 状态信息表
    • replication_connection_status
    • replication_applier_status
    • replication_applier_status_by_coordinator
    • replication_applier_status_by_worker

参考文献:

  1. http://www.innosql.net

BTW: Inside君最近开通了微信公众账号InsideMySQL,希望小伙伴们前来关注

--本篇文章转自:

Option File

 再检查主库配置:

然而,通过上述的SHOW BINLOG EVENTS,我们并没有发现有关组提交的任何信息。但是通过mysqlbinlog工具,用户就能发现组提交的内部信息:

Scope

(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,表示这些事务都在一组内,可以进行并行的回放。

Dynamic

 发现主库根本就没有slave_parallel_type这项配置。想起来主库是mysql5.6了。

例如上述last_committed为0的事务有6个,表示组提交时提交了6个事务,而这6个事务在从机是可以进行并行回放的。

Notes

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

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

abort-slave-event-count

 那么问题基本上就知道了,主库5.6只支持基于DATABASE的并行复制,而5.7的从库配置成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是一个自增的值,offset在每次二进制日志发生rotate时更新,记录发生rotate时的state值。其实state和offset记录的是全局的计数值,而存在二进制日志中的仅是当前文件的相对值。使用LOGICAL_CLOCK的场景如下:

Yes

明白了问题所在,那就好解决了,把从库的slave_parallel_type改为DATABASE,再起sql_thread问题应该就解决了:

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的变量:

No

"root@localhost:mysql3308.sock  [none]>set global slave_parallel_type='DATABASE';
Query OK, 0 rows affected (0.00 sec)

"root@localhost:mysql3308.sock  [none]>show global variables like '%slave_parallel_type%';
+---------------------+----------+
| Variable_name       | Value    |
+---------------------+----------+
| slave_parallel_type | DATABASE |
+---------------------+----------+
1 row in set (0.00 sec)

"root@localhost:mysql3308.sock  [none]>show slave statusG
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: master
                  Master_User: rep
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000104
          Read_Master_Log_Pos: 160115307
               Relay_Log_File: oracle-relay-bin.000093
                Relay_Log_Pos: 152912092
        Relay_Master_Log_File: binlog.000100
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 1755
                   Last_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..
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 152911925
              Relay_Log_Space: 4455094667
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               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..
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 50
                  Master_UUID: 0b961fcc-41c2-11e7-84fd-286ed488c7da
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 3600
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: 
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 180716 18:02:56
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 0b961fcc-41c2-11e7-84fd-286ed488c7da:111060115-163843604
            Executed_Gtid_Set: 0b961fcc-41c2-11e7-84fd-286ed488c7da:1-156369774
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
1 row in set (0.00 sec)

"root@localhost:mysql3308.sock  [none]>stop slave sql_thread;
Query OK, 0 rows affected, 1 warning (0.00 sec)

"root@localhost:mysql3308.sock  [none]>start slave sql_thread;
Query OK, 0 rows affected (0.01 sec)

"root@localhost:mysql3308.sock  [none]>show slave statusG
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: master
                  Master_User: rep
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000104
          Read_Master_Log_Pos: 160161836
               Relay_Log_File: oracle-relay-bin.000093
                Relay_Log_Pos: 169205552
        Relay_Master_Log_File: binlog.000100
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 169205385
              Relay_Log_Space: 4455141196
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 5351
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 50
                  Master_UUID: 0b961fcc-41c2-11e7-84fd-286ed488c7da
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 3600
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Waiting for Slave Worker to release partition
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 0b961fcc-41c2-11e7-84fd-286ed488c7da:111060115-163843692
            Executed_Gtid_Set: 0b961fcc-41c2-11e7-84fd-286ed488c7da:1-156400100
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
1 row in set (0.00 sec)

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

No

打完收工。

并行复制测试

Yes

转载请注明出处。

下图显示了开启MTS后,slave服务器的QPS。测试的工具是sysbench的单表全update测试,测试结果显示在16个线程下的性能最好,从机的QPS可以达到25000以上,进一步增加并行执行的线程至32并没有带来更高的提升。
而原单线程回放的QPS仅在4000左右,可见MySQL 5.7 MTS带来的性能提升,而由于测试的是单表,所以MySQL 5.6的MTS机制则完全无能为力了。

 

本文地址:

并行复制配置与调优

No

master_info_repository

DESCRIPTION: Option used by mysql-test for debugging and testing of replication   mysql-test用于调试和测试复制的选项

开启MTS功能后,务必将参数master_info_repostitory设置为TABLE,这样性能可以有50%~80%的提升。这是因为并行复制开启后对于元master.info这个文件的更新将会大幅提升,资源的竞争也会变大。在之前 InnoSQL 的版本中,添加了参数来控制刷新master.info这个文件的频率,甚至可以不刷新这个文件。因为刷新这个文件是没有必要的,即根据master-info.log这个文件恢复本身就是不可靠的。在MySQL 5.7中,Inside君推荐将master_info_repository设置为TABLE,来减小这部分的开销。

binlog_gtid_simple_recovery

slave_parallel_workers

Yes

若将slave_parallel_workers设置为0,则MySQL 5.7退化为原单线程复制,但将slave_parallel_workers设置为1,则SQL线程功能转化为coordinator线程,但是只有1个worker线程进行回放,也是单线程复制。
然而,这两种性能却又有一些的区别,因为多了一次coordinator线程的转发,因此slave_parallel_workers=1的性能反而比0还要差,在Inside君的测试下还有20%左右的性能下降,如下图所示:
这里其中引入了另一个问题,如果主机上的负载不大,那么组提交的效率就不高,很有可能发生每组提交的事务数量仅有1个,那么在从机的回放时, 虽然开启了并行复制,但会出现性能反而比原先的单线程还要差的现象,即延迟反而增大了 。聪明的小伙伴们,有想过对这个进行优化吗?

Yes

Enhanced Multi-Threaded Slave配置

No

说了这么多,要开启enhanced multi-threaded slave其实很简单,只需根据如下设置:

Yes

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

Global

复制的监控依旧可以通过SHOW SLAVE STATUSG,但是MySQL 5.7在performance_schema架构下多了这些表,用户可以更细力度的进行监控:

No

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)
总结

DESCRIPTION: Controls how binary logs are iterated during GTID recovery 控制GTID在恢复期间如何迭代二进制日志

MySQL 5.7推出的Enhanced Multi-Threaded Slave解决了困扰MySQL长达数十年的复制延迟问题,再次提醒一些无知的PostgreSQL用户,不要再停留在之前对于MySQL的印象,物理复制也不一定肯定比逻辑复制有优势,而MySQL 5.7的MTS已经完全可以解决延迟问题。anyway,和Inside君一起见证划时代MySQL 5.7 GA版本的降临吧。

Com_change_master

 

No

MySQL5.7并行复制中并行的真正含义

No

我们知道MySQL5.7并行复制引入了两个值last_committed和sequence_number。last_committed表示事务提交的时候,上次事务提交的编号,在主库上同时提交的事务设置成相同的last_committed。如果事务具有相同的last_committed,表示这些事务都在一组内,可以进行并行的回放。这个机制也是Commit-Parent-Based SchemeWL#6314中的实现方式。不过之后,官方对这种模式做了改进,所以最新的并行回放机制和WL#6314有了不同,详情见Lock-Based SchemeWL#7165

Yes

这个参数设置为yes是为了确保,在slave上事务的提交顺序与relay log中一致。
但是经过测试,这个参数在MySQL5.7.18中设置之后,也无法保证slave上事务提交的顺序与relay log一致。
在MySQL5.7.19设置后,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.

No

Both

No

DESCRIPTION: Count of CHANGE MASTER TO statements  change master to 语句的统计

Com_show_master_status

No

No

Yes

No

Both

No

DESCRIPTION: Count of SHOW MASTER STATUS statements SHOW MASTER STATUS语句统计

Com_show_new_master

No

No

Yes

No

Both

No

DESCRIPTION: Count of SHOW NEW MASTER statements  SHOW NEW MASTER 语句的统计

Com_show_slave_hosts

No

No

Yes

No

Both

No

DESCRIPTION: Count of SHOW SLAVE HOSTS statements  SHOW SALVE HOSTS语句的统计

Com_show_slave_status

No

No

Yes

No

Both

No

DESCRIPTION: Count of SHOW SLAVE STATUS statements SHOW SALVE STATUS 语句统计

Com_show_slave_status_nonblocking

No

No

Yes

No

Both

No

DESCRIPTION: Count of SHOW SLAVE STATUS NONBLOCKING statements SHOW SLAVE STATUS NONBLOCKING 语句统计

Com_slave_start

No

No

Yes

No

Both

No

DESCRIPTION: Count of START SLAVE statements START SLAVE 语句统计

Com_slave_stop

No

No

Yes

No

Both

No

DESCRIPTION: Count of STOP SLAVE statements STOP SALVE语句统计

disconnect-slave-event-count

Yes

No

No

Yes

 

No

DESCRIPTION: Option used by mysql-test for debugging and testing of replication  mysql-test用于调试和测试复制的选项

enforce-gtid-consistency

Yes

Yes

No

Yes

Global

Yes

DESCRIPTION: Prevents execution of statements that cannot be logged in a transactionally safe manner 防止不能以事务安全方式记录的执行语句

enforce_gtid_consistency

Yes

Yes

No

Yes

Global

Yes

DESCRIPTION: Prevents execution of statements that cannot be logged in a transactionally safe manner 防止不能以事务安全方式记录的执行语句

executed-gtids-compression-period

Yes

No

No

Yes

 

No

DESCRIPTION: Deprecated and will be removed in a future version. Use the renamed gtid-executed-compression-period instead.在后期版本将被弃用,使用重命名的gtid-executed-compression-period 代替

executed_gtids_compression_period

No

Yes

No

No

Global

Yes

DESCRIPTION: Deprecated and will be removed in a future version. Use the renamed gtid_executed_compression_period instead. 在后期版本将被弃用,使用重命名的gtid-executed-compression-period 代替

gtid-executed-compression-period

Yes

No

No

Yes

 

No

DESCRIPTION: Compress gtid_executed table each time this many transactions have occurred. 0 means never compress this table. Applies only when binary logging is disabled. 每次发生此很多事务时压缩gtid_executed表。 0表示不压缩此表。 仅在禁用二进制日志记录时应用。

gtid-mode

Yes

Yes

No

Yes

Global

Yes

DESCRIPTION: Controls whether GTID based logging is enabled and what type of transactions the logs can contain 控制是否启用基于GTID的日志记录以及日志可包含的事务类型

gtid_executed

No

Yes

No

No

Global

No

DESCRIPTION: Global: All GTIDs in the binary log (global) or current transaction (session). Read-only.全局:二进制日志(全局)或当前事务(会话)中的所有GTID。 只读。

gtid_executed_compression_period

No

Yes

No

No

Global

Yes

DESCRIPTION: Compress gtid_executed table each time this many transactions have occurred. 0 means never compress this table. Applies only when binary logging is disabled.每次发生此很多事务时压缩gtid_executed表。 0表示不压缩此表。 仅在禁用二进制日志记录时应用。

gtid_mode

No

Yes

No

No

Global

Yes

DESCRIPTION: Controls whether GTID based logging is enabled and what type of transactions the logs can contain控制是否启用基于GTID的日志记录以及日志可包含的事务类型

gtid_next

No

Yes

No

No

Session

Yes

DESCRIPTION: Specifies the GTID for the next statement to execute. See documentation for details.指定要执行的下一个语句的GTID。 有关详细信息,请参阅文档。

本文由必威发布于必威-数据,转载请注明出处:将这个参数配置在my.必威:cnf配置文件中,半同

TAG标签:
Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。