全文共 3480 字，阅读约需 6 分钟

如果你正在用 seekdb 构建 AI 应用，一定有过这个担心：单点故障怎么办？

seekdb 1.2.0 的正式发布，解决了这个困扰。

这个版本带来了 seekdb 的首个高可用方案——主备库异步复制架构。除此之外，还有整库级别快照克隆的 Fork Database，以及给数据加上 Git 能力的 Diff & Merge。

这三个能力各自解决不同的问题：主备库解决可用性问题，业务不能因为一台机器挂了就全面瘫痪；Fork Database 解决效率问题，AI 场景下的数据版本管理不能还停留在 mysqldump 的速度；Diff & Merge 解决可控性问题，数据变更不能是个黑盒，改了什么、能不能回滚，开发者要心里有数。

其中主备库是大家最关心的，也是这个版本分量最重的部分，先从它说起。

主备库：首个高可用方案

单点故障的痛，用过单机数据库的人都懂。seekdb 1.2.0 给出了解决方案：主备库异步复制架构。

| 架构设计：优雅、实用、可演进

seekdb 的主备库方案，采用的是最大性能模式的异步复制架构。这个选择是经过深思熟虑的。

同步复制虽然能保证数据零丢失，但代价是每次写入都要等备库确认，性能损耗明显。对于 AI 应用场景来说，很多时候写入的是向量数据、知识库文档、对话记录，这些数据的实时一致性要求并没有金融交易那么高。异步复制在性能和可靠性之间取得了一个务实的平衡。

整个架构基于 gRPC 框架进行 RPC 通信，这是一个成熟、高效、跨语言的选择。主库在运行过程中不断产生增量日志，备库通过网络拉取这些日志并回放，从而保持与主库的数据同步。

架构图大概是这样的：主库在左边，持续接收业务读写请求；备库在右边，通过 gRPC 连接从主库拉取日志；如果你需要更高的容灾能力，还可以在备库后面再挂一个备库，形成级联架构。

这个设计有几个值得说的点。

第一是备库异步搭建。你可以在任意时刻搭建备库，不需要停止主库服务。这意味着什么？意味着你可以在业务高峰期之后，悄悄加一个备库，而不用协调什么“维护窗口”。搭建过程也很优雅：先拷贝一份基线数据，然后同步增量日志，整个过程对主库的影响微乎其微。

第二是松耦合设计。备库知道主库在哪，会主动去拉日志；但主库不需要知道备库的存在，它只管自己的事情。这个设计带来两个直接的好处：主库性能完全不受备库数量的影响，而且天然支持一主多备的拓扑。你想加几个备库都行，主库根本不关心。

第三是级联备库支持。如果你的备库还想再有备库呢？没问题，seekdb 支持主库到备库 1 再到备库 2 的级联架构。这在跨机房、跨地域容灾场景下特别有用。

| 两种切换模式：有损和无损，各有各的用处

高可用架构的核心价值，在于当主库出问题时，能够快速切换到备库继续提供服务。seekdb 提供了两种切换模式，分别应对不同的场景。

Switchover，无损切换。这是在主库还活着的时候执行的切换。典型场景是计划内的维护：你要升级主库的版本，或者主库所在的机器需要打补丁。这时候主库还在正常运行，你执行 switchover 命令，系统会先检查主备之间的日志是否完全同步，确认没有数据丢失后，再执行角色互换。整个过程数据零丢失，业务感知到的只是一个短暂的连接中断。

更贴心的是，seekdb 还提供了 switchover verify 命令，让你可以在真正切换之前先做一次“模拟演练”。它会检查所有切换条件是否满足，但不实际执行变更。这对于生产环境来说非常重要——你可以提前发现潜在问题，而不是在真正切换时手忙脚乱。

Failover，有损切换。这是在主库已经挂掉的时候执行的紧急切换。服务器宕机了、网络断了、进程崩溃了，主库已经无法提供服务，这时候备库需要紧急接管。Failover 不会去检查主备日志是否完全同步，因为主库已经联系不上了，它会直接把备库提升为新的主库。

有损切换可能意味着少量数据丢失——那些已经在主库提交但还没来得及同步到备库的事务。但对于大多数场景来说，丢失几秒钟的数据，总比整个业务中断几个小时要强得多。这是一个务实的权衡。

说到这里，你可能会问：备库除了容灾，还能干什么？能不能用来分担查询压力？

能，而且这是备库的重要价值之一。备库提供只读服务，你可以把一些报表查询、分析任务路由到备库，减轻主库的负担。但有一点需要注意：因为是异步复制，备库的数据可能会略微滞后于主库，通常是毫秒到秒级的延迟。对于大多数查询场景，这个延迟是可以接受的；但如果你的业务对实时性要求极高，需要考虑这个因素。

那向量索引在备库上能正常查询吗？1.2.0 版本对向量索引的备库读支持还不完整，这是一个已知的限制，后续版本会优化。如果你的应用重度依赖向量查询，目前建议主要在主库上进行。

