Secondary节点可生成全量报表，但需满足状态为SECONDARY且启用读操作（如readPreference=secondary），否则默认路由至PRIMARY加重主节点压力；报表卡顿常因oplog单线程回放导致同步延迟，引发中间状态读取、内存排序超限或游标失效；应通过时间戳快照对齐、避开同步高峰期、强制索引覆盖及设置hidden/priority0节点来保障报表稳定性与隔离性。
Secondary节点能否直接用于生成全量报表
可以，但必须满足两个前提：节点状态是 SECONDARY 且已开启读操作（readPreference=secondary 或显式设置 rs.secondaryOk()），否则默认只允许在 PRIMARY 上读写。MongoDB 不会阻止你在 Secondary 上执行 db.collection.find()，但若未正确配置读偏好，驱动或 shell 可能自动路由到 Primary，导致报表任务意外加重主节点压力。
为什么报表查询常卡在 large sort 或 cursor timeout
Secondary 节点的 oplog 回放是单线程串行执行的，当主节点有持续高并发写入时，Secondary 可能存在几秒到几十秒的同步延迟（可通过 db.printSlaveReplicationInfo() 查看 syncedTo 时间戳与当前时间差）。此时若报表查询扫描全集合（如 db.orders.aggregate([{$group: {_id: null, total: {$sum: "$amount"}}}])），而数据尚未完全回放完成，就可能：
- 读到部分中间状态（例如某笔订单已插入但关联更新未完成）
- 触发 collection scan + in-memory sort，超出 maxTimeMS 或 sort buffer 限制
- 遭遇 cursor 自动失效（因底层数据块被 oplog 回放过程修改）
如何让报表结果稳定、可重现
关键不是“避免延迟”，而是“控制延迟可见性”。推荐做法：
- 用 oplog 时间戳对齐快照：在 Primary 上执行 db.runCommand({getLastError:1, w: "majority"}) 后记录返回的 lastOp.ts，再在 Secondary 上用 db.adminCommand({setSecondaryOk: true}); db.getMongo().setReadPref("secondary"); 并附加 readConcern: {level: "snapshot", atClusterTime: Timestamp(...)}（需 MongoDB ≥4.0 + replica set 升级为 featureCompatibilityVersion 4.0）
- 避开增量同步高峰期：通过监控 local.oplog.rs 的 count() 增速和 first/last event time 差值，识别同步追赶窗口，在此期间暂停非实时报表
- 强制使用索引覆盖：报表聚合务必包含 {$match: {status: "done"}} 等可走索引的前置条件，避免全表扫描触发同步冲突
要不要把报表节点设为 hidden 或 priority 0
要，尤其在多数据中心或混合负载场景下：
- 设置 hidden: true 和 priority: 0 可防止该节点参与选举，避免因报表负载抖动导致意外触发故障转移
- 隐藏节点仍会同步 oplog，但不会出现在客户端发现列表中，需显式连接其 IP+端口才能访问，天然隔离报表流量
- 注意：hidden 节点不能设为 arbiter，因为 arbiter 不同步数据，无法支撑报表需求
真正容易被忽略的是：Secondary 上的 readConcern: "majority" 在多数写确认未完成时会阻塞查询，而报表通常不需要强一致性——用 readConcern: "available" 更合适，它允许读取已写入磁盘但尚未被多数节点确认的数据，既降低延迟又不破坏最终一致性。
