对于集群同步负载的监控，除了监控cpu/io/内存等服务器指标之外，还可以通过监控备机重演任务队列的堆积情况来进行判别。在达梦的重演队列上，存在两个参数REDOS_BUF_SIZE 和REDOS_BUF_NUM。其中REDOS_BUF_SIZE 为控制重演日志的内存堆积，REDOS_BUF_NUM 为控制冲日志日志个数，两者同时生效，满足其一将会触发重演延迟处理，也就是说备机重演负载已经到达上限。在实际的观测中由于日志包存在合并的情况，REDOS_BUF_NUM 未达到上限的时候，REDOS_BUF_SIZE 已经达到上限了，然后触发了延迟处理。
因此我们通过在监控控cpu/io/内存等服务器指标之外，通过监控重演任务队列的堆积情况来判定负载

●触发延迟处理的日志打印情况，此时可以看到REDOS_BUF_SIZE 已经接近1024MB ,此时的堆积日志数（ 2173）才到达参数一半左右

2024-10-11 04:09:44.512 [INFO] database P0001301800 T0000000000001301832  checkpoint end, 480 pages flushed, used_space[118645760], free_space[4176313344].
2024-10-11 04:09:45.590 [INFO] database P0001301800 T0000000000001301841  rapply_redos_wait, redos_buf_used = 1073858560, redos_buf_num = 2176, total_wait_cnt = 37700, need wait the existing tasks to be applied firstly...
2024-10-11 04:09:46.564 [INFO] database P0001301800 T0000000000001301842  rapply_redos_wait, redos_buf_used = 1073859072, redos_buf_num = 2176, total_wait_cnt = 37710, need wait the existing tasks to be applied firstly...
2024-10-11 04:09:47.477 [INFO] database P0001301800 T0000000000001301840  rapply_redos_wait, redos_buf_used = 1074099200, redos_buf_num = 2173, total_wait_cnt = 37720, need wait the existing tasks to be applied firstly...
2024-10-11 04:09:48.488 [INFO] database P0001301800 T0000000000001301842  rapply_redos_wait, redos_buf_used = 1074098688, redos_buf_num = 2173, total_wait_cnt = 37730, need wait the existing tasks to be applied firstly...

工具

通过查询v$rapply_sys视图中的task_num 和 task_num_used 来监控

监控手段

●假定主备机环境硬件配置相同，那么可以通过监控task_mem_used与redos_buf_size、task_num与REDOS_BUF_NUM 的比值来监控重演任务队列，

监控规则

根据以上的的监控手段后，监控延迟的规则就比较清晰了
1.监控日志重演负载，如果持续大于300s（5min）则触发告警

select sysdate,*,case when TSK_MEM_USED>REDOS_BUF_SIZE*0.8 then 1 else 0 end warn from
 (select (select TASK_NUM||' | '||TASK_MEM_USED from v$rapply_sys) tsk,(select TSK_MEM_USED from v$rapply_stat) TSK_MEM_USED,
(select PARA_VALUE from v$dm_ini where para_name='REDOS_BUF_SIZE')*1024*1024 REDOS_BUF_SIZE from dual);

重演负载告警模拟处理

告警描述: 备机重演高负载超过5min且持续2min ，且未自动恢复
业务影响：1）业务整体响应缓慢 2）业务部分模块响应缓慢 3）业务方暂无反馈，但备机重演负载不降低、主备延迟增加
预期目标： 1）定位备机重演负载高的原因 2）降低业务响应时间 3）主备延迟缩短，并预估达到一致的时间
可能原因：1）业务层有大量的数据持续进行写入 2）主备机写入效率不同，备机略差于主机 3）主备延迟大存在大量待重演任务
可采取的处理方式：
1）排除网络延迟，提高备机硬件资源提高重演效率
2）将备机提出集群，（这种情况下如果主机归档被清理，那么备机加入集群后无法进行历史数据恢复）

 ## 前台启动对应集群的监视器
 ./dmmoitor dmmonitor.ini 
 ## 使用SSYDBA用户进行登录
 login
 ##将制定备库实例分离出守护集群
 detach database 备库实例名
 ##待写入量降低后，将分离出的实例重新加入守护集群
 attach database 备库实例名

3） 3）在硬件资源未满负载情况下，可以开启放大日志堆积量，避免备机拖累主库同时可以开启备机并行重演 （开启备机重演后备机查询为脏读对备机查询会带来性能损耗，因此同时限制用户对备机进行查询）

## 使用SSYDBA用户进行在集群所有节点执行
##放大redo日志堆积参数
 sp_set_para_value(2,'redo_buf_size',4096);-- 单位MB
 sp_set_para_value(2,'redo_buf_num',0);
##开启备机重演
 sp_set_para_value(2,'REDOS_PARALLEL_NUM',8);
 sp_set_para_value(2,'REDOS_ENABLE_SELECT',0);
 ## 注：重启数据库后生效