dbHash命令在副本集中不可靠，因其哈希值受元数据差异影响，不能直接用于一致性判定；必须限定collections参数、按集合名排序后逐项比对hash，并结合count、storageSize、totalSize及抽样验证。
dbHash命令在副本集里到底靠不靠谱
dbHash 命令返回的是当前节点上所有集合的哈希值汇总，但它**不保证跨节点比对结果可直接用于一致性判定**。MongoDB 官方文档明确说明：dbHash 的输出受集合元数据（如索引顺序、空闲空间分配、WiredTiger内部压缩状态）影响，同一份逻辑数据在不同节点上可能产生不同哈希值——尤其当节点版本不一致、存储引擎配置不同，或执行过compact操作时。
真正能反映数据差异的操作是 dbHash + collection-level 比对
单靠db.runCommand({dbHash: 1}) 返回的顶层哈希没意义；必须逐集合调用db.runCommand({collStats: "xxx"})确认count和size，再用db.runCommand({dbHash: 1, collections: ["a", "b"]})限定范围比对。否则容易把元数据抖动当成数据不一致。
- 必须显式传入
collections参数，否则默认只算非系统集合，且忽略system.*类元数据集合（比如system.views） - 主节点和从节点的
dbHash响应中collections字段顺序可能不同，比对前要先按集合名排序 - 如果某集合在某个节点上被
drop但oplog还没同步完，该节点的dbHash响应里压根不会包含它——这不是哈希不一致，是状态不同步
dbHash失败常见报错和对应原因
执行db.runCommand({dbHash: 1})时遇到错误，基本指向权限、连接或状态问题，不是数据本身出错：
-
"not master and slaveOk=false"：连接的是从节点但没设readPreference=secondary，或用户没开slaveOk -
"command dbHash requires authentication"：用户缺少clusterMonitor角色，仅read权限不够 -
"operation exceeded time limit"：库太大或I/O压力高，建议加maxTimeMS参数控制超时，例如{dbHash: 1, maxTimeMS: 30000}
比对脚本里最容易漏掉的三个细节
写自动化比对脚本时，90% 的误报来自这三个点：
- 没过滤掉
system.开头的集合（如system.profile），它们在不同节点上活跃度不同，哈希必然不同 - 没统一时间点：主节点执行
dbHash后，从节点延迟几秒再执行，期间有新写入就会导致哈希不等——应通过rs.printSecondaryReplicationInfo()确认各节点optimeDate差在毫秒级再比 - 用
JSON.stringify()直接比两个dbHash响应对象，但JavaScript对象键序不固定，会导致假不一致；必须提取collections数组，按集合名排序后再逐项比hash字段
哈希值本身只是线索，真正要确认数据一致，得看count、storageSize、totalSize三者是否全部吻合，再抽样查几条_id的$eq结果。不然光看dbHash，就像只称体重判断两个人是不是双胞胎。
