揭穿关于Vitess容错能力的三个谣言
我们经常听到一些关于 Vitess 在数据可靠性和数据丢失方面能力的关注。当有人听到“基于云原生的、高可用的、运行在 Kubernetes 上的分布式数据库”时，确实听起来像是好得令人难以置信，因此我们理解初期的担忧。
虽然 Slack、Square、GitHub 和京东等知名企业早已在生产环境中运行基于 Vitess 的数据库，我们仍然会收到关于 Vitess 是否会丢失数据的问题。
今天，我们将揭穿 Vitess 的几个常见误解，并回答一些关于 Vitess 如何处理故障的疑问。
谣言1：因为 Vitess 没有使用基于共识的提交协议，如果主节点（Master）宕机，数据会丢失。
真实情况：Vitess 基于 MySQL，因此它通过 MySQL 的无损半同步复制功能解决了这一潜在问题。简单来说，在事务被认为已经提交之前，主节点必须首先确认至少有一个副本（Replica）已收到该事务。
谣言2：即使数据已经保存下来，当 Vitess 主节点宕机时，无法自动执行自我恢复。
真实情况：虽然默认配置下这是事实，但通常情况下 MySQL（包括 Vitess）部署时都会配合使用 Orchestrator，在主节点失败时自动重新选主（Reparent）。更值得注意的是，PlanetScale 的专有 Vitess Operator 能够自动检测主节点故障并完成重新选主的操作。
谣言3：配置 Vitess 的自我恢复机制需要很多额外步骤。
真实情况：这也不是真的！Vitess 的控制面板包含诸如 “PlannedReparentShard” 和 “EmergencyReparentShard” 等现成可用的工作流。您的编排工具只需要检测到故障，发送重新选主的请求，而剩下的部分 Vitess 会为您处理。
在网络分区的情况下确实需要一些手动干预，这是 Vitess 为了优化极低的 p99 延迟和高性能进行的权衡所带来的结果。
关注公众号：程序新视界，一个让你软实力、硬技术同步提升的平台
除非注明，否则均为程序新视界原创文章，转载必须以链接形式标明本文链接
