我有一个想法，一个让Vitess自力更生的想法、一种消除Vites与外部故障检测和修复工具之间摩擦的想法、一个产生VTOrc的想法…
VTOrc和Orchestrator都是用于管理MySQL实例的工具。如果我用隐喻来描述这些工具，我会说它们有点像一班学生的班长。他们负责检查MySQL实例并修复它们，以防它们行为不端，就像监视器如何确保教室中不会发生恶作剧一样。
VTOrc最初是Orchestrator的一个分支，然后它被定制到作为本地Vites组件运行的Vites用例中。VTOrc和Orchestrator就像双胞胎，如果你从远处看，你可能会认为他们是一样的，做着同样的事情，但是你看得越近，在架构、功能和灵活性方面出现的差异就越多。
两者之间的大部分差异很大程度上源于这样一个事实，即VTOrc可以对很多事情固执己见，因为它只需要解决一个用例，即Vites用例，但Orchestrator实际上是为使用任何MySQL拓扑而构建的。例如，Vites当前不支持分层复制。在一个碎片中有一个主平板电脑，以及这些主平板电脑的副本。没有级联复制。在稳定状态下，没有复制副本从其他复制副本复制。但Orchestrator允许这种配置。因此，VTOrc不必担心层次结构拓扑，它可以消除Orchestrator提供的灵活性，支持与其他Vites组件（如vtcltd）连接的更简单的代码。
发现
两者的第一点区别在于Orchestrator本身是一个完整的工具，而VTOrc是一个更大的框架Vites的一部分。因此，VTOrc可以依靠Vitess的其他组件进一步简化其设计。让我们看看MySQL实例发现，以更好地理解这一点。
从Orchestrator关于Discovery的文档中，Orchestractor会主动读取您的拓扑并对其进行映射。它读取MySQL的基本信息，如复制状态和配置。另一方面，VTOrc采取了完全不同的方法。在Vitess中，所有MySQL实例都有一个名为VTTablet的侧车。这些VTTablet在拓扑服务器中注册。因此，VTOrc可以直接向拓扑服务器请求VTTablet的详尽列表，以获取它所关心的碎片，并使用这些记录来发现和轮询底层MySQL实例。
发现还有一个超越当前状态的维度。MySQL实例应该在拓扑中运行。从VTOrc的角度来看，我们已经知道Vitess只支持一个MySQL复制层次结构，不支持共主场景，因此每个碎片只有一个主，碎片中的所有其他MySQL实例都应该从中复制。至于主节点是谁，该信息存储在拓扑服务器中。然而，对于Orchestrator，没有存储所需拓扑的中心位置，它必须根据当前的拓扑配置以及用户可能进行的任何更改来推断。换言之，VTOrc的拓扑发现和维护在本质上是声明性的，而Orchestrator的工作方式更为迫切。
同步
正如拓扑服务器的存在大大简化了MySQL发现一样，它也有助于同步。
在维护和尝试修复MySQL拓扑时，必须确保只有一个参与者试图更改拓扑，否则，事情可能会很快出错。例如，假设您有一个正在运行的集群，其主集群发生故障，并且您有多个编排器正在运行。如果两个协调器决定升级不同的主节点，那么可能会导致拓扑配置损坏，其中一些副本指向一个实例，其他副本指向另一个实例。这种状态很可能导致大脑分裂，并可能导致严重头痛。
为了防止不同的编排器节点相互干扰，一个可能的解决方案是只让一个编排器维护集群。但这是不可行的，因为与任何其他应用程序一样，编排器也容易出现故障，其中一些故障超出了它们的控制范围，例如从Kubernetes环境中的节点中被逐出，分配给它的CPU耗尽等。因此，要获得高可用性，您需要为每个集群部署多个编排器节点。
Orchestrator提供了两种提供高可用性的方法，第一种使用一致性算法Raft，另一种使用Orchestraor节点的共享备份存储。
另一方面，VTOrc依赖于现有的碎片锁定功能，Vitess将其用于不同参与者之间的同步。由于拓扑服务器是可靠的键值存储库，在幕后运行一些一致的算法，因此VTOrc可以依赖它们实现仅允许唯一参与者获取碎片锁的功能，从而确保同步。这允许多个VTOrc实例监视同一集群，而不需要知道或关心其他集群的存在。
历年数据
在Vitess中，拓扑服务器负责存储持久性和持久性数据，如拓扑结构、持久性策略等。这使得VTOrc可以只存储短暂数据。它不需要在重启期间保存任何数据，这使得VTOrc成为真正的云本地组件，因为它可以随意重启，并且它的数据可以从拓扑服务器重新填充。
用户界面
Orchestrator附带了一个吸引人的用户界面，它是一个已经令人印象深刻的工具的最后一部分。它允许用户查看当前的拓扑结构，调查所有MySQL节点的设置，甚至从UI更改它们！
然而，在Vites中，用户界面不仅仅是关于运行的MySQL实例，还应该包含其他Vites组件，如vtplates和vtgates。它应该允许用户查看他们当前的Vitess配置，如VSchema，还应该允许他们无缝地更改它。这里还有另一个Vites组件来帮助我们，VTAdmin。它是Vites提供的管理工具，提供API和web界面。该团队正在努力将VTOrc UI提供的所有数据和功能（继承自Orchestrator）合并到VTAdmin中，此时VTOrc的独立UI将被弃用并删除。
清理和易用性
Vitess中内置的协调器集成很麻烦，过去曾导致错误。使VTOrc成为一个本地Vitess组件，它可以感知其他Vitess部件，从而使我们不再依赖脆弱的集成。它还提供了清理不再需要的代码的机会。例如，VTTablet能够从以前的备份中进行备份或恢复。随着Vites Orchestrator的集成，VTTablet在开始备份之前需要进入维护模式。这是必需的，因为在进行备份时复制已停止，我们不希望Orchestrator修复它。这意味着VTTablets必须知道至少一个编排器节点才能请求维护模式。另一方面，VTOrc可以访问VTTablet元数据以及MySQL实例，这允许它推断VTTablet正在进行备份，如果没有VTTablet的明确操作，则不应修复其复制。
未来范围
与Orchestrator相比，VTOrc在失败场景中有多种超越的可能性。VTOrc还可以处理与VTTablet相关的故障，而不仅仅是MySQL实例。它可以订阅VTTablet健康检查以完成相同的任务。可能性是无穷的，真正令人兴奋。
随着VTOrc即将上市，这是您尝试它的最佳时机。如果您这样做，请通过GitHub或Slack向我们提供您的体验反馈。
原文标题：OrchestratorVTOrc: Vitess-native Orchestrator
原文作者：Manan Gupta
原文链接：https://vitess.io/blog/2022-09-21-vtorc-vitess-native-orchestrator/
