PostgreSQL MCP 服务器在故障转移期间可能保持可用，但仍会返回错误的答案。
连接重试指向了一个副本节点。
该副本节点的数据存在滞后。
一次对话将故障转移前的结果与故障转移后的后续操作结合在一起。
每次查询都成功了，因此最终答案看起来是完整的。
在生产环境部署之前，为每个工作流定义一致性契约：
- 最终一致性，并明确披露允许的滞后预算
- 在一次对话内保持单调性
- 读己之所写
- 跨多个查询的时间点一致性
- 仅主节点读取
然后，将来源身份、模式版本、快照标记、观察时间和新鲜度作为实质性结果的一部分。
测试内容不应仅限于主从切换：
- 空闲的连接池连接
- 活跃的事务
- 预编译语句和 DNS 缓存
- 被中断的多查询应答
- 有限制的重试机制
- 对话连续性
- 模式和策略版本
- 暂停的重放与追赶过程
- 故障恢复（切回主节点）
切勿将旧主节点的部分行与新主节点的行拼接在一起。如果答案无法证明处于同一个一致性边界内，则丢弃部分结果，并返回一个结构化的、可重试的失败响应。
可用性是一种传输层属性。
可信的答案需要数据契约来保障。
完整测试指南：用于 Postgres 的 MCP 服务器：测试故障转移的一致性，而不仅仅是可用性
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
