MongoDB分片集群部署与Chunk迁移调优实践

MongoDB分片集群的架构组成与路由机制

MongoDB分片集群由三个核心组件构成：Config Server（配置服务器，存储集群元数据和Chunk分布信息）、Mongos（路由进程，接收客户端请求并路由到对应分片）、Shard（分片，存储实际数据，每个分片是一个Replica Set）。客户端连接Mongos而非直接连接Shard，Mongos根据查询条件中的分片键定位目标Shard，将请求转发过去并合并结果返回。

分片键（Shard Key）决定了数据在分片间的分布方式，一旦选择后不可修改（5.0之前），选择不当会导致数据倾斜和热点分片。分片键类型包括：范围分片（Range）和哈希分片（Hashed）。范围分片支持范围查询效率高但容易产生热点；哈希分片数据分布均匀但范围查询需要广播到所有分片。

分片集群部署实操步骤

以下以3分片+3节点Config Server+2个Mongos的生产级集群为例：

# 1. 启动Config Server副本集（3节点）
mongod --configsvr --replSet cfgRS --port 27019 \
  --dbpath /data/configdb --bind_ip 0.0.0.0 \
  --logpath /var/log/mongodb/config.log --fork

# 初始化Config Server副本集
rs.initiate({
  _id: "cfgRS",
  configsvr: true,
  members: [
    { _id: 0, host: "cfg1:27019" },
    { _id: 1, host: "cfg2:27019" },
    { _id: 2, host: "cfg3:27019" }
  ]
})

# 2. 启动分片副本集（每个分片3节点）
mongod --shardsvr --replSet shardRS1 --port 27018 \
  --dbpath /data/shard1 --bind_ip 0.0.0.0 \
  --logpath /var/log/mongodb/shard1.log --fork

# 3. 启动Mongos路由
mongos --configdb cfgRS/cfg1:27019,cfg2:27019,cfg3:27019 \
  --port 27017 --bind_ip 0.0.0.0 \
  --logpath /var/log/mongodb/mongos.log --fork

# 4. 添加分片
sh.addShard("shardRS1/shard1a:27018,shard1b:27018,shard1c:27018")
sh.addShard("shardRS2/shard2a:27018,shard2b:27018,shard2c:27018")
sh.addShard("shardRS3/shard3a:27018,shard3b:27018,shard3c:27018")

# 5. 启用数据库分片
sh.enableSharding("myapp")

# 6. 对集合启用分片
sh.shardCollection("myapp.orders", { user_id: 1, created_at: 1 })

Chunk分裂与迁移的内部机制

MongoDB将分片键值域划分为多个Chunk，每个Chunk默认64MB。当Chunk大小超过阈值时触发分裂（Split），将一个Chunk一分为二；当分片间Chunk数量差异超过阈值时触发迁移（Migration），由Balancer自动将Chunk从负载高的分片移动到负载低的分片。

Chunk迁移的四个阶段：

1. 初始扫描：源分片扫描Chunk数据，计算迁移范围。

2. 数据拷贝：源分片将Chunk数据写入目标分片，期间源分片继续处理对该Chunk的读写请求，写操作记录在oplog中。

3. 追赶（Catchup）：目标分片读取源分片oplog中的增量写操作，追赶到迁移期间的变更。

4. 提交（Commit）：Mongos更新Config Server的元数据，将Chunk的归属从源分片切换到目标分片。切换瞬间可能有短暂阻塞。

// 监控Chunk分布和迁移状态
db.adminCommand({ balancerStatus: 1 })

// 查看各分片的Chunk数量
db.config.chunks.aggregate([
  { $group: { _id: "$shard", count: { $sum: 1 } } },
  { $sort: { count: -1 } }
])

// 查看正在进行的迁移
db.config.migrations.find()

// 查看迁移历史
db.config.changelog.find({
  what: { $in: ["split", "moveChunk.start", "moveChunk.commit"] }
}).sort({ time: -1 }).limit(20)

Balancer调优与迁移窗口控制

Balancer默认持续运行，大集群中迁移操作会消耗大量网络I/O和磁盘I/O，影响业务性能。生产环境通常设置迁移窗口，只在低峰时段允许Balancer运行。

// 设置Balancer只在凌晨2点到6点运行
db.config.settings.update(
  { _id: "balancer" },
  { $set: { activeWindow: { start: "02:00", stop: "06:00" } } },
  { upsert: true }
)

// 紧急情况下手动停止Balancer
db.adminCommand({ balancerStop: 1 })

// 手动触发特定Chunk迁移
db.adminCommand({
  moveChunk: "myapp.orders",
  find: { user_id: ObjectId("50a...") },
  to: "shardRS2"
})

// 调整Chunk大小
db.config.settings.update(
  { _id: "chunksize" },
  { $set: { _id: "chunksize", value: 128 } },
  { upsert: true }
)

分片键选择策略与数据倾斜修复

分片键选择是分片集群成败的关键。常见错误选择：使用ObjectId作为范围分片键（单调递增导致所有写入集中到最后一个分片）；使用低基数字段（如性别、状态枚举值）导致数据集中在少数Chunk。

推荐的分片键设计原则：

1. 高基数：字段取值范围大，保证足够多的Chunk数。

2. 低频率：字段值不单调递增，写入分散到各分片。

3. 复合分片键：第一个字段用哈希分散写入，第二个字段用范围支持范围查询。

// 理想的复合分片键设计
// 场景：订单表，按用户查询为主，偶尔按时间范围查询

db.orders.createIndex({
  user_id: "hashed",
  created_at: 1
})

sh.shardCollection("myapp.orders", {
  user_id: "hashed",
  created_at: 1
})

// MongoDB 6.1+支持resharding重新选择分片键
db.adminCommand({
  reshardCollection: "myapp.orders",
  key: { user_id: "hashed", created_at: 1 }
})

分片集群的监控与告警配置

分片集群的核心监控指标包括：各分片Chunk数量差异（大于20%触发告警）、迁移速率和持续时间（持续迁移超30分钟告警）、各分片磁盘使用率（任一分片大于80%告警）、Balancer队列长度（积压迁移大于100告警）。结合Prometheus MongoDB Exporter采集指标，配置Grafana仪表盘可视化。

groups:
- name: mongodb_sharding
  rules:
  - alert: ShardChunkImbalance
    expr: |
      max(mongodb_shard_chunks) / min(mongodb_shard_chunks) > 1.5
    for: 30m
    labels:
      severity: warning
    annotations:
      summary: "分片Chunk分布不均衡"
  - alert: BalancerStuck
    expr: mongodb_balancer_running == 1 and mongodb_balancer_migrations_in_progress == 0
    for: 1h
    labels:
      severity: critical
    annotations:
      summary: "Balancer运行但无迁移进展"

MongoDB分片集群的运维核心是合理选择分片键、控制Balancer迁移窗口、持续监控Chunk分布均衡性。一旦分片键选择不当导致倾斜，修复代价极大（需要resharding），因此在设计阶段就要基于数据增长预估和查询模式仔细评估分片键方案。