【FoundationDB 内核】故障恢复：角色招募与恢复 epoch
内容提要
本文讨论了FoundationDB的故障恢复机制，强调将故障视为常态并快速恢复。通过角色招募、epoch管理和版本控制，确保事务系统的高可用性。恢复过程包括锁定状态、停止旧角色、招募新角色，并计算恢复版本（RV）和上一epoch版本（PEV）。恢复期间写路径不可用，但读路径可访问已有数据。整体目标是缩短恢复时间，提高系统稳定性。
关键要点
-
将故障视为常态，快速恢复是FoundationDB的设计原则。
-
通过角色招募、epoch管理和版本控制，确保事务系统的高可用性。
-
恢复过程包括锁定状态、停止旧角色、招募新角色，并计算恢复版本（RV）和上一epoch版本（PEV）。
-
恢复期间写路径不可用，但读路径可访问已有数据。
-
Proxy和Resolver无状态，易于替换；LogServer的恢复核心在于用KCV/DV界定已确认提交与可丢弃后缀。
-
写暂停是恢复窗口的硬边界，读边界取决于版本获取与Storage可见性。
-
MTTR主要由控制面与日志终点发现决定，而不是由数据体积上的全量重放决定。
延伸解读
故障恢复的设计原则
FoundationDB将故障视为常态，强调快速恢复的重要性。这种设计理念使得系统在面对故障时能够迅速采取措施，减少停机时间。通过主动关闭故障角色并招募新角色，系统能够在最短时间内恢复到可用状态，确保高可用性。
恢复过程中的读写路径
在恢复过程中，写路径会暂时不可用，客户端可能会遇到提交超时等问题。然而，读路径仍然可以访问已有数据。这种设计允许在恢复期间继续提供部分服务，降低了对用户的影响。用户应了解这一点，以便在故障发生时采取适当的应对措施。
Epoch管理的重要性
每个epoch代表一代事务管理系统，确保在同一时刻只有一个Sequencer在推进恢复。这种管理方式避免了并行恢复带来的数据一致性问题，确保系统在故障恢复时的稳定性和可靠性。理解epoch的概念有助于更好地把握FoundationDB的故障恢复机制。
延伸问答
FoundationDB的故障恢复机制是如何设计的？
FoundationDB将故障视为常态，设计原则是快速恢复，主要通过角色招募、epoch管理和版本控制来确保高可用性。
在FoundationDB的恢复过程中，写路径和读路径有什么不同？
恢复期间写路径不可用，客户端会遇到提交超时等错误，而读路径可以访问已有数据，不受影响。
什么是恢复版本（RV）和上一epoch版本（PEV），它们在恢复中有什么作用？
恢复版本（RV）是指可以丢弃的未确认数据的下界，而上一epoch版本（PEV）是已确认提交的上界，二者用于隔离旧日志和确定恢复点。
FoundationDB如何处理角色的招募和恢复？
当检测到角色失败时，ClusterController会招募新Sequencer，随后新Sequencer会锁定状态、停止旧角色并招募新角色。
在FoundationDB的恢复过程中，如何确保事务系统的高可用性？
通过快速锁定状态、停止旧角色、招募新角色以及计算RV和PEV，FoundationDB确保事务系统的高可用性。
恢复窗口内客户端应遵循哪些契约？
客户端应将提交失败视为未提交，依赖官方重试机制，而不是假定部分提交已成功。
