MySQL InnoDB集群 - HelloWorld开发者社区

作者：Miguel Araújo 译：徐轶韬

MySQL开发团队发布InnoDB集群的8.0维护版本 - 8.0.17！

除了重要的错误修复和改进之外，8.0.17还带来了改变游戏规则的功能！

这篇博文将涵盖MySQL Shell和AdminAPI，如需详细了解MySQL路由器的新功能，请关注即将发布的博客文章！

MySQL Shell AdminAPI

对于这个版本，我们将重点放在扩展AdminAPI和整个InnoDB集群上，并提供一个非常重要的特性——自动节点配置!

除此之外，我们对内部帐户的AdminAPI处理进行了重新设计和改进，并对其进行了扩展，以提供更好的监视功能和跨版本策略的处理。最后，随着许多bug的修复，质量得到了很大的提高。

以下是此版本的亮点：

自动节点配置
改进和简化的内部恢复帐户管理
自动处理跨版本策略
改进了集群状态信息

自动节点配置

AdminAPI提供了一种简单直接的方法来管理集群拓扑，以便从中添加或删除实例。但是，要成功接受集群中的新成员，群组复制要求所有成员都已同步，即在分布式恢复阶段，加入成员已经处理了与其他组成员相同的一组事务。

分布式恢复

群组复制实现了一种机制，允许服务器从集群中获取丢失的事务，以便它可以成功加入集群。这种机制称为分布式恢复，在MySQL 8.0.16和更早版本中，它只能通过在连接实例和集群成员之间建立一个常规的异步复制通道来实现。

通常，二进制日志会随着时间的推移而清除，如果仅依赖于分布式恢复的异步复制通道，数据有可能无法从提供者复制到接收者。最重要的是，大型数据集可能需要相当长的时间才能被复制，这意味着在很长一段时间内，实例将无法作为集群的ONLINE成员使用。

也就是说，基于异步复制的分布式恢复对于某些常见场景是不够的......

随着MySQL 8.0.17的发布，终于改变了这一切！通过在MySQL中引入内置的克隆支持，以及通过Group Replication进行集成，我们终于可以克服这些限制并转向完整的开箱即用的HA解决方案。

通常，克隆插件允许获取数据库的物理快照并通过网络将它们传输到配置服务器。因此，无需任何外部工具即可启用远程克隆。

注意：克隆
使用提供者的物理快照完全覆盖接收者的状态。

为了实现克隆插件和群组复制提供的自动节点配置的透明处理和管理，我们从三个方面扩展了AdminAPI：

内置的检查和提示，引导用户通过方便和理想的路径来完成他们的需求。
能够选择在群组复制的分布式恢复期间应使用哪种数据传输机制。
使用动态进度信息监视配置过程。

最重要的是，AdminAPI会自动且透明地管理恢复帐户的所有处理以及内置克隆支持的任何必要步骤。

有关如何实现这一目标的详细信息将在一系列文章中进行描述，从这篇博文https://mysqlhighavailability.com/?p=9042 开始，该文章以AdminAPI中的自动节点配置截屏视频开头！

在这篇博文中值得一提的是API的变化和扩展。

dba.checkInstanceState（）

此命令可以确定实例是否将成功加入集群，具体取决于GTID集的状态与集群进行比较。我们已经大幅改进了检查功能，准确的说，也考虑到克隆可以在目标实例上使用的情况。

MySQL InnoDB集群

dba.createCluster（）

默认情况下，AdminAPI将确保在创建集群时安装克隆插件。

但是，添加了一个dba.createCluster() 的新选项，以允许禁用集群使用克隆：

disableClone

.setOption（）和 .options（）

对 <Cluster>.setOption() 进行了扩展，允许正在运行的集群更改 disableClone的值。因此，可以随时禁用克隆使用，甚至也可以在不使用时启用它。

在.options()之上扩展了disableClone的值。

MySQL InnoDB集群

.addInstance()

关于用于传输数据的分布式恢复机制 .addInstance()，

AdminAPI默认处理它并相应地引导用户，也可以明确地设置应该使用哪一个。因此，该命令已使用名为`'recoveryMethod'` 的新选项进行扩展，该选项接受以下值：

