PlanetScale 快速且可靠。得益于我们的 shared nothing 架构，我们能够利用本地存储而非网络附加存储，从而在云端实现最佳速度。我们的容错能力建立在易于理解的原则、流程和架构之上，但要将其做好则需要艰苦细致的工作。

我们已经多次讨论过我们的速度。现在让我们来谈谈为什么我们是可靠的。

原则

我们的原则既不新颖也不激进。你可能会觉得它们显而易见。即便如此，它们是我们容错能力的基石。我们添加的每一项能力，以及我们做出的每一项优化，都受这些原则约束或源于这些原则。

• 系统由尽可能在物理和逻辑上独立的部件构成。

• 一个部件的故障不会级联导致独立部件的故障。

• 关键路径上的部件具有尽可能少的依赖。

• 每个部件被复制多份，因此如果一个部件发生故障，其副本可以继续完成其工作。

• 每个部件的副本之间彼此隔离。

• 当某些东西发生故障时，使用最后已知的良好状态继续运行。

• 超额配置，以便故障部件的工作可以由其副本吸收。

架构

我们的架构源于上述原则。

• 提供数据库管理功能。数据库创建、计费等。

• 由冗余部件组成，分布在多个云可用区。

• 不如数据平面关键，因此具有更多依赖。

• 例如，使用一个 PlanetScale 数据库来存储客户和数据库元数据。

• 存储数据库数据并处理客户应用程序查询。

• 由查询路由层和数据库集群组成。

• 每个部分都具备区域级和可用区级的冗余与隔离。

• 最关键的面，依赖项比控制面更少。

• 不依赖于控制面。

• 由一个主实例和至少两个副本组成。

• 每个实例由一台 VM 和位于数据面的存储组成。

• 实例均匀分布在三个可用区。

• 当主实例发生故障时，自动故障转移到健康的副本。

• 客户可以选择在只读区域运行副本。

• 企业客户可以选择将只读区域提升为主实例。

• 极其关键。依赖项极少。

流程

在此架构中，我们应用了一系列流程来增强系统的整体容错能力。

始终在进行故障转移

• 具备非常成熟的从故障数据库主实例故障转移到健康副本的能力。

• 每周在每次发布变更时，对每个客户数据库执行此能力演练。

• 在硬件故障或网络故障的情况下——这在云端运行的大型系统中相当常见——我们会自动且积极地执行故障转移。

• 查询缓冲可最小化或消除故障转移期间的中断。

同步复制

• MySQL 半同步复制，Postgres 同步提交。

• 在主实例向客户端发送确认之前，提交已持久化存储在至少一个副本上。

• 这使我们能够将副本视为潜在的主实例，并在需要时立即故障转移到它们。

渐进式交付

• 数据面变更逐步发布到关键程度递增的环境中。

• 数据库集群配置和二进制变更通过功能标志逐个数据库发布

• 发布通道允许我们先将变更发布到开发分支，并等待一周或更长时间后再将相同的变更发布到生产分支

• 最小化我们自身错误对客户的影响。

故障模式

遵循上述原则、架构和流程如何使我们能够容忍各种故障模式。

非查询路径故障

• 由于我们的查询路径依赖极少，查询路径之外的故障不会影响客户的应用查询。

• 例如，假设我们的某个云提供商的 Docker（容器化平台） 容器化平台注册表服务发生故障，可能会影响我们创建新数据库实例的能力，但不会影响现有实例提供查询或存储数据的能力。

• 同样，我们的控制平面发生故障，甚至是完全故障，会影响客户更改其数据库集群设置的能力，但不会影响该集群的查询服务。

云提供商故障

我们运行在 AWS 和 GCP 上，这些平台可能并且确实会以多种不同方式发生故障。

实例

• 如果故障影响主数据库实例，我们会立即故障转移到副本。

• 如果块存储数据库实例的虚拟机发生故障，弹性卷会从该虚拟机分离并重新挂载到新的健康虚拟机上。

• 如果 PlanetScale Metal 数据库实例的虚拟机发生故障，我们会使用新的虚拟机和本地 NVMe 驱动器快速创建一个替代实例，并在替代实例健康后销毁故障实例。

• 块存储和 Metal 集群的存储故障处理方式大致相同：我们启动一个替代数据库实例，并缩减不健康实例。

可用区故障

• 与实例级故障类似，如果主数据库实例所在的可用区发生故障，我们会立即故障转移到健康可用区中的副本。

• 我们的查询路由层通过将流量转移到健康可用区中的实例来应对可用区故障。

区域故障

• 如果整个区域宕机，该区域中运行的数据库集群也会宕机。

• 但是，在其他区域运行的数据库集群不受影响。

• 企业客户可以主动故障转移到其只读区域之一。

PlanetScale 引起的故障

• Vitess 或 PlanetScale Kubernetes（容器编排平台） 容器编排平台 operator 中的 bug 很少影响超过 1-2 个客户，这得益于我们广泛使用功能标志来推出变更。

• 由基础设施变更（如 Kubernetes 升级）引起的故障可能影响更大，但由于我们严格的测试和逐步推出方式，这种情况很少发生。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：PlanetScale Blog

原创地址：https://planetscale.com/blog/the-principles-of-extreme-fault-tolerance