DM主备的实现原理

一：实时归档与即时规档流程图

得出如下结论：

1. 在两种方式的归档中，日志的发送成功与否对主库的影响。
2. 联机日志刷盘和规档的方式不同；
3. 实时归档因为联机日志刷盘的原因，它比起即时归档来说多了一个keep_pkg包。
4. 实时归档不等备库应用完日志，主库就可以开始下一个事务【实时主备集群的应用场景】；即时归档要等备库应用完成后日志，主库才可以开始下一个事务【读写分离集群的应用场景】。

二：事务一致模式与高性能模式

事务一致模式：主库事务提交触发 Redo 日志刷盘和即时归档，备库收到主库发送的 Redo 日志，并重演完成后再响应主库。主库收到备库响应消息后，再响应用户的提交请求。事务一致模式下，同一个事务的 SELECT 语句无论是在主库执行，还是在备库执行，查询结果都满足 READ COMMIT 隔离级要求。

高性能模式：与实时归档一样，备库收到主库发送的 Redo 日志后，马上响应主库，再启动日志重演。高性能模式下，备库与主库的数据同步存在一定延时（一般情况下延迟时间非常短暂，用户几乎感觉不到），不能严格保证事务一致性。

    事务一致模式下，主备库之间严格维护事务一致性，但主库要等备库 Redo 日志重演完成后，再响应用户的提交请求，事务提交时间会变长，存在一定的性能损失。高性能模式则通过牺牲事务一致性获得更高的性能和提升系统的吞吐量。用户应该根据实际情况，选择合适的即时归档模式。

读写分离一定要配置为 ARCH_WAIT_APPLY 配置项（默认值为 1），即事务一致模式

建议：根据读写分离特性合理地规划应用的事务逻辑，也可以获得更佳的性能：

1. 尽可能将事务规划为只读事务和纯修改事务，避免无效的备库试错。

2. 读操作尽量放在写操作之前，用备库可读的特点来分摊系统压力。

 更多学习内容参考：达梦数据库 - 新一代大型通用关系型数据库 | 达梦云适配中心 https://eco.dameng.com