incremental：使用异步复制通道来恢复和应用从另一个集群成员复制的丢失事务。克隆将被禁用。
clone：使用内置的MySQL克隆支持，使用另一个集群成员的完整快照替换目标实例的状态。需要MySQL 8.0.17或更高版本。
auto：让Group Replication根据目标服务器支持的内容和group_replication_clone_threshold 的设置来选择是否必须执行完整快照。这是默认值。如果无法自动确定执行方式，将显示提示。如果禁用交互，则将取消操作。

MySQL InnoDB集群

进度监测

已经增加了对恢复进度进行全面详细监测的功能<Cluster>.addInstance()。现在可以通过进度信息对克隆的恢复速度进行监控。

MySQL InnoDB集群

8.0.17中引入的一个非常明显的变化是<Cluster>.addInstance()，默认情况下，在返回给用户之前，要等到分布式恢复过程完成并且集群中的实例处于ONLINE状态。

进度监视是异步进行的，可以通过按_ctrl-c_随时中断。即使退出shell，恢复过程也会正常继续。

控制监控行为

为了控制监控的行为，<Cluster>.addInstance()添加了一个名为'waitRecovery'的新选项。该选项可以采用以下值：

0：不要等待，让恢复过程在后台完成。
1：阻止，直到恢复过程结束。
2：阻止，直到恢复过程完成并显示进度信息。
3：阻止，直到恢复过程完成并使用进度条显示进度。

通过将'waitRecovery'选项设置为'0'可以设置以前的非阻塞行为，其中. addinstance()即使在恢复尚未完成时也返回。

例： cluster.addInstance（“clusterAdmin@10.276.2.10：3306”，{waitRecovery：0}）

.status()

在任何时候，都可以使用常规方法.status()检查进度信息

以下屏幕截图显示了基于克隆的恢复时，该命令输出的片段。

MySQL InnoDB集群

简化内部恢复帐户

无论是使用基于克隆的机制来传输数据还是异步复制通道，分布式恢复都需要一个恢复帐户。Shell会自动安全地创建和管理这些帐户。

出于安全原因，Shell不会存储这些内部帐户的凭据，而是根据命名模式mysql_innodb_cluster_r[10_numbers]为每个新加入成员创建一个具有唯一生成密码的新帐户。

使用的主机名都是通配符'%'，允许从每个主机访问'localhost'。如果使用IP白名单，将为 ipWhitelist列表中的每个地址创建一个内部使用地址。密码是随机生成的安全值。

尽管这允许透明和自动处理复制帐户，但也存在一些缺陷。在某些情况下，为每个实例创建多个这样的帐户（为每个可能的连接主机创建一个帐户）。最重要的是，从集群中删除实例并不意味着从集群本身删除了它的恢复帐户。如果一个InnoDB集群用户根据需要扩展它的应用服务器(在这些服务器上丢失和重新创建)，那么孤立的复制帐户将呈指数级增长。

这样的情况肯定是不受欢迎的，因此，在8.0.17中，我们大大改进了InnoDB集群内部帐户的管理。

帐户处理在8.0.17中已经改变，其目标是：

每个集群成员应具有为每个集群拓扑更改自动管理的单个复制帐户。

为了简化这一点，现在只要实例加入集群，就会创建一个帐户，遵循命名模式mysql_innodb_cluster_[server_id]@%。由于集群中的实例必须具有唯一的@@server_id，因此可以更简单地管理恢复帐户。

最后，<Cluster>.removeInstance()删除要在集群的主要成员上删除的实例的恢复帐户。

总而言之，账户的处理已大大改善：

简化帐户命名
相应地自动创建，重新使用或删除帐户
删除ipWhitelist处理
不允许帐户的指数增长

处理跨版本策略

