任何大型项目都是从几台服务器开始的。 起初有一个数据库服务器，然后向其中添加从属服务器以扩展读取。 然后——停下来！ 主人只有一位，奴隶却有很多； 如果其中一个从服务器离开，那么一切都会好起来，但如果主服务器离开，情况就会很糟糕：停机，管理员正在尝试提升服务器。 该怎么办？ 预留一个师傅。 我的同事帕维尔已经写过这个 ，我就不重复了。 相反，我会告诉您为什么一定需要 Orchestrator for MySQL！
让我们从主要问题开始：“当主人离开时，我们如何将代码切换到新机器上？”
- 我最喜欢带有VIP（虚拟IP）的方案，我们下面会讲到。 这是最简单、最明显的，尽管它有一个明显的限制：我们要保留的主机必须位于新机器的 L2 段中，也就是说，我们可以忘记第二个 DC。 并且，以友好的方式，如果遵循大 L2 是邪恶的规则，因为 L2 仅适用于每个机架，而 L3 位于机架之间，并且这样的方案具有更多限制。
- 您可以在代码中写入DNS名称并通过/etc/hosts进行解析。 事实上，不会有任何解决方案。 该方案的优点：没有第一种方法的限制特性，即可以组织跨DC。 但随后出现了一个明显的问题：我们能多快通过 Puppet-Ansible 将更改传递到 /etc/hosts？
- 你可以稍微改变第二种方法：在所有Web服务器上安装缓存DNS，通过它代码将进入主数据库。 您可以在 DNS 中为此条目设置 TTL 60。 看起来，如果实施得当，这个方法是好的。
- 带有服务发现的方案，意味着使用Consul和etcd。
- 一个有趣的选择 。 你需要通过ProxySQL将所有流量路由到MySQL；ProxySQL本身可以决定谁是master。 顺便说一句，您可以在我的文章中阅读有关使用该产品的选项之一 .
Orchestrator的作者，在Github工作，首先用VIP实现了第一个方案，然后将其转换为用consul的方案。
典型的基础设施布局：
我将立即描述需要考虑的明显情况：
- VIP 地址不应在任何服务器的配置中注册。 让我们想象一种情况：主服务器重新启动，在加载时，Orchestrator 进入故障转移模式并使其中一个从服务器成为主服务器； 然后老爷子就起来了，现在贵宾就坐两辆车了。 这不好。
- 对于orchestrator，您需要编写一个脚本来调用旧master和新master。 在旧的 master 上，您需要运行 ifdown，在新的 master 上，您需要运行 ifup vip。 如果在此脚本中还包含以下内容，那就太好了：在发生故障转移时，只需关闭旧主交换机上的端口以避免任何裂脑。
- Orchestrator 调用您的脚本首先删除 VIP 和/或熄灭交换机上的端口，然后在新主设备上调用 VIP 提升脚本后，不要忘记使用 arping 命令告诉每个人新的 VIP 现已存在这里。
- 所有从属设备都应该有 read_only=1，并且一旦您将从属设备提升为主设备，它就应该有 read_only=0。
- 不要忘记，我们为此选择的任何从站都可以成为主站（编排器有一个完整的偏好机制，首先将哪个从站视为新主站的候选者，其次是哪个从站，以及应该将哪个从站视为新主站的候选者）任何情况下都不能选择高手）。 如果从机成为主机，那么从机的负载将保留在其上，并且主机的负载将被添加，这是必须考虑到的。
如果您没有 Orchestrator，为什么还需要 Orchestrator？
- Orchestrator 有一个非常用户友好的图形界面，可以显示整个拓扑（请参见下面的屏幕截图）。
- Orchestrator 可以跟踪哪些从属设备落后，以及复制通常在哪里发生故障（我们在 Orchestrator 上附加了用于发送 SMS 的脚本）。
- Orchestrator 会告诉您哪些从站的 GTID 错误。
编排器界面：
什么是 GTID 错误？
Orchestrator 的工作有两个主要要求：
- 需要在MySQL集群中的所有机器上启用伪GTID；我们启用了GTID。
- 任何地方都必须有一种类型的binlog，可以使用statement。 我们有一个配置，其中主设备和大多数从设备具有 Row，并且两个历史上保持混合模式。 因此，Orchestrator 根本不想将这些从站连接到新的主站。
请记住，生产从站中最重要的是它与主站的一致性！ 如果您在主服务器和从服务器上都启用了全局事务 ID (GTID)，那么您可以使用 gtid_subset 函数来查明这些机器上是否实际执行了相同的数据更改请求。 您可以阅读更多相关内容 .
因此，Orchestrator 通过 GTID 错误向您显示从属设备上存在主设备上没有的事务。 为什么会发生这种情况？
- Read_only=1 在从站上未启用，有人连接并完成了更改数据的请求。
- 从站上未启用 Super_read_only=1，然后管理员混淆了服务器，进入并在那里执行请求。
- 如果你考虑到前面的两点，那么还有一个技巧：在MySQL中，刷新binlog的请求也会进入binlog，因此在第一次刷新时，Master和所有Slave上都会出现GTID错误。 如何避免这种情况？ Perona-5.7.25-28 引入了 binlog_skip_flush_commands=1 设置，该设置禁止将刷新写入二进制日志。 mysql.com 网站上有一个已建立的 .
让我总结一下以上所有内容。 如果您还不想在故障转移模式下使用 Orchestrator，请将其置于观察模式。 然后，您眼前将始终看到 MySQL 机器的交互图，以及有关每台机器上的复制类型、从机是否落后以及最重要的是它们与主机的一致性的可视化信息！
显而易见的问题是：“Orchestrator 应该如何工作？” 他必须从当前的slave中选择一个新的master，然后将所有的slave重新连接到它（这就是需要GTID的原因；如果你使用带有binlog_name和binlog_pos的旧机制，那么将一个slave从当前的master切换到一个新的）根本不可能！）。 在我们拥有 Orchestrator 之前，我曾经不得不手动完成所有这些工作。 旧的 master 由于有缺陷的 Adaptec 控制器而挂起；它有大约 10 个从属设备。 我需要将 VIP 从主服务器转移到其中一个从服务器，并将所有其他从服务器重新连接到它。 我必须打开多少个控制台，我输入了多少个同时命令...我必须等到凌晨 3 点，删除除两个之外的所有从机的负载，使第一台机器脱离两个主机，立即连接第二台机器因此，将所有其他从站连接到新主站并返回负载。 总体而言，可怕...
Orchestrator 进入故障转移模式时如何工作？ 这是最容易通过一个例子来说明的，我们希望让主机成为比现在更强大、更现代的机器。
该图显示了该过程的中间部分。 到目前为止已经做了什么？ 我们说我们想让某个从站成为新的主站，Orchestrator 开始简单地将所有其他从站重新连接到它，新的主站充当中转机。 使用这种方案，不会发生错误，所有从站都工作，Orchestrator 从旧主站中删除 VIP，将其转移到新主站，使 read_only=0 并忘记旧主站。 全部！ 我们服务的停机时间是VIP转接时间，2-3秒。
今天就到这里，谢谢大家。 很快就会有第二篇关于 Orchestrator 的文章。 在著名的苏联电影《车库》中，一个角色说：“我不会和他一起侦察！” 那么，Orchestrator，我就和你一起去侦察吧！
来源： habr.com