主备集群参数学习

1 研究背景

主备集群中，主库产生的 Redo 日志需要经过 MAL 网络传输，并在备库完成接收与重演，最终影响主库事务响应、备库同步效率及系统资源消耗。因此选择以下三个参数进行研究，分析不同配置对主备集群性能的影响。

2 ARCH_WAIT_APPLY

该参数位于 dmarch.ini 中。0 表示收到马上响应（高性能模式），1 表示重演完成后响应（事务一致模式）。配置为即时归档时，缺省值为 1；配置为实时归档时，缺省值为 0。

ARCH_WAIT_APPLY=0

ARCH_WAIT_APPLY=1

实验对比 ARCH_WAIT_APPLY=0 与 ARCH_WAIT_APPLY=1（线程数 20）时，TPS 从 1188.94 下降到 1034.46，大约下降 13%；平均响应时间从 16.43 毫秒增加到 18.90 毫秒，大约增加 15%。可见该参数对主库事务响应影响明显。如果业务更加关注主库吞吐和响应速度，那么 ARCH_WAIT_APPLY=0 会更加有利。

3 REDOS_PARALLEL_NUM

该参数位于 dm.ini 中，取值范围 1~256，1 表示不开启日志并行重演，缺省为 1。监控工具可使用 top 配合 disql 查询 V$RAPPLY_SYS。

REDOS_PARALLEL_NUM=1

REDOS_PARALLEL_NUM=4

REDOS_PARALLEL_NUM=8

对比 REDOS_PARALLEL_NUM=1、4、8 三组配置（线程数 50），TASK_NUM 峰值均为偶尔 1，日志堆积均无。说明在当前 Redo 压力下，单线程已经能够实时追平，并行重演并非越大越好。随着线程数从 1 增加到 8，dmserver CPU 峰值从大约 50% 上升到 70%，而吞吐量反而从 2080 微降至 2040（几乎无变化）。
原因在于：多线程并行重演后，还需要进行按序合并、锁协调和等待，这些都会产生额外开销。如果当前 Redo 压力本身不大，增加更多线程并不能带来实际收益，反而会增加线程协调、锁竞争等额外开销，甚至放大尾部延迟（90th/95th/99th 高百分位延迟显著恶化）。因此并行度需匹配 Redo 压力。

4 MAL_COMPRESS_LEVEL

MAL 消息压缩等级，取值范围 0~10。缺省为 0，不进行压缩；1~9 表示采用 lz 算法，从 1 到 9 压缩速度依次递减、压缩率依次递增；10 表示采用 snappy 算法，压缩速度高于 lz 算法，压缩率相对低。监控工具为 ServerAgent 配合 PerfMon 插件。
MAL_COMPRESS_LEVEL=0


MAL_COMPRESS_LEVEL=1


MAL_COMPRESS_LEVEL=5


MAL_COMPRESS_LEVEL=10


从原理上来说，压缩可以减少网络传输的数据量，但压缩本身也需要消耗 CPU，本质是用 CPU 计算换取网络带宽。
从实验结果来看，开启压缩以后，网络流量确实下降了，但 TPS 也同步下降了大约 15% 到 23%，平均响应时间反而明显增加。对于小数据包，压缩带来的计算开销远大于节省的传输时间，导致平均响应时间暴涨 30%。特别是在当前测试环境网络带宽并不是瓶颈的情况下，压缩节省的网络资源价值并不高，但 CPU 计算成本却真实存在。如果网络带宽充足，没有明显网络瓶颈，可以优先考虑 MAL_COMPRESS_LEVEL=0，避免为了节省带宽额外消耗 CPU。

5 总结

把三个参数放在一起，可以形成一个比较清晰的对应关系：ARCH_WAIT_APPLY 主要影响主库事务响应，REDOS_PARALLEL_NUM 主要影响备库 Redo 重演，MAL_COMPRESS_LEVEL 主要影响主备网络通信。这三个参数分别对应主库、备库和网络三个环节。
但最终的调优思路并不是"参数越大越好"，而是要根据实际压力找到平衡点。比如：如果优先保证主库业务性能，可以考虑 ARCH_WAIT_APPLY=0；如果备库 Redo 已经能够实时追平，就没有必要盲目增加 REDOS_PARALLEL_NUM；如果网络带宽充足，则没有必要为了节省带宽增加额外的 CPU 压缩开销。
主备性能优化的核心，不是把参数调到最大，而是在一致性、重演能力、网络传输和 CPU 开销之间找到平衡。