○ 高性能模式：principal 与 mirror 之间数据异步传输，principal 上的事务提交无需等待 mirror 的响应，principal 宕机后，存在数据更新丢失的可能，不支持自动故障转移，可以通过强制服务的方式使得 mirror 提供服务。适合对数据可靠性要求不高，性能要求较高的业务场景，与 MySQL 的异步复制模式，Oracle DataGuard 最大性能模式相近；
○ 不带故障转移的高安全模式：principal 上所有的事务提交，都必须要确认该事务涉及的事务日志均已经传送到的 mirror 上，并写入 mirror 的重做队列中，持久化（是否持久化到外存设备还与 windows 操作系统写入缓存策略相关），mirror 返回确认后，才可提交，可以实现 principal 宕机下数据“零”丢失，不支持自动故障转移，可以通过手动转移或者强制服务方式使得 mirror 提供服务。与 MySQL 5.7 Loss-less replication、Oracle DataGuard 最大可用模式相近；
○ 带故障转移的高安全模式：与不带故障转移的高安全模式相比，增加了 witness (见证服务器)，可以实现自动的故障转移，通过 witness，可以确保只有一个节点成为 principal，对外提供服务，实际上 witness 最重要的一个作用就是选主；
故障转移
镜像集群故障转移最复杂场景就是带见证服务器的支持自动故障转移的高安全模式，所以我们重点讨论该模式下的故障处理流程。
初始状态下，witness、principal 和 mirror 三个节点两两之间均保持长连接会话，现在讨论其中一方连接中断的情况：
Principal 与 witness 连接中断：
此时 witness 与 mirror 连接正常，触发自动故障恢复流程，principal 丢失 witness 连接会话，如果 principal 仍在运行状态，则将状态标记为 disconnected，表示失去与 mirror 连接，切断所有客户端连接，停止读写服务，等待故障切换。为了防止网络抖动引起不必要的切换，会话超时默认时间为 10秒；witness 和 mirror 将 principal 标记为不可用，等待 mirror 上的重做队列中的事务日志回放（roll forward）完成后，mirror 成为新的 principal，开始对外提供读写服务。