MongoDB分片迁移时出现"Lock busy"错误怎么办：锁争用与高负载下的重试策略
遇到分片迁移时蹦出的“Lock busy”错误，确实让人头疼。这背后，往往不是简单的死锁，而是一场围绕配置服务器（config server）或目标分片元数据写锁的并发争夺战。想想看，当集群里同时跑着大量chunk迁移、手动触发moveChunk，或者应用正在高频创建索引、删除集合时，它们都在争抢config数据库那把全局写锁，场面能不“忙”吗？
关键在于理解这个锁的机制。即便MongoDB 4.2+的配置服务器采用了副本集，但所有元数据变更依然需要主节点来串行处理。这个锁的粒度，并非针对单个文档，而是针对逻辑单元——比如对chunks集合的某一次更新操作。一旦某次迁移因为网络延迟或目标分片磁盘性能不佳而卡住，后续的迁移请求就会在锁队列里排起长队，最终超时，抛出那个熟悉的Lock busy。
这里有几个常见的误区需要厘清：
- 指望通过加大
secondaryThrottle参数来缓解？这条路走不通。它只控制数据拷贝到从节点的节奏，对减少元数据锁的竞争毫无帮助。 moveChunk命令默认超时是60秒，但真正的锁等待时间由lockTryAcquireWaitMS参数控制（默认5000毫秒）。时间一到，锁还没拿到，命令就直接报错退出了。- 如何快速确认是锁的问题？执行
sh.status()，如果看到大量pending状态或者chunk migration in progress的提示，基本就可以断定，锁队列已经饱和了。
为什么 Lock busy 错误总在分片迁移中途爆发
这个问题其实已经点明了核心症结。它通常不是随机出现的，而是在迁移这个对元数据锁高度依赖的操作进行到一半时爆发。根本原因在于并发操作对同一关键资源的争夺。当多个迁移任务，或者迁移与DDL（数据定义语言）操作撞车时，config服务器的锁机制就成了瓶颈。迁移过程中的每一步关键状态更新，都需要这把锁，任何一个环节被其他操作阻塞，连锁反应就会导致后续任务全部“忙等”。
怎么安全降低迁移期间的锁压力
应对思路可以概括为三个词：错峰、限流、避免震荡。别再简单地启动平衡器（sh.startBalancer()）后就放任不管了，那无异于在交通高峰期把所有车都放进主干道。
- 人工调度，分批迁移：先执行
sh.stopBalancer()停掉自动平衡，改为手动执行moveChunk。每次只迁移1到2个chunk，并且在每次操作之间留出至少30秒的间隔，给锁释放和系统喘息的时间。 - 净化操作环境：在规划的迁移窗口期内，尽量避免执行
createIndex、collMod、renameCollection等会产生元数据变更的操作。尤其要确保没有直接对config数据库的写入。 - 控制迁移粒度：通过调整
chunkSize（例如在mongos启动参数中设置为--chunkSize 64，单位MB）来减小单个chunk的大小。更小的chunk意味着单次迁移耗时更短，自然也就缩短了持有元数据锁的时间。 - 主动监控锁状态：直接查询
config.locks集合，使用db.locks.find({state: 2})来查看当前已被获取（state: 2表示acquired）的锁，检查是否有异常长时间持有锁的会话。
moveChunk 命令里哪些参数能绕过锁瓶颈
首先要明确一点，moveChunk命令本身无法“绕过”锁机制，但通过合理配置参数，可以最大限度地缩短占用锁的窗口，并避免因失败重试而引发的雪崩效应。
- 启用二级节流：务必显式设置
_secondaryThrottle: true。这个参数能确保数据在源分片删除和目标分片写入之间有序进行，如果设为false，两者并行反而可能增加冲突和锁竞争的概率。 - 等待删除完成：加上
waitForDelete: true参数。这能保证命令在源分片上的chunk数据被彻底删除后才返回，防止残留数据导致后续迁移时的校验失败，引发新一轮的锁竞争。 - 合理设置超时：谨慎使用
maxTimeMS参数。设置过短（比如5000毫秒）会导致迁移因临时性延迟而频繁失败重试，反而加重锁队列负担。建议根据集群状况设置为一个更充裕的值，例如120000毫秒（2分钟），以覆盖磁盘IO较慢等场景。 - 慎用强制选项：不要轻易使用
force: true参数。它仅仅跳过一些一致性检查，并不会跳过锁获取步骤。强行使用可能导致配置服务器元数据不一致，造成更棘手的问题。
一个相对稳健的命令示例如下：
sh.adminCommand({
moveChunk: "mydb.mycoll",
find: { _id: 1 },
to: "shard01",
_secondaryThrottle: true,
waitForDelete: true,
maxTimeMS: 120000
})
监控和自动重试的底线逻辑
实现自动重试，可不是简单地加个while循环那么简单。这里的重点不在于“重试多少次”，而在于“在什么时机重试”——必须等待锁真正被释放，而不是用轮询的方式去硬碰硬。
- 精确错误匹配：在代码中捕获错误时，必须精确匹配
LockBusy（注意大小写）。不要把它和Lock timeout或InterruptedDueToReplStateChange等其他错误混淆。 - 采用退避策略：重试前固定等待5到10秒的方式过于生硬。更优的做法是采用指数退避算法，例如首次等待3秒，下次等待6秒，逐渐增加，但设置一个上限（比如30秒），这样可以有效避免所有重试请求同时发起导致集群雪崩。
- 验证迁移状态：在发起重试前，应该先检查chunk的当前状态。可以通过查询
db.chunks.findOne({ min: ..., max: ..., shard: "shard01" })来确认这个chunk是否确实没有移动到目标分片，防止进行重复的、不必要的迁移操作。 - 追踪元数据状态：关注
config.migrations集合中的state字段。只有当其状态变为committed时，才表示迁移真正成功。如果状态是failed或为空，通常意味着需要人工介入排查。
还有一个极易被忽略的陷阱：迁移失败后，源分片上的chunk数据通常不会自动回滚，但配置服务器里的元数据可能已经进行了部分更新。此时如果直接发起重试，很可能触发DuplicateKey（重复键）或ChunkTooBig（块过大）等新的错误。正确的处理流程是：首先执行sh.stopBalancer()停止平衡器，然后使用带force: true参数的moveChunk命令强制同步元数据，最后务必进行数据一致性验证，确保集群处于健康状态。
