Uber对自身的MySQL基础设施进行了重新设计，旨在提升集群的正常运行时间。他们用MySQL组复制技术取代了原有的外部故障转移机制。这一变更应用到了数千个集群中，使得故障转移所需的时间从几分钟缩短到了几秒钟，同时仍保持了数据的一致性。重新设计的过程首先是从引入共识复制机制开始的，以此来消除对外部系统的依赖；随后，这一方案通过自动化节点管理、负载均衡以及安全防护措施，在整个Uber系统中得到了全面推广，从而确保了集群的稳定运行与可靠性。
此前，Uber使用的MySQL集群采用的是单主节点、异步复制的架构。外部系统会检测到故障并自动切换到备用节点，因此故障转移所需的时间通常为几分钟。为了减少停机时间并提升系统的可靠性，Uber采用了基于Paxos协议的MySQL组复制技术。新的架构将共识机制直接集成到了数据库系统中，从而形成了由三个节点组成的MGR集群：其中一个节点负责写入操作，另外两个节点则参与共识决策过程，但不会直接接收写操作请求。这种设计确保了所有节点都能保持数据的一致性，并且在需要时可以自动选举出新的主节点。
Uber工程团队在LinkedIn上发布的一篇文章中强调：
在Uber，高可用性是绝对不可妥协的。
可扩展的读复制节点从备用节点中分发数据请求，这样就可以将读操作的扩展性与写操作的可靠性分开来处理，同时还能保持系统的容错能力。MGR系统中的流量控制机制会实时监控每个备用节点上的事务队列情况，并根据需要向主节点发送信号，让其暂停或限制写操作速度，从而防止某些节点出现数据延迟。这种机制可以有效避免复制错误，减少故障发生时的写操作延迟，同时也能阻止错误的GTIDs信息在集群外传播。
基于共识机制的MySQL集群架构（来源：Uber官方博客文章）
测试结果显示，新设计确实带来了一些权衡：与异步复制方案相比，写操作的延迟略有增加，增加了几百微秒；但在主节点发生故障时，整个系统的写入可用性时间从几分钟缩短到了不到10秒钟，这其中还包括了主节点选举和路由更新等操作所需的时间。由于本地复制节点的性能与旧架构中的节点相当，因此读操作的延迟并没有发生变化。
Uber通过使用自动化控制机制来管理集群的加入与退出过程、在拓扑结构发生变化时进行重新平衡操作。相关工作流程能够处理节点的平滑替换或非平滑替换，而诸如group_replication_unreachable_majority_timeout这样的配置设置以及单主模式能够有效防止“脑裂”现象及少数派分区的出现。当某个集群的节点数量低于法定数量时，自动化拓扑健康分析机制会动态添加新节点；而当系统中存在多余节点时，该机制也会自动删除这些节点以降低系统开销。在删除节点的过程中，下游副本会自动重新指向新的主节点，同时还可以通过设置延迟处理机制来确保外部数据的一致性。
重新平衡共识集群的工作流程（来源：Uber博客文章）
Uber的工程师们表示，大规模应用MySQL组复制机制的过程中，他们发现使用MGR插件、结合performance_schema.memory/group_replication这些工具，以及仔细处理group_replication_bootstrap_group相关配置，能够有效防止“脑裂”现象的发生。出于简化系统架构及提高运行稳定性的考虑，他们最终选择了单主模式而非多主模式——因为多主模式会增加数据冲突的风险，同时也需要更复杂的机制来确保事务处理的顺序正确性。基于共识机制的复制技术、自动化的工作流程以及可扩展的读副本机制，共同为Uber大规模部署MySQL基础设施提供了有力保障，使得系统具备高可用性、强一致性和低人工干预的需求得到满足。