停止写入后，能否在 MongoDB 副本集所有成员上同时执行 compact？

能否同时执行？

可以分别向多个成员发起 compact，但“没有写入”并不意味着所有成员同时执行就安全。生产环境更适合逐个成员执行，保留能够正常承担读取和故障切换的节点。

compact 不会从 primary 复制到 secondary，因此需要在每个待整理的成员上分别执行。在支持该操作的版本中，对当前 primary 执行还需要 force: true。具体限制以实际 MongoDB 版本为准。参见 MongoDB compact 文档。

停止写入后还有哪些影响？

停止写入可以减轻业务负载，但 compact 仍会占用磁盘资源，运行时还可能需要额外空间。如果所有成员同时整理，整个副本集都会承受维护负载；成员共享底层存储时，资源竞争可能更明显。

“不阻塞 CRUD”也不等于“没有性能影响”。MongoDB 7.0 文档说明，compact 不阻塞 CRUD，secondary 整理期间仍可复制并接受读取，但延迟仍可能增加。旧版本的行为需要单独核对。参见 MongoDB 7.0 compact 文档。

建议怎样执行？

以下是自建副本集的逐节点流程，执行前须确认部署版本支持相应操作：

1. 确认成员健康、复制已追平，并检查目标节点的可用磁盘空间。
2. 直接连接一个 secondary，在目标数据库中执行 compact。
3. 等待操作完成，检查节点状态、复制延迟和磁盘负载，再处理下一个 secondary。
4. 处理完全部 secondary 后，将原 primary 降级。等待新 primary 选举成功，再整理已成为 secondary 的原 primary。

这是官方文档给出的自建副本集维护顺序。参见 副本集 compact 操作步骤。

例如，直接连接目标 secondary 后，整理示例数据库 app 中的 events 集合：

db.getSiblingDB("app").runCommand({ compact: "events" })

执行时请替换数据库和集合名称。该命令针对一个集合及其索引，不会一次整理整个副本集。

可以用 rs.stepDown() 降级原 primary。执行前必须有已追平且可被选举的 secondary，切换期间写入会受到影响。参见 rs.stepDown() 文档。

什么情况下考虑并行？

如果能接受维护期间服务性能下降或不可用，且已在相同版本和相近数据规模下验证过资源余量，可以评估并行执行。原问题没有提供版本、存储配置和读取要求，因此无法保证所有成员并行执行不会出问题。

备注：内容仅供参考。