转到文章 Weidong Li · 八月 12, 2022 正式环境也是 mirror 嘛？能简单描述下测试环境 mirror 的搭建过程吗？我以前也做过类似的操作。假设 mirror 的两个成员分别是 A 和 B，正式环境的备份是 bak1，你是用 bak1 分别在 A 和 B 上还原，然后再建立 mirror，添加 mirror DB 的，还是将 bak1 在 A 上还原，然后建立 mirror，接着在 A 上面备份，生成 bak2，然后在 B 上面用 bak2 还原，然后再添加 mirror DB 的？另外，可以看下日志是否有报错？
转到文章 Weidong Li · 三月 15, 2022 可以参考下历史的帖子。https://community.intersystems.com/post/backup-strategy-%E5%8F%8C%E6%9C%... 如果是我，会选择方案1，原因：既然 intersystems 提供了完整的 mirror 高可用方案，就没必要再和第三方的方案掺和在一起，凭空增加了问题排错的复杂度。如果真出现了服务中断，这个时候要第一要务是尽快做出正确的决策，以便尽快恢复服务。架构的复杂性会给自己造成很多不必要的麻烦以及决策上的复杂性 （个人建议，仅供参考。）
转到文章 Weidong Li · 三月 15, 2022 我们的 mirror 应该不是同步的吧，我之前做过测试，因为更新某些配置的原因，我直接 shutdown standby member，然后重启 standby，在这个过程中，没有收到 “卡住” 的报警。因为我们的 API 都有实时监控，外部调用方也有很多 API 监控，8s 的卡顿绝对会触发一堆警报的，实际上这个过程我们没收到任何报警 ps. 我们 API 的 QPS 其实不低的。
转到文章 Weidong Li · 三月 11, 2022 不大清楚 2015.1 的机制，我们用的 2019.1。 在2019.1版本下，备库离线不会对主库造成任何影响，更不会带来应用卡住。如果在默认的时间（8s）内主库没有得到从库的ACK，另外一台会 force down，同时停止传输 mirror journal，恢复之后两边数据会追平，不用担心。
