config.changelog不可直接truncate或drop，否则导致元数据不一致；它由mongos写入、记录配置变更且无自动过期机制；唯一安全清理方式是mongodb 4.2+中通过mongos执行deletemany（需先停balancer并限定时间范围）。
MongoDB 的 config.changelog 集合不能直接 truncate 或 drop，强行删会导致分片集群元数据不一致甚至不可用。
为什么 config.changelog 会越长越大
这个集合由 mongos 写入，记录所有分片集群的配置变更（如添加/删除分片、迁移 chunk、更新 balancer 状态等）。只要集群长期运行且频繁调整，日志就持续追加——它不自动过期，也不受 TTL 索引支持（MongoDB 官方明确禁止在 config 数据库建索引）。
常见错误现象：config.changelog 占用几十 GB，查询变慢，mongos 启动或重载配置时卡顿，备份时间飙升。
- 不是业务数据，但属于集群“操作心跳”，删了不影响当前服务，但删错会破坏集群可恢复性
- 不能用
db.changelog.deleteMany({})或db.changelog.drop()—— config 库只读，写操作会被 mongos 拦截并报错：not authorized on config to execute command { delete: "changelog", ... } - 也不能通过
mongod直连 config server 执行删除：config server 是特殊角色，其本地config库受内部保护，绕过 mongos 操作极大概率导致元数据损坏
唯一安全的清理方式：用 sh.stopBalancer() + mongos 连接执行 remove（仅限 MongoDB 4.2+）
从 MongoDB 4.2 开始，官方开放了有限度的 config.changelog 清理入口，但仍要求严格前置条件和操作顺序。
- 必须先停掉 balancer：
sh.stopBalancer()，否则清理过程中新日志写入会导致状态不一致 - 必须通过
mongos（不能直连 config server）连接到集群，用 admin 数据库权限执行 - 只能按时间范围删旧数据，推荐保留最近 7–30 天（取决于你故障回溯需求），例如：
use config
db.changelog.remove({ "time": { "$lt": ISODate("2024-04-01T00:00:00Z") } })注意：remove() 在 4.4+ 已标记为 deprecated，应改用 deleteMany()，但它在 config 库中仍被允许（仅此一处例外）；deleteMany() 行为相同，但更符合当前语法习惯。
自动化轮转必须靠外部脚本 + 时间窗口控制
MongoDB 不提供内置轮转机制，得自己定时调用。关键不是“能不能删”，而是“删多少”和“什么时候删最稳”。
- 脚本必须检查 balancer 状态：
sh.getBalancerState()返回true时禁止执行清理 - 建议在每日低峰期（如凌晨 2–4 点）运行，且每次只删 1 天或 3 天，避免单次操作阻塞 mongos
- 命令行示例（用 mongo shell 脚本）：
mongo --host mongos-host:27017 --eval "
if (sh.getBalancerState()) {
print('Balancer is ON, skip cleanup');
quit(1);
}
db = connect('config');
cutoff = new Date();
cutoff.setDate(cutoff.getDate() - 15); // 保留最近 15 天
result = db.changelog.deleteMany({ 'time': { '\$lt': cutoff } });
print('Deleted ' + result.deletedCount + ' changelog entries');
"别依赖 system.timeZone：config server 和 mongos 时区可能不一致，统一用 UTC 时间比较安全。
容易被忽略的兼容性坑
不同版本行为差异极大，错配就会失败或静默无效果：
- MongoDB not authorized，别白费力气
- MongoDB 4.2–4.4：支持
deleteMany，但部分 patch 版本（如 4.2.8 之前）有 bug，删完后sh.status()可能显示异常，建议升到 4.2.12+ - MongoDB 5.0+：依然支持，但官方文档已移除相关说明，属“未弃用但不鼓励”，未来版本可能收紧
- 云托管服务（如 Atlas、MongoDB Cloud）：默认禁用 config 库写权限，即使你有 admin 角色，也会被平台拦截，需提工单申请临时开通
真正麻烦的从来不是命令怎么写，而是确认当前集群版本、balancer 实际状态、以及你连的是不是真正的 mongos（而不是误连了 config server 或 shard primary）——这三个点错一个，清理就变成高危操作。
