共计 3274 个字符，预计需要花费 9 分钟才能阅读完成。
MySQL 复制从问世到现在已经经历了多个年头，它的稳定性和可靠性也在稳步的提高。这是一个不停进化的过程，由于 MySQL 的很多重要功能都是依赖于复制，所以复制的快速发展也是很容易理解的。
在 MySQL 的上一个版本当中，MySQL 通过实现真正意义的并行复制将复制的性能提升到了一个新的层面，因为在 MySQL 5.6 的版本中，虽然号称是实现了并行复制，但是并行复制是 schema 级别的，即如果 binlog row event 操作的是不同的 schema 的对象，在确定没有 DDL 和 foreign key 依赖的情况下，就可以实现并行复制，并不能称为真正意义的复制。它只是将不同 schema 的事物分开来执行，并不能真正意义的实现并行复制（比如主从架构只有一个 schema 的情况还是很多见的）。当然如果你的主从架构有多个 schema 的话，5.6 的并行复制是对性能有很大的提升的。
MySQL5.7 的并行复制是基于组提交（group commit）的并行复制的方法，5.7 的并行复制，即使你的多个事物是对同一个 schema 进行操作，也能够在从库上并行回放。简而言之，就是多个事物如果相互不影响，在刷盘的时候是能够作为一个组来提交刷盘，我们甚至可以通过在从库手动设置 binlog_group_commit_sync_delay 这个参数控制日志在刷盘前日志提交要等待的时间，从而提高从库复制的效率。
这个方案看起来似乎很完美，但是并不是没有缺点。事物提交的延迟，最终都会影响到应用端的用户体验。当然，你可以将延迟设置在几毫秒内，但是即使是这样还是会影响到客户端的时效性。
MySQL8.0 复制性能的提升
截至目前（2017 年 8 月）的 MySQL 8.0 最新发布了 beta 版本，起初是为了组复制（GR）开发的，但是由于 GR 在底层也是使用的普通复制，普通复制也受益匪浅。我们提到的改进是 8.0 在 binary log 中加入了一些依赖的跟踪信息。在 MySQL8.0 中，MySQL 通过一种方法能够存储记录那些行受到了那些事物的影响信息（称之为 writeset），而且 MySQL 可以对比不同事物的 writeset 信息，这样就可以将两个事物是否是对同一个对象的同一行进行操作，如果不是，就可以并行执行。这相比于 MySQL5.7 的复制又提升了一个级别。你需要牢记的事，最终，从库看到的数据可能会出现和主库不同的情况，这种情况是永远不会发生在主库的。发生这种情况的原因是因为，从库执行事物的顺序可能和主库执行事物的顺序是不一致引起的。虽然这并不能称之为一个问题，MySQL5.7 的并行复制机制也是会产生这个问题的，除非你指定启用了 slave-preserve-commit-order 这个参数。
为了避免这种情况的发生，MySQL8.0 新增了 binlog_transaction_dependency_tracking 参数来解决这个问题。他可以取以下三个值：
COMMIT_ORDER：默认设置，默认设置为 MySQL5.7 的默认机制
WRITESET：它能够实现更好的并行化，并且主库开始在二进制日志中存储写入 writeset 信息
WRITESET_SESSION：设置事物在从库是顺序执行的，这就消除了我们上面说的从库查看数据可能会存在和主库不同的情况。设置为这个值会虽然会降低并行复制的性能，但是相比默认设置来说，性能还是有很大提升的。
基准测试
7 月份，Vitor Oliveira 在 mysqlhighavailability.com 上写了一篇文章，他试图测试复制新模式下的性能。在他的测试中，使用了最理想的情况 - 没有做数据持久化，借此来对比新旧复制模式下的性能。我们决定使用相同的方法，这一次在一个更接近生产的设置：使用 log_slave_updates 启用二进制日志。持久化参数在 MySQL8.0 中是默认的（sync_binlog=1- 这在 MySQL8.0 是默认的，开启了双写缓存和 innodb 校验），innodb_flush_log_at_trx_commit 设置为 2。
我们看一下机器的配置，32G，8 核（slave_parallel_workers 设置为 8），测试工具为 sysbench 的 oltp_read_write.lua 脚本，32 个表中的 1600 万行存储在 1000GB gp2 卷上（即 3000 IOPS），我们在所有复制模式下分别开 1,2,4,8,16,32 并发对性能进行测试和对比。测试过程如下：停止 slave，执行 100000 个事物，打开 slave 并计算从库追上主库的时间。
首先，我们不知道当使用 1 个线程执行 sysbench 时发生了什么。每次测试在暖机运行后执行了五次。这个特殊的配置被测试了两次 – 结果是稳定的：单线程工作量是最快的。我们将进一步研究，以了解到底是为什么。
除此之外，一切都符合我们的预期。COMMIT_ORDER 是最慢的，特别是对于低流量，2- 8 线程。WRITESET_SESSION 通常比 COMMIT_ORDER 效率更好，但是对于低并发流量，它比 WRITESET 慢。
这对我来说有什么好处？
第一个益处是显而易见的，如果你的数据库负载较高，而且从库有延迟的话，你可以通过将主库升级为 MySQL 8.0 来提升复制的性能。这里需要留意两个方面：第一，此功能向下兼容，即使的从库是 MySQL 5.7，性能也能有很好的提升；第二，MySQL8.0 暂时并没有 GA, 所以说不推荐在生产库使用 Beat 版本。MySQL8.0 对复制的提升不仅能够很好解决从库延迟的问题，这种情况下主从的延迟几乎是没有的，除非你重新添加一个新的 slave 或者重新配置了 slave 的时候可能会产生延迟。如果使用“WRITESET”模式将使得配置新主机的过程更加快捷。
总而言之，这个功能可能比你预期的产生更大的影响，鉴于所有基准测试，显示 MySQL 处理低并发性流量时的性能回归，任何有助于提高在这种环境中复制的效率的任何操作都将是巨大的进步。
如果你使用了级联复制，这也是你需要了解的一个功能。任何中间主节点都会将事务处理和执行的方式添加一些序列化的信息 - 但是真是情况却是，中间节点的负载要比主库要小。因为他使用了一些写入组件来实现更好的并行化，从而提高了自身和自身从库的并行效率。甚至你可以通过将中间节点的主库升级为 MySQL8.0 来提高下层从库的节点（请记住，MySQL 5.7 从站可以识别 riteet 数据并使用它，即使它不能自己生成它）。当然，MySQL 8.0 到 5.7 的主从复制听起来确实是很棘手的，这倒不是因为 MySQL8.0 还没有 GA 的原因。当然在一些情况下，这可以使从库的 CPU 使用率得到很好的提升。
MySQL 复制的其他变化
MySQL8.0 对于复制最主要的提升就是引入了 writesets，但是这并不是唯一的变化。让我们来看一下其他的一些重要的改进，如果你的主库是 MySQL5.0 以下版本，8.0 将不再支持读取它的二进制日志，所以如果你使用的还是老版本的 MySQL 进行传统复制，是时候升级你的数据库版本了。为了确保复制的安全性和稳定性，修改了复制了默认参数：master_info_repository 和 relay_log_info_repository 默认将设置为 table，Expire_log_days 默认设置为 30，除了 Expire_log_days，还新增了一个参数 binlog_expire_log_seconds，这将对 binlog 的轮询策略实现更细粒度的管控。在 binlog 信息中将会添加一些额外的时间戳信息，目的是能够更好的观察监控复制的延迟，达到微妙级别。
总而言之，这不是与 MySQL 复制相关的更改和功能的完整列表。你可以访问这里获得完整的列表信息，了解复制功能的所有的改进和提升。
如我们所知，MySQL 的复制正在变化，而且越来越好。正如我们开始所说，虽然这是一个缓慢进步的过程，但是我们已经可以看到了它的大好前景了。而且我们也很高兴看到 Group Replication 的底层复制也是采用了常规复制的功能来。
