MySQL的Orchestrator：为什么没有它就无法构建故障安全项目

任何重大项目都始于一对服务器。首先，有一台数据库服务器，然后将从服务器添加到其中以扩展读取范围。在这里-停下来！一位主人，但许多奴隶；如果其中一个从属服务器离开，那么一切都会好起来，但是如果主服务器离开，情况将会很糟：停机，管理员需要举起服务器。该怎么办？保留主人。我的同事帕维尔（Pavel）已经写了一篇有关此的文章，我不再重复。相反，我将告诉您为什么您肯定需要MySQL的Orchestrator！

让我们从主要问题开始：“向导退出后，如何将代码切换到新计算机上？”

• 我最喜欢使用VIP（虚拟IP）的方案，下面我们将对其进行讨论。它是最简单和最明显的，尽管它有一个明显的局限性：我们将保留的主服务器必须位于新机器的L2段中，也就是说，您可以忘记第二个DC。而且，以一种好的方式，如果您遵循大L2是邪恶的规则，因为L2仅在机架上，并且在机架L3之间，这样的方案有更大的限制。
• 您可以在代码中注册DNS名称，并通过/ etc / hosts解析它。实际上，将没有解决方案。该方案的优点：第一种方法没有限制特性，也就是说，也可以组织跨DC。但是随后出现了一个明显的问题，即通过Puppet-Ansible我们可以多快将更改交付给/ etc / hosts。
• 您可以稍微更改第二种方法：在所有Web服务器上，我们都放置了缓存DNS，通过该DNS，代码将进入主数据库。您可以为此DNS条目注册TTL 60。似乎，通过适当的实现，该方法是好的。
• 具有服务发现的方案，涉及使用Consul和etcd。
• ProxySQL一个有趣的选项。必须通过ProxySQL将所有流量包装到MySQL，ProxySQL可以确定现在是谁。顺便说一下，可以在我的文章中找到使用该产品的一种选择。

在Github工作的Orchestrator的作者首先使用VIP实施了第一个方案，然后将其重新引入领事的方案。

典型的基础架构方案：

我将立即描述要考虑的明显情况：

• VIP- . : , , Orchestrator failover ; , VIP . .
• . ifdown, — ifup vip. , failover , splitbrain.
• , Orchestrator , VIP / , VIP, arping , VIP .
• 所有从站都应具有read_only = 1，并且一旦将从站提升为主站，它就应具有read_only = 0。
• 请不要忘记我们为此选择的任何从属都可以成为主节点（协调器具有完整的偏好机制，首先应将哪个从属节点视为新主节点的候选者，其次是一个，而在任何情况下都不应选择该从属节点。主）。如果从属设备成为主设备，则将保留从属负载并添加主设备负载，这必须予以考虑。

如果没有一个，为什么绝对需要Orchestrator？

• Orchestrator具有非常用户友好的图形界面，可显示整个拓扑（请参见下面的屏幕截图）。
• Orchestrator可以跟踪哪些从属服务器位于后面，以及复制在何处中断（我们有用于将SMS发送到Orchestrator的脚本）。
• Orchestrator会告诉您哪些幻灯片出现GTID错误。

Orchestrator界面：

什么是GTID错误？

要使Orchestrator工作，有两个基本要求：

• 必须在MySQL集群中的所有计算机上启用伪GTID，我们已启用GTID。
• 您必须声明，到处只有一种类型的Binlog。我们有一个配置，其中Row在主服务器和大多数从属服务器上，而混合模式在历史上仍然保留在两个上。结果，Orchestrator只是不想将这些从属服务器连接到新的主服务器。

请记住，生产从属服务器中最重要的事情是它与主服务器的一致性！如果在主服务器和从服务器上都启用了全局事务ID（GTID），则可以使用gtid_subset函数来确定在这些计算机上是否实际执行了相同的数据更改请求。在此处阅读有关此内容的更多信息。

因此，Orchestrator通过一个GTID错误错误向您显示该从服务器上的事务不在向导上。为什么会发生？

• 从站未启用Read_only = 1，有人连接并执行了数据更改请求。
• 在从属服务器上未启用Super_read_only = 1，然后，管理员将服务器混为一谈，然后在其中执行请求。
• 如果您考虑了以上两段内容，则还有另外一个技巧：在MySQL中，对刷新binlog的请求也将落入binlog中，因此，当您第一次刷新时，向导和所有从属上都会出现GTID错误。如何避免这种情况？在perona-5.7.25-28中，出现binlog_skip_flush_commands = 1设置，该设置禁止将刷新写入二进制日志。mysql.com中有一个错误。

我总结了以上所有内容。如果您不想在故障转移模式下使用Orchestrator，请将其置于监视模式。这样一来，您将始终可以看到MySQL机器之间的交互作用图，以及有关每台机器上哪种复制类型，从机是否在后面以及最重要的一点-它们与主服务器有多少一致性的清晰信息！

显而易见的问题是：“协调器应该如何工作？”他必须从当前从站中选择一个新的主站，然后将所有从站重新连接到它（这就是GTID的目的;如果您将旧机制与binlog_name和binlog_pos一起使用，那么将从站从当前主站切换到新主站是完全不可能的！）。在Orchestrator来到我们之前，我曾经不得不手动完成所有这些操作。原来的主机由于有故障的Adaptec控制器而崩溃，它有大约10个从机。我需要将VIP从主机传输到一个从机，然后将所有其他从机重新连接到它。我必须打开多少个控制台，要输入多少个并发命令...我不得不等到凌晨3点，从除两个之外的所有从站上卸下负载，使两个主站中的第一个轿厢从中出来，立即将第二辆轿厢挂接到它上，因此，将所有其他从站拾取到新的主站并返回负载。总的来说，恐怖...

Orchestrator进入故障转移模式时如何工作？我们希望使母版比现在更强大，更现代的机器的情况最容易说明这一点。

该图显示了过程的中间部分。到目前为止，已经做了什么？我们说过，我们想使某种从属服务器成为新的主服务器，Orchestrator刚刚开始将所有其他从属服务器重新连接到该主服务器，而新的主服务器充当了传输机器。使用这种方案，不会发生错误，所有从属都可以工作，Orchestrator从旧的主控器中删除VIP，将其转移到新的VIP，使read_only = 0并忘记了旧的主控器。所有！我们服务的停机时间是VIP传输时间，为2-3秒。

今天就这些，谢谢大家。很快将有第二篇有关Orchestrator的文章。在苏联著名的电影《车库》中，一位英雄说：“我不会和他在一起！” 因此，协调器，我将和您一起侦察！