理想情况下，InnoDB集群的所有成员都应运行相同的MySQL Server版本，以获得最佳性能和兼容性。然而，在联机集群上执行常见的场景(如升级或降级集群)是可取的，否则将丢失可用性。因此，InnoDB集群支持在同一个集群中混合使用不同的MySQL版本。但是，考虑到新版本可能会出现新功能甚至折旧，依赖此类功能的集群成员将会产生错误。此外，如果正在使用仅在新版本中支持的新功能，则数据写入到比其余成员更新版本的集群成员可能会导致问题。

为了防止出现这种情况，使用适当的跨版本策略，可以禁止特定的一组版本加入集群和/或限制并强制实施集群中的实例角色。

8.0.16之前，这些策略仅考虑实例的主要版本。但是，由于MySQL的发布模型允许快速和持续改进，并在补丁版本中引入功能，Group Replication改进了策略以考虑补丁版本。这样，我们可以在执行常规操作，群组重新配置和升级方案期间确保混合版本集群的复制安全性。

此类策略由Group Replication内部处理，但为了提供最佳可用性，AdminAPI应事先运行这些检查，以正确通知用户由于跨版本策略而导致的任何错误或警告。

在8.0.17中，我们扩展了AdminAPI以支持兼容性策略。<Cluster>.addInstance()操作现在可以检测由于MySQL版本导致的不兼容性，如果不兼容将终止，并发送信息错误或警告。

MySQL InnoDB集群

在上面的示例中，集群由运行8.0.15的实例和加入的8.0.17实例组成。跨版本策略要求实例可以加入集群，但无论集群拓扑的模式如何，都将以R / O模式运行。

改进了群集状态信息

根据'extended'选项的值，将.status()输出更改为包含新信息:

0：禁用命令详细信息（默认）
1：包括有关群组复制报告的群组协议版本，群组名称，集群成员UUID，集群成员角色和状态以及受保护的系统变量列表信息
2：包括有关连接和应用程序处理的事务的信息
3：包含有关每个集群成员的复制机制的更详细的统计信息。
布尔值：等效于0或1

此外，<Cluster>.status()的属性'mode'会考虑super_read_only的值以及集群是否具有仲裁，例如，当集群成员启用super_read_only时，它的属性'mode'反映实例的实际模式，即R/O。最重要的是，当一个集群失去其仲裁时，所有集群成员都被列出为R/O。

最后，我们添加了以下新属性，只要'extended'设置为大于等于1的值：

memberRole

Group Replication本身提供的成员角色，即来自performance_schema.replication_group_members.MEMBER_ROLE

memberState

Group Replication本身提供的状态，即来自performance_schema.replication_group_members.MEMBER_STATE

fenceSysVars

列表包含已启用的fence系统变量的名称。考虑的_fence sysvars_是read_only， super_read_only 和 offline_mode。

在上一个示例里，我们在8.0.15集群上添加了一个8.0.17实例，并强制实施了加入实例必须在R / O模式下运行的跨版本策略。这是一个很好的例子来说明<Cluster>.status()其中的变化。以下屏幕截图包含将扩展选项设置为“1”时命令输出的片段：

MySQL InnoDB集群

如您所见，8.0.17实例的角色是“PRIMARY”，但是，它的模式是“R / O”。除此之外，还提供了一个fence sysvars列表：“super_read_only”和“read_only”。

值得注意的错误修复

有关此版本中错误修复的完整列表，请参阅更改日志。在这里列出一些值得关注的修复。

BUG＃28855764 - Shell创建的用户使用Default_password_lifetime过期

如果定义了全局密码过期策略，AdminAPI创建的内部恢复帐户可能无法使用。这已通过禁用这些用户的密码过期来解决。对于这些用户，他们不需要考虑密码策略，因为他们是在内部经过安全处理的。

BUG＃29305551 - Adminapi无法检测到实例正在运行异步复制

要为InnoDB集群使用实例，无论是在其上创建集群还是将其添加到现有集群，都要求该实例尚未在异步（主从）复制中充当从服务器。到目前为止，dba.checkInstanceConfiguration()错误地报告该实例对集群使用有效。因此，dba.createCluster()和<Cluster>.addInstance()在没有提供信息的情况下发生错误。

通过引入检查来验证是否已将实例配置为使用异步复制的从服务器，如果是，则产生信息错误。