分片集群迁移报“Storage engine mismatch”错误，表明各分片及config server存储引擎不一致（如wiredTiger与mmapv1混用）；须全部统一为wiredTiger，且需通过数据导出导入而非配置覆盖来切换旧引擎。
分片集群迁移时提示“Storage engine mismatch”
直接报错 Storage engine mismatch between shards，说明至少有两个分片使用了不同的存储引擎（比如一个用 wiredTiger，另一个还在用已废弃的 mmapv1）。MongoDB 分片集群要求所有分片（包括 config server）必须使用相同的 storage engine，否则无法完成 chunk 迁移、元数据同步等关键操作。
实操建议：
- 登录每个分片的
mongod实例，执行db.serverStatus().storageEngine.name确认当前引擎 - 检查 config server 节点——它常被忽略，但同样必须是
wiredTiger - 如果发现
mmapv1，不能在线切换；需导出再导入，或重搭该节点（4.2+ 版本已彻底移除 mmapv1 支持） - 注意：副本集内所有成员也必须一致，否则主从同步会失败，间接导致分片迁移卡住
mongod 启动参数中 storageEngine 不生效
改了配置文件里的 storage.engine: wiredTiger，重启后 db.serverStatus().storageEngine.name 仍返回 mmapv1，大概率是数据目录里已有旧引擎的文件残留。MongoDB 启动时会优先按现有数据文件格式选择引擎，不强制覆盖。
实操建议：
- 停掉
mongod，检查数据目录下是否存在_mdb_catalog.wt（wiredTiger）或journal/（mmapv1）等标志性子目录 - 若存在
journal/且无*.wt文件，说明确实是 mmapv1 数据，此时设置storage.engine无效 - 安全做法：用
mongodump导出，新建空目录，用wiredTiger启动后mongorestore导入 - 切勿手动删除数据文件或强行修改配置硬启，会导致数据不可读
config server 使用 embedded 模式导致迁移失败
在测试环境或旧部署中，config server 可能以 --configsvr --dbpath 方式单节点运行，但未显式指定 storage.engine。这种情况下，它可能沿用系统默认或历史遗留的引擎，和分片节点不一致。
实操建议：
- config server 必须明确声明
storage.engine: wiredTiger，不能依赖默认值 - 确认 config server 的
mongod进程启动命令或配置文件中包含该配置项 - 4.4+ 版本要求 config server 必须是 replica set（即至少 3 节点），单节点 config server 已不被支持，迁移前需先升级架构
- 验证方式：连接 config server 执行
db.runCommand({getCmdLineOpts: 1})，查看输出中parsed.storage.engine字段
迁移卡在 “waiting for replication” 状态
看起来迁移没报错，但 sh.status() 显示某个 chunk 长时间处于 WAITING_FOR_REPLICATION，本质仍是存储引擎不一致引发的隐性故障：目标分片因引擎不兼容，无法正确应用 oplog，导致复制延迟无限累积。
实操建议：
- 查目标分片的日志，搜索
storage engine或oplog相关 warn/error，常会看到类似cannot apply oplog entry: unsupported storage engine - 对比源分片与目标分片的
db.version()和db.serverBuildInfo().versionArray，版本差异也可能放大引擎兼容问题 - 临时缓解：停止 balancer（
sh.stopBalancer()），逐个分片确认引擎和版本，修复后再开启 - 别只看
sh.status()表面状态——底层复制链断裂时，它不会主动报错，只会挂起
实际操作中最容易漏掉的是 config server 的引擎一致性，以及误以为改了配置就等于生效。数据目录的引擎类型由物理文件决定，不是靠配置覆盖的。
