FoundationDB

让配置与数据各自保持连续

运维人员提交完整的集群配置，说明节点、持久卷、进程和协调节点之间的关系。Controller 控制器把期望配置保存在被管数据库之外，因此数据库暂时不可用时，配置查询和管理仍有独立保存的依据。

所有节点使用同一份只读运行镜像。节点根据连接控制器时实际使用的本地地址取得分配，核对机器与卷身份后启动数据库进程。镜像包含程序与连接材料；具体分配、数据和可写状态在运行时分别取得。

首次建立集群与普通重启走不同路径

首次建立集群，需要完整的集群声明、明确的节点与设备归属，以及属于该集群的初始连接材料。控制端保存声明的位置独立于所管理的数据库，节点再按当前分配取得运行要求。

新卷初始化是一项单独授权的维护操作：先停用目标节点，排除旧写入者，再处理获准设备。普通重启则使用原有卷和数据库已经维护的连接文件；不能因为连接失败、文件缺失或启动受阻，就自动重新播种连接文件或重置数据。

1. 保存完整期望

   提交集群、节点、卷、进程与协调节点的明确关系，核对当前声明已经保存。

2. 建立或核对卷归属

   新卷走明确初始化；已有卷走身份核对与复用。变更归属前先终止旧写入。

3. 观察节点，再读数据库

   核对实际进程与监听，再使用数据库接口读回独立预期的数据。控制配置与数据结果分别成立。

先明确操作，再触碰磁盘

初始化新卷需要明确授权：配置中须先停用目标节点，操作绑定其中的确切设备，并允许清除该设备上未标记的内容。控制卷先写入获准的集群连接文件，确认保存完成后才写入归属标记。

普通启动只复用身份匹配的卷，保留进程目录与 FoundationDB 维护的连接文件。标记缺失、身份冲突或已有连接文件损坏都会阻止启动。操作者还需独立排除通过设备别名或旧主机继续写入的进程；一个匹配标记不能证明这些条件。

分别观察配置记录与运行效果

配置写入成功表示期望已经保存。节点随后检查设备、内存和运行条件，应用变更，并报告期望配置与实际生效配置。只有所有声明进程的程序、参数、数据目录与监听端口均被确认，整份配置才可标为运行。

不变的配置不会反复重写文件或重启进程。安全的参数调整可以只替换相关进程。停用或明确撤销分配时，节点等待进程、输入输出和挂载结束后报告停止；暂时读不到控制器则保留已经获准的运行配置，冷启动仍需取得当前分配。

把维护落实到具体进程

替换协调节点地址时，先保留旧端点并加入继任进程，确认旧协调节点的多数与全部新节点可达，再执行数据库交接，并更新供新客户端首次连接的种子文件。确认交接后才可移除旧端点。数据库交接与种子更新分别报告结果。

移除承载数据的进程前，先按选定端点让 FoundationDB 迁出其数据，也就是排空，并核对完成情况。这种维护保留无关进程和既有目录。保留磁盘的普通重启无需排空；变更设备归属或数据目录则要先停用，并独立确认旧写入者已结束。

把异常定位到配置、节点或数据库

运维调查先问三个问题：控制端现在要求什么，本机实际应用了什么，数据库当前能读写什么。三者的时间和来源不同。期望写入成功不等于节点已应用；monitor 进程存在不等于全部数据库进程按所需参数运行；数据库样本缺失也不能直接解释为服务停止。

控制端暂时不可读取时，已经运行的节点保留获准配置；刚启动的节点仍须取得当前分配。若只有一项进程变更，应围绕该进程观察替换与必要排空，保留无关进程和既有数据目录，避免把局部维护扩大为重建集群。

• 可以确认：当前报告与实际进程相符

  完整程序、参数、数据目录和监听端口均匹配，才支持本机已应用该配置的结论。

• 不能推断：卷标记匹配即没有其他写入者

  旧主机、设备别名或未退出进程仍需独立排除；归属标记不能替代这一前提。

• 继续核对：数据库采样不可用

  保留采样失败的来源与时间，再通过所需的数据库接口核对业务结果，不把缺失填成零或停机。

让状态和验证保留原本含义

数据库采样与管理请求异步运行。可用性、复制、磁盘空间、迁移积压和事务探测分别保留来源与单位；采集失败不会被写成数据库不可用，缺失字段也不会补成零。节点运行报告与数据库健康是两种独立观察。

设计中的验证重点包括：旧卷重开后保持原数据、格式化只作用于授权目标、只更新选定进程而不影响其他进程，以及结果丢失或控制器中断时继续处理未完成工作。证据分别来自数据读回、进程和资源观察，不能用单一成功回执替代。