单片机|GitHub生产数据库架构优化和数据迁移( 二 ) excel|操作系统|内存条

由于linter仅在开发和测试环境中启用，因此开发人员在开发过程的早期就会遇到违规错误。此外，在CI运行期间， linter确保不会意外引入新的违规行为。
linter 有一种方法可以通过使用特殊注释SQL查询来抑制异常：
/* cross-schema-domain-query-exempted */
为了更加轻松翻边的添加注释，还构建了一个ActiveRecord方法，以便更轻松：
Repository.joins(:owner).annotate(\"cross-schema-domain-query-exempted\")
# => SELECT * FROM `repositories` INNER JOIN `users` ON `users`.`id` = `repositories.owner_id` /* cross-schema-domain-query-exempted */
通过注释所有导致失败的查询，可以构建需要修改的查询积压。常用来消除豁免的几种方法有：
有时，可以通过触发单独的查询而不是连接表来轻松解决豁免问题。一个例子是使用 ActiveRecord的 preload方法而不是 includes.
另一个挑战是has_many:through导致的关系JOINs跨来自不同schema域的表。为此，开发了一个通用的解决方案， has_many有一个 disable_joins告诉 Active Record 不要做任何事情的选项JOIN跨基础表的查询。相反，它会运行多个传递主键值的查询。
在应用程序中而不是在数据库中加入数据是另一种常见的解决方案。例如，替换 INNER JOIN带有两个单独查询的语句，而是在Ruby中执行“联合”操作（例如，A.pluck(:b_id) & B.where(id: ...)）。
在某些情况下，这会带来惊人的性能提升。根据数据结构和规模， MySQL 的查询计划器有时会创建次优的查询执行计划，而应用程序端连接则具有更稳定的性能成本。
与几乎所有与可靠性和性能相关的更改一样，将它们发布在这些 Scientist 实验之后，为请求的子集执行旧的和新的实现，使能够评估每个更改对性能的影响。
事务linter除了查询，事务也是一个问题。现有的应用程序代码在编写时考虑了特定的数据库模式。 MySQL事务保证数据库内表之间的一致性。如果事务包括对将移动到单独数据库的表的查询，它将不再能够保证一致性。
为了了解需要审查的事务，还引入了事务linter 。与查询linter类似，它验证在给定事务中一起使用的所有表都属于同一schem域。
该linter在生产中运行并进行大量采样，以将性能影响降至最低。收集和分析 linting结果以了解大多数跨域事务发生的位置，使得可以决定更新某些代码路径或调整我们的数据模型。
在事务一致性保证至关重要的情况下，将数据提取到属于同一schema域的新表中。这确保它们保持在同一个数据库集群上，因此继续具有事务一致性。这通常发生在包含多态表来自不同schema域的数据的中（例如，一个reactions表存储不同功能的记录，如问题、拉取请求、讨论等）
零停机数据迁移虚拟隔离schema域已准备好物理移动到另一个数据库集群。为了动态移动表，方案中使用了两种不同的方法：Vitess和自定义write-cutover过程。
VitessVitess是云原生的MySQL代理中间件，可以用于对MySql集群进行分片和负载均衡，通过其垂直分片功能可以将生产中的多组表迁移到一起，而无需停机。

VTGate可以实时获取Vitess设置的当前状态，并通过另一个Vitess 组件VTTablet与MySQL实例对话。 Vitess的表移动功能则由VReplication提供支持，负责数据库集群之间复制数据。
通过在K8S集群中部署Vitess VTGate ，然后应用程序的数据池连接到VTGate进程，而无需直连接MySQL 。 Vitess MySQ协议，对后端应用是来说等同Mysq实例。

write-cutover过程由于Vitess的采用在2020年初仍处于探索阶段，因此先开发了一种替代方法来一次性移动大量表格。这降低了依赖单一解决方案来确保GitHub持续可用的风险。