在云中运行ClusterControl时的注意事项

MySQL中的复制已经存在了很长一段时间，并且在过去的几年中一直在稳步改进。它更像是进化而不是革命。这是完全可以理解的，因为复制是许多人依赖的一个重要特性—它必须工作。

在最近的MySQL版本中，我们看到了通过支持并行应用事务来提高复制性能。在MySQL5.6中，并行化是在模式级别完成的——所有在不同模式中执行的事务都可以一次执行。对于那些在一台服务器上有多个模式的工作负载来说，这是一个很好的改进，而且负载或多或少地均匀分布在这些模式上。

在MySQL 5.7中，增加了另一种并行化方法，即所谓的“逻辑时钟”。它允许在从属服务器上获得某种程度的并发性，即使您的所有数据都存储在单个模式中。简而言之，它基于这样一个事实：由于硬件增加了延迟，一些事务将一起提交。您甚至可以手动添加延迟，以便使用binlogu groupu commitu syncu delay在从属服务器上实现更好的并行化。

这个解决方案真的很好，但不是没有缺点。提交事务的每一次延迟最终都会影响应用程序中面向用户的部分。当然，你可以在几毫秒的范围内设置延迟，但即便如此，还是会有额外的延迟减慢应用程序的速度。

MySQL 8.0中的复制性能改进

MySQL8.0目前（2017年8月）仍处于测试状态，它为复制带来了一些不错的改进。最初，它是为组复制（GR）而开发的，但由于GR在后台使用常规复制，“普通”MySQL复制从中受益。我们提到的改进是二进制日志中存储的依赖跟踪信息。MySQL8.0现在有了一种方法来存储关于哪些行受给定事务影响的信息（称为writeset），并比较不同事务的writeset。这使得识别那些不在同一行子集上工作的事务成为可能，因此，这些事务可以并行应用。与MySQL5.7中的实现相比，这可以使并行化级别提高几倍。您需要记住的是，最终，从机将看到不同的数据视图，一个从未出现在主机上的视图。这是因为应用事务的顺序可能与应用于主机的顺序不同。不过，这应该不是问题。MySQL5.7中当前多线程复制的实现也可能导致此问题，除非显式启用slave preserve commit order。

为了控制这种新的行为，引入了变量binlogu transactionu dependencyu tracking。它可以有三个值：

• 提交顺序：这是默认的，它使用MySQL5.7中的默认机制。

• 写集：它可以实现更好的并行化，并且主服务器开始将写集数据存储在二进制日志中。

• 写集会话：这确保事务将按顺序在从服务器上执行，并解决从服务器看到的问题数据库的一种从未在主机上出现过的状态被消除。它减少了并行化，但仍能提供比默认设置更好的吞吐量。

基准

一位作者写了一篇文章，他试图衡量新模式的性能。他使用了最好的场景——没有任何耐用性，来展示新旧模式之间的差异。我们决定使用相同的方法，这次是在一个更真实的设置中：二进制日志启用了logu-slave-u更新。耐久性设置保留为默认值（因此，syncu binlog=1-这是MySQL8.0中的新默认值，启用了doublewrite缓冲区，启用了InnoDB校验和等）耐久性中唯一的例外是InnoDBu flushu logu atu trxu commit设置为2。

我们使用m4.2xl实例、32G、8核（因此slaveu parallelu workers设置为8）。我们还使用了sysbench，oltpu read_写入.lua脚本。在1000gbgp2卷（即3000 IOPS）上存储了32个表中的1600万行。我们测试了1、2、4、8、16和32个并发sysbench连接的所有模式的性能。过程如下：停止slave，执行100k事务，启动slave并计算清除slave延迟所需的时间。

首先，我们不知道当sysbench只使用一个线程执行时发生了什么。每项测试在预热运行后执行五次。这个特定的配置被测试了两次——结果是稳定的：单线程工作负载是最快的。我们将进一步调查，以了解发生了什么。

除此之外，其余结果与我们的预期相符。提交顺序是最慢的，特别是对于低流量、2-8个线程。WRITESETu会话通常比COMMITu顺序执行得更好，但对于低并发流量，它比WRITESET慢。

它能帮我什么？

第一个优点是显而易见的：如果您的工作负载很慢，而从属服务器在复制方面却有后退的趋势，那么一旦主服务器升级到8.0，它们就可以从改进的复制性能中获益。这里有两个注意事项：第一，这个特性是向后兼容的，5.7从属也可以从中受益。第二，提醒您8.0仍处于beta测试状态，我们不鼓励您在生产中使用beta软件，尽管急需，但这是一个测试选项。此功能不仅可以在从属服务器落后时帮助您。他们可能会被完全赶上，但当你创建一个新的奴隶或重组现有的一个，奴隶将落后。能够使用“WRITESET”模式将使配置新主机的过程更快。

总而言之，这个特性将产生比你想象的更大的影响。当MySQL处理低并发流量时，所有的基准测试都显示出性能的下降，任何有助于在这样的环境中加速复制的东西都是一个巨大的改进。

如果您使用中间主控形状，这也是要查找的功能。任何中间主机都会在处理和执行事务的方式中添加一些序列化—在现实世界中，中间主机上的工作负载几乎总是不如主机上的并行。利用writesets实现更好的并行化，不仅可以提高中间主机的并行化，而且可以提高所有从机的并行化。甚至可以使用8.0中间主服务器来提高从属服务器的复制性能（请记住，MySQL5.7从属服务器可以理解writeset数据并使用它，即使它不能自己生成数据）。当然，从8.0复制到5.7听起来相当棘手（这不仅仅是因为8.0仍然是beta版）。在某些情况下，这可能会起作用，并会加快5.7从属服务器上的CPU利用率。

MySQL复制中的其他更改

引入writesets虽然是最有趣的，但它并不是MySQL 8.0中MySQL复制的唯一变化。让我们看看其他一些，也是重要的变化。如果您使用的主机比MySQL5.0旧，那么8.0将不支持其二进制日志格式。我们不希望看到很多这样的设置，但是如果您使用一些非常旧的MySQL进行复制，那么肯定是时候升级了。

默认值已更改，以确保复制尽可能安全：masteru infou repository和relayu logu infou repository设置为TABLE。Expireu log u days也已更改-现在默认值为30。除了expire log days之外，还添加了一个新变量binlog expire log seconds，它允许更细粒度的binlog循环策略。在二进制日志中添加了一些额外的时间戳，以提高复制延迟的可观察性，引入了微秒级的粒度。

当然，这并不是一个完整的与MySQL复制相关的更改和特性列表。如果您想了解更多信息，可以查看MySQL变更日志。确保您已经审阅了所有这些特性—到目前为止，所有8.0版本中都添加了这些特性。

正如您所看到的，MySQL复制仍在发生变化并变得更好。正如我们在一开始所说，这必须是一个缓慢的过程，但看到未来的发展真的很棒。在“常规”MySQL复制中，还可以看到组复制的工作逐渐深入并重用。