可以参考下历史的帖子。https://community.intersystems.com/post/backup-strategy-%E5%8F%8C%E6%9C%...

如果是我,会选择方案1,原因:既然 intersystems 提供了完整的 mirror 高可用方案,就没必要再和第三方的方案掺和在一起,凭空增加了问题排错的复杂度。如果真出现了服务中断,这个时候要第一要务是尽快做出正确的决策,以便尽快恢复服务。架构的复杂性会给自己造成很多不必要的麻烦以及决策上的复杂性 (个人建议,仅供参考。)

我们的 mirror 应该不是同步的吧,我之前做过测试,因为更新某些配置的原因,我直接 shutdown standby member,然后重启 standby,在这个过程中,没有收到 “卡住” 的报警。因为我们的 API 都有实时监控,外部调用方也有很多 API 监控,8s 的卡顿绝对会触发一堆警报的,实际上这个过程我们没收到任何报警 laugh

ps. 我们 API 的 QPS 其实不低的。

不大清楚 2015.1 的机制,我们用的 2019.1。

在2019.1版本下,备库离线不会对主库造成任何影响,更不会带来应用卡住。如果在默认的时间(8s)内主库没有得到从库的ACK,另外一台会 force down,同时停止传输 mirror journal,恢复之后两边数据会追平,不用担心。