另一个常见的问题是：切换之后，应用需要改连接串吗？目前需要。切换完成后，新的主库 IP 地址变了，应用需要更新连接配置。在实际操作中，你可以通过 DNS、VIP、或者连接代理来简化这个过程，后续版本也会考虑提供更自动化的方案。

Fork Database：AI 时代的数据版本管理

如果说主备库解决的是“不能挂”的问题，Fork Database 解决的就是“不能慢”的问题。

做 AI 应用的同学应该深有体会。你在调试一个 RAG 应用，知识库里有几十万条文档，跑了一版效果不太好，想回退到之前的状态试试别的参数。传统做法是什么？要么提前做好备份，要么用 mysqldump 导出再导入。数据量稍微大一点，几个小时就过去了。

你在做 A/B 测试，需要两份完全相同的数据跑不同的算法。你在训练模型，每个实验需要独立的数据快照。你在做 AI Coding，让大模型修改数据库里的数据，但你想保留一份原始版本以防改坏了。

这些场景有一个共同点：你需要快速、低成本地创建数据的副本。

seekdb 1.1.0 版本支持了 Fork Table，能够快速克隆单张表。1.2.0 把这个能力升级到了整库级别。一条命令，整个数据库瞬间克隆，所有表、所有数据、所有关系，全部保留。

这里的“瞬间”不是夸张。Fork 操作的耗时与数据量无关，不管原库有 1GB 还是 100GB，都是秒级完成。背后的原理是 Copy-on-Write 机制：Fork 出来的目标库一开始只是指向源库数据的引用，只有当你真正写入时，才会复制被修改的那部分数据。

更妙的是库级原子快照。Fork Database 会选取一个一致性快照时刻，目标库中所有表共享这同一个快照版本。这意味着多表关联查询、外键约束，在 Fork 后仍然保持逻辑一致。你可以放心地在目标库上做任何操作，不用担心数据不一致的问题。

这个能力放在 AI 场景下特别有价值。知识库版本管理变得轻而易举，每次大的更新前 Fork 一个版本，效果不好随时回退。A/B 测试数据准备从几个小时变成几秒钟。模型训练的数据快照不再需要每次都复制一份完整数据。AI Agent 的多分支对话可以有独立的数据上下文。

同一个源库可以 Fork 多次，每次产生独立的目标库，互不影响。你可以 Fork 出 dev、test、staging 多个环境，想怎么折腾就怎么折腾，不会影响源库。

Diff & Merge：给数据加上 Git 的能力

Fork Database 让你能快速创建数据副本，但副本改完之后呢？改了什么、要不要合并回去、怎么合并？

代码世界早就有了标准答案：Git。branch、diff、merge、pull request，这套工作流开发者闭着眼睛都能用。但数据世界呢？大多数时候还是原始状态——改了什么不知道，能不能回滚不好说，想对比两个版本的差异得自己写脚本。

seekdb 1.2.0 引入了 Diff & Merge 功能，让数据也能像代码一样被管理。

工作流程很直观：先 Fork 一个副本出来，在副本上做各种修改，然后用 Diff 对比两边的差异，最后用 Merge 把改动合并回去（如果你决定要的话）。

Diff 会告诉你：新增了多少条记录，修改了多少条，删除了多少条，每一条的具体变化是什么。Merge 则支持多种策略：全量覆盖、只合并新增、只合并修改、跳过删除等等。

这套能力解决的核心问题是：让数据变更从“不可观测、难控制”变成“可观测、可控制”。

• 可观测：改了什么一目了然，不用猜，不用对比数据库导出文件。

• 可审计：所有变更都有迹可循，谁在什么时候改了什么。

• 可回滚：合并之前可以反复验证，发现问题不合并就完了。

• 可协作：多人可以在不同的 Fork 上并行工作，最后合并到一起。

对于 AI 应用来说，这个能力特别实用。RAG 知识库更新可以先在 Fork 上验证效果，好了再合并，不好就丢弃。AI Agent 不同对话分支的记忆可以独立演进，需要时再合并。数据清洗流水线可以把每个步骤作为一个分支，最终 Merge 得到干净数据。

写在最后

回到开头的问题：单点故障怎么办？

seekdb 1.2.0 给出的答案是一整套组合拳。主备库让你有了容灾能力，业务不会因为一台机器的故障而全面瘫痪。Fork Database 让数据版本管理变得轻盈，不用再为备份恢复耗费大量时间。Diff & Merge 让数据变更变得可控，改了什么、要不要回滚，心里有数。

这是 seekdb 从“开发友好”走向“生产就绪”的关键一步。

如果你正在用 seekdb 构建 AI 应用，这个版本值得认真看看。如果你还没用过，现在是一个不错的起点——它依然保持着轻量、易用的特点，pip install pyseekdb 就能在本地跑起来，但它现在也有了生产环境需要的高可用能力。

AI 原生数据库正在从“能用”走向“好用”，从“开发友好”走向“生产就绪”。