mongodb分片集群无法直接限速chunk迁移，因内核硬编码且无migratebandwidthlimit配置；仅能通过暂停均衡、控制单次耗时、调整chunk大小或reshardcollection间接调控迁移密度，或在系统层用tc限速，但需警惕cpu开销、锁持有延长等副作用。
分片集群迁移流量无法通过配置项直接限速，MongoDB 不提供 chunk 迁移带宽控制开关。所谓“限速”，实际是通过间接手段调控迁移节奏和资源占用。
为什么没有 migrateBandwidthLimit 这类配置？
MongoDB 从设计上就未暴露迁移带宽参数——net.compression.compressors 只影响客户端连接层，对分片间 chunk 迁移无效；sh.moveChunk 等命令也不接受速率参数。这是内核级硬编码行为：迁移由负载均衡器触发，底层使用 snappy 压缩（6.0+ 默认启用且不可替换），压缩率与网络吞吐已固化。
能控制的只有迁移频率和并发数
真正可调的维度是迁移的“密度”，而非“速度”：
- 通过
sh.setBalancerState(false)完全暂停迁移，适用于维护窗口 - 用
sh.startBalancer({maxTimeMS: 300000})设置单次均衡回合最大耗时（单位毫秒），避免长迁移阻塞其他操作 - 调整迁移阈值：修改
chunk大小（sh.splitAt()或sh.splitFind()）间接影响单次迁移数据量，但需配合sh.stopBalancer()手动触发 - 在 MongoDB 8.0+ 中，可用
reshardCollection替代传统范围迁移——它不走 chunk 迁移通道，而是重建分片分布，全程不产生迁移流量，但要求 shard key 不变且目标集群空闲
网络层绕过方案：仅限物理/虚拟机环境
若必须压低实际网络带宽，只能在操作系统或网络设备层面做限制：
- Linux 上用
tc（traffic control）对 mongod 进程出向流量限速，例如：tc qdisc add dev eth0 root tbf rate 10mbit burst 32kbit latency 400ms - 云厂商 VPC 内可通过安全组或网络 ACL 限速，但注意 config server 与 shard 之间、shard 与 shard 之间的双向通信均需覆盖
- 切勿在 mongos 节点上做限速——它不参与 chunk 迁移，只负责路由
- 该方式会延长迁移总时长，且可能触发迁移超时失败（默认
moveChunk超时为 600 秒），需同步调大moveChunkTimeoutMS参数
真正容易被忽略的是：snappy 压缩虽降低传输量，但会增加 CPU 开销；而限速后迁移时间拉长，会导致锁持有时间变长、jumbo chunk 更难清理、甚至引发元数据不一致——这些副作用比带宽本身更值得警惕。
