1. 起因一场真实的“单机崩盘”凌晨现场我至今记得那个凌晨四点的电话。线上MongoDB主节点挂了从节点没有自动提升成功整个业务入口直接瘫痪。运维兄弟在电话里语气急促我却连一个能快速恢复的备份方案都拿不出来。那次事故让我意识到一个很无情的现实单机MongoDB再快也是有天花板的而且天花板撞上来的时候根本不会给你留准备时间。当时的业务规模其实不算夸张日增数据几十GBQPS不过几千。但我犯了一个很多团队都犯过的错以为读写压力还能顶得住就一直没动分片的念头。结果磁盘满了之后写入连续失败WiredTiger的checkpoint反复做不上去最后我把整个库从备份恢复到可用折腾到当天中午。业务方每十分钟来催一次那种焦灼感到现在我都记得。后来复盘的时候我才真正想明白一件事单机到分片的本质不是“容量翻倍”而是一次架构层面的跃迁。你没法靠换一台更大的机器解决所有问题哪怕换了NVMe硬盘CPU和内存也会很快追上瓶颈。这个节点上MongoDB分片是你绕不开的方案。它能把数据水平打散到多台机器让容量、性能、可用性都往上走一个台阶前提是你足够懂它。这篇文章我会把从单机迁到分片集群过程中踩过的坑、查过的问题、验证过的做法全部拆开来讲。重点放在“10大生死坑”上适合已经在用MongoDB、正准备从单机迁移到分片架构的开发和DBA。你不需要全部看完再动手可以先跳到对应章节遇到问题再回来翻。2. 为什么要分片架构跃迁背后的真实逻辑2.1 单机瓶颈到底卡在哪三个环节先说说我为什么坚持要分片。单机MongoDB的瓶颈不是某一个点而是三个点同时卡你磁盘容量、CPU计算、内存命中。磁盘容量是最直观的。数据只增不减单机磁盘总有满的一天。网上经常能看到“C盘满了怎么扩容”“DiskGenius扩容C盘”这类内容但那是磁盘分区的活MongoDB面对的是数据量和访问量同时增长根本不是同一个量级的问题。单机磁盘满了之后读写都会出问题扩容只能缓解一时数据还在涨你迟早要面对架构级的变化。CPU和内存的瓶颈更隐蔽。MongoDB在读多写少业务下热点数据如果都能命中内存性能还不错一旦数据量超过内存容量WiredTiger就会频繁刷盘磁盘IO成为最大瓶颈。我见过有些团队堆硬件把单机配置提到128核、512GB内存短期看性能没问题但成本上去了而且数据量再翻一倍又得继续加配置。垂直扩展这条路只会越走越窄越走越贵。2.2 分片集群的三大组件每层都在解决什么问题MongoDB分片集群核心就是三个角色mongos、config server、shard。搞清楚这三个角色后面所有坑都好理解。mongos是路由层业务连接都打到它身上它要把读写请求转发到正确的shard。它本身不存数据是无状态的所以可以横向多部署几个。很多人不理解mongos存在的意义觉得多了一次转发开销但正是这一层把分布式路由逻辑收口了客户端只需要连接mongos完全不用关心数据到底在哪个shard。config server是元数据层它存着“哪个chunk属于哪个shard”这类信息。mongos启动和运行时要频繁访问config server。从3.2版本开始config server必须以副本集方式部署原因很简单元数据丢了整个集群就等于全废。这条规则是MongoDB吸取了大量生产事故教训之后定下来的不是随便设计出来的。shard是真正的数据层每个shard本身就是一个副本集副本集内部通过oplog做数据同步。写数据时mongos根据分片键计算目标chunk然后把请求转发给对应shard。每个shard的副本集配置决定着你这个分片集群的数据安全等级这方面千万不能省。2.3 什么时候才真正需要分片以及什么时候千万别碰分片不是MongoDB的默认选项它是有代价的。分片之后聚合查询如果没带分片键会在所有shard上跑一遍再合并结果这种“scatter-gather”操作比单机慢得多。索引管理、备份恢复、监控告警的复杂度也会上一个台阶。所以团队里没有能Hold住分布式数据库的人之前别急着上分片。我的判断标准是三个条件同时满足再考虑分片数据量达到数TB级别、单机性能无可避免地下降、业务读写模型能够接受分片键约束。如果是几百GB且QPS不高先把索引、查询、存储引擎、副本集部署这些基本功做好分片反而会拖慢业务迭代效率。记住分片解决的是“单机装不下、扛不住”的问题不是用来炫技的。3. 动手落地一套高可用的分片集群搭建方案3.1 蓝图设计机器规划、版本选型和分片数估算我有一个经验先在白板上把拓扑画出来再动手装。别小看这一步很多后面踩的坑其实在设计阶段就已经注定了。版本选择上当时线上是MongoDB 3.6.8。如果是从0开始建议选4.2以上版本事务支持和分片相关的运维工具成熟很多。但如果你已经有存量库不要直接跨大版本升级后面坑10会专门讲。我见过不少团队贪图新版特性直接把生产库从3.x跳到5.x结果一堆兼容性报错最后只能回滚。分片数怎么定我一般按“单shard承载1TB以内”来规划。分片不是越多越好分片多了config server的元数据量也会涨mongos的转发逻辑也更重。最稳妥的做法是从3到4个分片开始观察均衡情况后再水平加shard。每个shard建议用独立机器不要和config server混布。磁盘方面我习惯按实际数据的2到2.5倍来规划否则过个半年又要扩容又得折腾一轮。3.2 分片键整个方案里第一个生死决策分片键选错后面所有的操作都是在还债。这句话我说给每一个来找我问MongoDB分片的朋友听。分片键的两个核心要求一是基数足够大字段值不能就这么几个二是业务查询要尽量带它。我举个例子按user_id做范围分片用户量大值域广绝大多数业务查询也都是按用户维度来这种就非常合适。如果用status这种状态字段做分片键状态值就0/1/2三个那每个chunk都没法继续分裂数据根本摊不开集群会变成一堆jumbo chunk的集合。另外要强调一点分片键一旦确定文档写入之后就不能修改字段值。这是很多人在设计阶段完全忽略的。你要提前想清楚业务将来会不会改这个字段否则只能用组合分片键或者接受以后“导出重导”的代价。设计分片键时我一般会拉开发一起过一遍所有核心查询的where条件看有没有一个能被大多数查询带上的字段那个字段就是候选分片键。3.3 从单机到集群的迁移能少踩坑就少踩坑迁移方案我走了不少弯路最直接的流程是这样的搭建分片集群mongos、config server、shard拓扑全部起来。用mongosh连接mongos对目标集合执行sh.shardCollection()开启分片。单机端用mongodump导出数据集群端用mongorestore导入。修改业务连接串指向mongos验证读、写、聚合、索引是否正常。这里有个细节mongodump和mongorestore在数据量大的时候非常慢。十亿级别的数据就别想了更靠谱的是用文件系统快照做物理迁移或者借助MongoDB自带的复制机制让分片集群作为单机数据源的一个从节点先全量同步再增量追平最后切换。这种方式对外部影响小回滚也方便。我自己后来一直用第二种方式比dump恢复省太多时间。刚迁移完那几天一定要盯着每个shard的chunk分布。mongorestore导入的数据极大概率都落在同一个shard上需要均衡器慢慢搬这是正常的。但如果你没有预分片这个搬运过程会非常漫长具体怎么处理我在坑6里详细说。4. 生死坑实录上架构规划期的5个致命坑4.1 坑1分片键选错热写入让集群比单机还慢先说最毒的一个坑。有段时间我发现集群的写入延迟比单机还高查了一圈才发现问题是分片键设计成单调递增的流水号范围分片导致所有新写入都集中到最后一个shard。写入全部打在一个热点shard上其他shard闲着看热闹。这种问题在监控上看不出来因为集群整体的QPS没有下降但每个shard的负载完全不一样。用db.printShardingStatus()查看或者在config库里查chunks集合一眼就能看出数据全堆在一个shard上。真正线上排查时我习惯先看每个shard的连接数、命令执行时间和chunk数量三者一对比热点分片立刻现形。解决办法分两步短期先用均衡器把已有chunk摊开但治标不治本长期要把分片键改成hashed分片或者用组合分片键把单调递增字段的分布打散。这个坑最可怕的地方在于业务规模越大迁移成本越高。等数据到了几十TB再想换分片键工程量大得能让你怀疑人生。所以架构阶段一定要把分片键的数据分布特征想清楚。4.2 坑2基数太差chunk根本无法分裂分片的基本单位是chunk默认64MB。当chunk数据量超过64MB时MongoDB会尝试把chunk一分为二。问题来了如果分片键的基数太低比如用布尔值当分片键那整个keyspace最多就两个分片区间想分裂都没有地方下刀。我见过一个团队用类别字段做分片键全表只有4个值结果数据量翻番后每个chunk都标成jumbo迁移也迁不了删除也删不动集群直接进入半瘫痪状态。当时他们想用sh.splitAt()手动切分但根本找不到可用的切分点因为每个分片键值对应的数据量都超过了chunk上限怎么切都超。遇到这种时候别想着“改一下分片键就好了”。MongoDB不允许修改分片键字段的值数据只能导出重导。所以建表前要测算分片键基数少于几百万级别的值域就要警惕了。临时估算方法很简单预计数据量除以64MB得到基础chunk数量分片键值域个数至少要比这个chunk数量高一个数量级才算是安全的。这个教训值不少钱切记。4.3 坑3范围分片遇上单调递增热点全挤在一块这个和坑1类似但很多人会搞混。范围分片本身没问题问题在于业务字段是不是单调递增的。日志表、订单表按时间戳做范围分片看起来逻辑自然实际上写入永远落在最后一个chunk热点无法避免前面分过的chunk反而成了冷数据躺在那里占磁盘。一个有效的做法是hashed分片用哈希把连续的输入打散到不同chunk写入压力可以均匀分摊到所有shard。代价是范围查询会跨多个chunk需要在所有shard上并行扫描再聚合结果性能会有一定损耗。具体损耗多大取决于你的查询筛选字段和分片键的重合度。另一个方案是组合分片键比如user_id加timestamp。这样同一个user的数据会按时间排序聚到一个chunk附近写入能分散时间范围查询也不会太差。前提是设计者吃透了业务的访问模式。我遇到过一些团队简单粗暴地选一个字段做分片键上线两个月后发现这个字段的访问频率极低大部分查询都变成全集群扫描苦不堪言。分片键一定要以查询模式为核心来设计不要只看写入分布。4.4 坑4mongos只部署一个连接数直接把路由打爆mongos是分片集群的流量入口。很多人以为mongos没什么好配的一个就够了。我在生产环境里被教训过应用连接数突然飙升单个mongos的线程和连接全部被打满新的连接直接排队超时业务侧报错一批接一批而shard本身负载其实很低。mongos本身没有状态完全可以横向扩展。生产环境我建议至少部署2到3个mongos前面用负载均衡或者直接在业务驱动的连接串里配多个mongos地址官方驱动会自己做failover和负载均衡。别嫌多这一点点冗余能换来的稳定性远超过那些机器成本。还要把mongos的进程参数调好比如maxIncomingConnections。默认值在某些场景下不够用但不建议盲目调大因为每个连接都占用线程和内存资源调太大反而可能拖垮mongos所在机器的操作系统。我是配合压测结果来调的先看清楚业务连接的峰值再留出30%左右的余量。连接数这个指标一定要放进你最核心的监控面板里。4.5 坑5config server配成光杆司令元数据成了定时炸弹config server是分片集群的“大脑”里面存着所有集合的分片键信息、chunk分布信息。3.2之后的副本集模式是强制要求的但总有人不按规矩来觉得自己用的数据量不大单节点无所谓。有人觉得config server压力小就部署一个裸节点连副本集都没有。结果节点一挂mongos全部报错整个集群不可用。还有人把config server和shard放在同一台机器上磁盘IO互相干扰元数据读写变慢直接影响所有请求的路由速度因为mongos每次路由都要从config server缓存和获取元数据信息。config server必须至少3节点副本集而且最好用独立的小机器或容器。备份策略要和业务数据同等对待该做的快照绝不能少。config server的数据量不大但恢复代价极高一旦元数据损坏整个集群的数据找回难度是你无法承受的。我在客户那边遇到过config server数据文件损坏的情况当时的恢复过程完全是噩梦级别从那以后config server在我心里的地位和业务元数据库完全对等。5. 生死坑实录下迁移与运维期的5个致命坑5.1 坑6一次性灌入历史数据chunk卡在单shard上不动从单机迁移历史数据时我先在mongos上执行了sh.shardCollection()然后启动mongorestore。一开始数据导入非常快几个小时后发现绝大多数chunk还是落在第一个shard上集群整体负载非常不均匀其他shard几乎没写入。原因在于shardCollection初始状态下只有一个chunk所有数据先写到一个shard然后等均衡器慢慢搬。你要是导入几十GB数据还好等一阵子就自动均衡了但要是一次性灌入几十亿条历史数据均衡器根本搬不过来数据一致性窗口越拉越长业务根本等不起。正确做法是预分片。在迁移数据前根据分片键的键值范围手动用sh.splitAt()把chunk拆分成多个让数据写入时直接分散到不同shard。sh.shardCollection()支持对hashed分片做自动预分片只需要指定初始chunk数量。操作时要注意预分区数量不要过大否则会产生大量空的元数据chunk均衡器后续处理它们也会消耗资源。我一般按目标shard数的整数倍来预分区比如4个shard就预分32个初始chunk让均衡压力从第一天开始就均匀分布。5.2 坑7均衡器全天候运行业务高峰撞上chunk迁移均衡器的任务是让数据均匀分布到所有shard。听起来很美好但实际问题很大均衡器迁移chunk的时候会在源shard和目标shard之间拷贝数据磁盘IO和网络带宽全部打满直接影响正常业务读写。我有一次发现线上写延迟从10ms涨到500ms一开始以为是分片键热点排查半天才发现是均衡器正在迁移大量chunk把业务高峰期的IO全吃掉了。均衡器默认是全天候运行的它可不管你的业务高峰期是什么时候只要发现chunk分布不均就开始搬。MongoDB提供了balance window配置可以限制均衡器只能在指定时间段运行。我固定把均衡窗口设在凌晨两点到五点和业务低峰期完全对齐。还有一个实用小技巧在迁移大表之前临时停掉均衡器等迁移完成再打开防止均衡和迁移互相打架导致两边都慢。操作方式很简单用sh.stopBalancer()和sh.startBalancer()就能控制。5.3 坑8write concern还在用默认值主节点挂了直接丢数据分片集群里每个shard是副本集默认write concern是w1意味着主节点写入成功就返回确认。副本集同步是异步的如果主节点在同步完成前宕机这部分数据就永远丢了。很多人只觉得MongoDB不丢数据其实这是错觉。我第一次做故障演练时专门测试了主节点kill的场景。结果令我震惊虽然从节点选举成功了但最后几百条写入的数据丢失了。业务方反馈非常直接“数据没了你们怎么做数据库的”从那以后我把核心写入的write concern调成wmajority确保大多数节点确认后才返回成功。这样做的代价是写入延迟会有所上升因为要等副本复制完才能确认但对核心业务来说这个代价完全值得。读偏好read preference也要按业务场景来设置。默认是primary读从节点只承担备份职责如果用了secondaryPreferred或者nearest要清楚这带来的数据延迟问题。特别是分片集群里不同shard的从节点延迟可能不一样读到的数据可能比主节点旧几秒。这块配置一定要和业务方对齐别让业务拿从节点的数据做实时判断那就麻烦大了。5.4 坑9备份恢复还是单机思维真到恢复的时候傻眼单机MongoDB做备份mongodump一把梭简单直接。分片集群不能这么干原因在于每个shard是独立的副本集各自dump出来的数据在时间点上对不齐。你用单机思维的备份策略恢复出来的集群很可能数据互相矛盾业务根本不敢用。我们后来改成了文件系统快照方式配合云盘快照对每个shard同时做快照尽量保证数据一致性窗口对齐。也可以在业务低峰期短暂停写几分钟再快照这样数据一致性最好。如果用的是WiredTiger存储引擎官方还提供mongod的journal配合快照能把恢复窗口控制得很小。恢复流程也要演练。真到灾难发生的时候顺序是这样的先恢复config server再恢复各shard最后启动mongos。顺序一错整个集群起不来。我专门把这个流程写成运维手册每个季度带着运维同事演练一遍。纸上谈兵没有用一定要真刀真枪地验证过恢复时长确认每个备份文件能真正被使用才算合格。我见过太多团队备份了一堆文件真到恢复的时候才发现文件损坏或者版本不匹配那才是真正的灾难。5.5 坑10版本跨度升级组件之间互相“不认识”MongoDB的版本升级和单机版本不一样分片集群牵扯到mongos、config server、shard三套组件升级顺序错了就会出现组件协议不一致的问题。我见过有人从3.2直接跳到4.0结果shard还在3.2mongos和config server已经是4.0三者通信直接失败集群起不来。官方要求的升级路径是逐版本升级不能跨大版本。每个大版本内部得先升级所有shard再升级config server最后升级mongos。这个顺序不能乱因为新版mongos向后兼容旧版shard但新版shard不一定兼容旧版mongos反过来也一样。升级期间建议先停均衡器避免元数据在升级过程中发生变化。还要检查驱动的兼容性。老版本驱动可能不认识新版本的握手协议连接会直接报错。升级前先在测试环境把驱动、Compass、DBeaver这类工具全部验证一遍确认能连上新版本集群再动生产。DBeaver连接MongoDB如果出现协议问题通常就是驱动包版本太老去官方仓库下个新版驱动包就好。这块虽然没有技术含量但确实是我遇到过最多的“升级后连不上”原因。6. 从单机到千倍容量扩容过程中的容量估算与监控6.1 容量估算不是“加机器”那么简单标题里说“千倍扩容”从单机走到分片集群容量确实可以大几个数量级但不是说一直加机器就完事。我总结了一句话先算数据再算节点最后看chunk。数据量估算要看业务增速。假设单机每天新增10GB数据一年就是3.6TB。分片集群里每个shard建议控制在1TB以内那一年后的数据就需要至少4个shard两年后就需要8个。你还要考虑索引、oplog、磁盘碎片这些额外空间。oplog的大小和副本延迟直接相关建议按2小时以上的写入量来配置。chunk数量也要估算。chunk默认64MB1TB数据约需要16000个chunk。当你增加新shard时这些chunk会被均衡器重新分配每个chunk的迁移都要拷贝数据所以新shard要提前加进去让均衡器有足够时间摊数据。临时抱佛脚式扩容往往扩容命令执行成功后数据均衡要好几天甚至几周期间集群性能反而会下降。6.2 真正重要的监控指标这几个比CPU内存更值得盯分片集群的监控不能只盯CPU和内存。我重点看这几个指标每个shard的chunk数量分布。chunk数量差太大说明均衡有问题要么均衡窗口不够要么分片键设计有缺陷要么有jumbo chunk卡住了迁移。mongos的connections。连接数打满通常是mongos不够用或者应用连接池配置不合理。副本集的复制延迟延迟过大从节点选举后数据会丢也会影响依赖从节点读取的业务。均衡器运行状态它一动IO就占用要观察是否和业务高峰重叠。磁盘使用率和可用空间分片之后磁盘满了依然会发生只是把“单机满盘”变成了“某个shard满盘”。工具方面我用过mongostat和mongotop看实时状态用MongoDB Compass做可视化诊断DBeaver连接mongos查数据分布也很顺手。Compass对日常巡检很友好能直接看到各shard的chunk分布和集合统计信息。DBeaver的优势是SQL化查询对习惯关系型数据库的人来说上手快但连接MongoDB时偶尔要手动下载驱动包第一次连的时候要耐心等它下载完成。6.3 均衡器和chunk管理的几个微调技巧均衡器的默认行为不是万能的几个微调可以解决大问题。第一设置均衡窗口不让均衡器和业务高峰抢资源。第二大表迁移前临时停均衡迁移完再启动。第三调整chunk大小64MB是默认值可以调小到32MB来增加chunk数量、加快均衡粒度但chunk太碎也会增加元数据压力和路由转发开销。反之如果业务数据单文档就很大chunk太小会导致频繁分裂这时调到128MB反而更合适。chunk大小修改要谨慎生产环境我一般不动除非遇到chunk分裂性能问题。调整chunk大小会影响后续分裂和迁移行为但不影响已有chunk的实际大小。还有一个冷门技巧如果某个集合的chunk分布已经严重倾斜且均衡器一直搬不动可以用sh.moveChunk()手动指定目标shard并带上“_secondaryThrottle”参数限流避免迁移把IO打满。手动迁移完要再查一次chunks分布确认不要移完就不管了。7. 常见问题排查速查表问题现象可能原因排查建议解决方向写入延迟升高分片键热点、chunk迁移、磁盘IO饱和查每个shard的负载和chunk分布调整分片键、设置均衡窗口集群读变慢聚合查询未带分片键触发全集群扫描查看explain是否走了targeted查询查询带分片键或接受scatter-gather成本某个shard容量告急数据增长不均匀chunk没有及时迁移查看chunks分布和均衡器状态手动moveChunk规划新增shardmongos连接超时mongos节点太少或连接数达到上限查mongostat里的connections扩mongos节点调maxIncomingConnections副本集延迟增大从节点网络差、磁盘慢、oplog窗口不足查复制延迟时间检查oplog大小优化从节点资源配置均衡器频繁迁移分片键分布异常导致chunk倾斜查看chunk数量和迁移日志预分区优化分片键避开业务高峰这张表被我打印出来贴在工位上每次集群出问题先对一遍表再去看日志。排查思路比单点工具重要因为大多数分片集群故障不是单一原因很可能是几个因素叠加导致的。比如写入慢既可能是分片键热点也可能是均衡器在迁移chunk还可能只是某块磁盘性能下降。把这几条线同时查一遍基本就能定位到真正的根因。这里有个真实案例可以分享有一次我们线上写入延迟持续偏高我按上表逐个排查发现chunk分布完全平均均衡器也没在跑最后用iostat一看某块云盘IO延时到了近百毫秒是同一物理宿主机上的邻居实例在“吵闹”导致磁盘性能严重劣化。这种情况在云环境里很容易被忽略但只要你把排查路径走完整就一定能找到真相。8. 写在最后我的个人体会从单机MongoDB一路迁到分片集群我最深的体会是分片不是灵丹妙药它是一整套工程体系。分片键的设计一定要前置宁可多花三天想清楚也不要上线后用三个月来还债。架构方案、监控告警、备份恢复、故障演练每一个环节都得在动手之前设计好不然就是在给未来的自己埋雷。我个人觉得如果团队里没有一个人真正读过官方分片文档、亲自搭过集群就不要贸然把核心库迁到分片架构。先拿历史数据、非关键业务做试点把均衡、备份、监控全部验证一遍再谈扩容。迁移的过程一定要有回滚方案别觉得“反正数据都导过去了”就万事大吉业务切换时候的运行状态和导入状态往往不一样。最后再分享一个小技巧无论多忙都要定期做故障演练。我每个月至少kill一次某个shard的主节点看集群能不能自动恢复mongos能不能正常切换路由。很多坑都是演练的时候暴露的真等线上出问题再排查成本高到你不想回忆。这篇文章里的每一个坑都是我实际踩过、或者在生产环境帮人救火时见过的。希望你看完之后在分片键设计、迁移落地、运维监控这几个环节都能少走我走过的弯路。
MongoDB从单机到分片集群：迁移避坑指南与10大生死坑
1. 起因一场真实的“单机崩盘”凌晨现场我至今记得那个凌晨四点的电话。线上MongoDB主节点挂了从节点没有自动提升成功整个业务入口直接瘫痪。运维兄弟在电话里语气急促我却连一个能快速恢复的备份方案都拿不出来。那次事故让我意识到一个很无情的现实单机MongoDB再快也是有天花板的而且天花板撞上来的时候根本不会给你留准备时间。当时的业务规模其实不算夸张日增数据几十GBQPS不过几千。但我犯了一个很多团队都犯过的错以为读写压力还能顶得住就一直没动分片的念头。结果磁盘满了之后写入连续失败WiredTiger的checkpoint反复做不上去最后我把整个库从备份恢复到可用折腾到当天中午。业务方每十分钟来催一次那种焦灼感到现在我都记得。后来复盘的时候我才真正想明白一件事单机到分片的本质不是“容量翻倍”而是一次架构层面的跃迁。你没法靠换一台更大的机器解决所有问题哪怕换了NVMe硬盘CPU和内存也会很快追上瓶颈。这个节点上MongoDB分片是你绕不开的方案。它能把数据水平打散到多台机器让容量、性能、可用性都往上走一个台阶前提是你足够懂它。这篇文章我会把从单机迁到分片集群过程中踩过的坑、查过的问题、验证过的做法全部拆开来讲。重点放在“10大生死坑”上适合已经在用MongoDB、正准备从单机迁移到分片架构的开发和DBA。你不需要全部看完再动手可以先跳到对应章节遇到问题再回来翻。2. 为什么要分片架构跃迁背后的真实逻辑2.1 单机瓶颈到底卡在哪三个环节先说说我为什么坚持要分片。单机MongoDB的瓶颈不是某一个点而是三个点同时卡你磁盘容量、CPU计算、内存命中。磁盘容量是最直观的。数据只增不减单机磁盘总有满的一天。网上经常能看到“C盘满了怎么扩容”“DiskGenius扩容C盘”这类内容但那是磁盘分区的活MongoDB面对的是数据量和访问量同时增长根本不是同一个量级的问题。单机磁盘满了之后读写都会出问题扩容只能缓解一时数据还在涨你迟早要面对架构级的变化。CPU和内存的瓶颈更隐蔽。MongoDB在读多写少业务下热点数据如果都能命中内存性能还不错一旦数据量超过内存容量WiredTiger就会频繁刷盘磁盘IO成为最大瓶颈。我见过有些团队堆硬件把单机配置提到128核、512GB内存短期看性能没问题但成本上去了而且数据量再翻一倍又得继续加配置。垂直扩展这条路只会越走越窄越走越贵。2.2 分片集群的三大组件每层都在解决什么问题MongoDB分片集群核心就是三个角色mongos、config server、shard。搞清楚这三个角色后面所有坑都好理解。mongos是路由层业务连接都打到它身上它要把读写请求转发到正确的shard。它本身不存数据是无状态的所以可以横向多部署几个。很多人不理解mongos存在的意义觉得多了一次转发开销但正是这一层把分布式路由逻辑收口了客户端只需要连接mongos完全不用关心数据到底在哪个shard。config server是元数据层它存着“哪个chunk属于哪个shard”这类信息。mongos启动和运行时要频繁访问config server。从3.2版本开始config server必须以副本集方式部署原因很简单元数据丢了整个集群就等于全废。这条规则是MongoDB吸取了大量生产事故教训之后定下来的不是随便设计出来的。shard是真正的数据层每个shard本身就是一个副本集副本集内部通过oplog做数据同步。写数据时mongos根据分片键计算目标chunk然后把请求转发给对应shard。每个shard的副本集配置决定着你这个分片集群的数据安全等级这方面千万不能省。2.3 什么时候才真正需要分片以及什么时候千万别碰分片不是MongoDB的默认选项它是有代价的。分片之后聚合查询如果没带分片键会在所有shard上跑一遍再合并结果这种“scatter-gather”操作比单机慢得多。索引管理、备份恢复、监控告警的复杂度也会上一个台阶。所以团队里没有能Hold住分布式数据库的人之前别急着上分片。我的判断标准是三个条件同时满足再考虑分片数据量达到数TB级别、单机性能无可避免地下降、业务读写模型能够接受分片键约束。如果是几百GB且QPS不高先把索引、查询、存储引擎、副本集部署这些基本功做好分片反而会拖慢业务迭代效率。记住分片解决的是“单机装不下、扛不住”的问题不是用来炫技的。3. 动手落地一套高可用的分片集群搭建方案3.1 蓝图设计机器规划、版本选型和分片数估算我有一个经验先在白板上把拓扑画出来再动手装。别小看这一步很多后面踩的坑其实在设计阶段就已经注定了。版本选择上当时线上是MongoDB 3.6.8。如果是从0开始建议选4.2以上版本事务支持和分片相关的运维工具成熟很多。但如果你已经有存量库不要直接跨大版本升级后面坑10会专门讲。我见过不少团队贪图新版特性直接把生产库从3.x跳到5.x结果一堆兼容性报错最后只能回滚。分片数怎么定我一般按“单shard承载1TB以内”来规划。分片不是越多越好分片多了config server的元数据量也会涨mongos的转发逻辑也更重。最稳妥的做法是从3到4个分片开始观察均衡情况后再水平加shard。每个shard建议用独立机器不要和config server混布。磁盘方面我习惯按实际数据的2到2.5倍来规划否则过个半年又要扩容又得折腾一轮。3.2 分片键整个方案里第一个生死决策分片键选错后面所有的操作都是在还债。这句话我说给每一个来找我问MongoDB分片的朋友听。分片键的两个核心要求一是基数足够大字段值不能就这么几个二是业务查询要尽量带它。我举个例子按user_id做范围分片用户量大值域广绝大多数业务查询也都是按用户维度来这种就非常合适。如果用status这种状态字段做分片键状态值就0/1/2三个那每个chunk都没法继续分裂数据根本摊不开集群会变成一堆jumbo chunk的集合。另外要强调一点分片键一旦确定文档写入之后就不能修改字段值。这是很多人在设计阶段完全忽略的。你要提前想清楚业务将来会不会改这个字段否则只能用组合分片键或者接受以后“导出重导”的代价。设计分片键时我一般会拉开发一起过一遍所有核心查询的where条件看有没有一个能被大多数查询带上的字段那个字段就是候选分片键。3.3 从单机到集群的迁移能少踩坑就少踩坑迁移方案我走了不少弯路最直接的流程是这样的搭建分片集群mongos、config server、shard拓扑全部起来。用mongosh连接mongos对目标集合执行sh.shardCollection()开启分片。单机端用mongodump导出数据集群端用mongorestore导入。修改业务连接串指向mongos验证读、写、聚合、索引是否正常。这里有个细节mongodump和mongorestore在数据量大的时候非常慢。十亿级别的数据就别想了更靠谱的是用文件系统快照做物理迁移或者借助MongoDB自带的复制机制让分片集群作为单机数据源的一个从节点先全量同步再增量追平最后切换。这种方式对外部影响小回滚也方便。我自己后来一直用第二种方式比dump恢复省太多时间。刚迁移完那几天一定要盯着每个shard的chunk分布。mongorestore导入的数据极大概率都落在同一个shard上需要均衡器慢慢搬这是正常的。但如果你没有预分片这个搬运过程会非常漫长具体怎么处理我在坑6里详细说。4. 生死坑实录上架构规划期的5个致命坑4.1 坑1分片键选错热写入让集群比单机还慢先说最毒的一个坑。有段时间我发现集群的写入延迟比单机还高查了一圈才发现问题是分片键设计成单调递增的流水号范围分片导致所有新写入都集中到最后一个shard。写入全部打在一个热点shard上其他shard闲着看热闹。这种问题在监控上看不出来因为集群整体的QPS没有下降但每个shard的负载完全不一样。用db.printShardingStatus()查看或者在config库里查chunks集合一眼就能看出数据全堆在一个shard上。真正线上排查时我习惯先看每个shard的连接数、命令执行时间和chunk数量三者一对比热点分片立刻现形。解决办法分两步短期先用均衡器把已有chunk摊开但治标不治本长期要把分片键改成hashed分片或者用组合分片键把单调递增字段的分布打散。这个坑最可怕的地方在于业务规模越大迁移成本越高。等数据到了几十TB再想换分片键工程量大得能让你怀疑人生。所以架构阶段一定要把分片键的数据分布特征想清楚。4.2 坑2基数太差chunk根本无法分裂分片的基本单位是chunk默认64MB。当chunk数据量超过64MB时MongoDB会尝试把chunk一分为二。问题来了如果分片键的基数太低比如用布尔值当分片键那整个keyspace最多就两个分片区间想分裂都没有地方下刀。我见过一个团队用类别字段做分片键全表只有4个值结果数据量翻番后每个chunk都标成jumbo迁移也迁不了删除也删不动集群直接进入半瘫痪状态。当时他们想用sh.splitAt()手动切分但根本找不到可用的切分点因为每个分片键值对应的数据量都超过了chunk上限怎么切都超。遇到这种时候别想着“改一下分片键就好了”。MongoDB不允许修改分片键字段的值数据只能导出重导。所以建表前要测算分片键基数少于几百万级别的值域就要警惕了。临时估算方法很简单预计数据量除以64MB得到基础chunk数量分片键值域个数至少要比这个chunk数量高一个数量级才算是安全的。这个教训值不少钱切记。4.3 坑3范围分片遇上单调递增热点全挤在一块这个和坑1类似但很多人会搞混。范围分片本身没问题问题在于业务字段是不是单调递增的。日志表、订单表按时间戳做范围分片看起来逻辑自然实际上写入永远落在最后一个chunk热点无法避免前面分过的chunk反而成了冷数据躺在那里占磁盘。一个有效的做法是hashed分片用哈希把连续的输入打散到不同chunk写入压力可以均匀分摊到所有shard。代价是范围查询会跨多个chunk需要在所有shard上并行扫描再聚合结果性能会有一定损耗。具体损耗多大取决于你的查询筛选字段和分片键的重合度。另一个方案是组合分片键比如user_id加timestamp。这样同一个user的数据会按时间排序聚到一个chunk附近写入能分散时间范围查询也不会太差。前提是设计者吃透了业务的访问模式。我遇到过一些团队简单粗暴地选一个字段做分片键上线两个月后发现这个字段的访问频率极低大部分查询都变成全集群扫描苦不堪言。分片键一定要以查询模式为核心来设计不要只看写入分布。4.4 坑4mongos只部署一个连接数直接把路由打爆mongos是分片集群的流量入口。很多人以为mongos没什么好配的一个就够了。我在生产环境里被教训过应用连接数突然飙升单个mongos的线程和连接全部被打满新的连接直接排队超时业务侧报错一批接一批而shard本身负载其实很低。mongos本身没有状态完全可以横向扩展。生产环境我建议至少部署2到3个mongos前面用负载均衡或者直接在业务驱动的连接串里配多个mongos地址官方驱动会自己做failover和负载均衡。别嫌多这一点点冗余能换来的稳定性远超过那些机器成本。还要把mongos的进程参数调好比如maxIncomingConnections。默认值在某些场景下不够用但不建议盲目调大因为每个连接都占用线程和内存资源调太大反而可能拖垮mongos所在机器的操作系统。我是配合压测结果来调的先看清楚业务连接的峰值再留出30%左右的余量。连接数这个指标一定要放进你最核心的监控面板里。4.5 坑5config server配成光杆司令元数据成了定时炸弹config server是分片集群的“大脑”里面存着所有集合的分片键信息、chunk分布信息。3.2之后的副本集模式是强制要求的但总有人不按规矩来觉得自己用的数据量不大单节点无所谓。有人觉得config server压力小就部署一个裸节点连副本集都没有。结果节点一挂mongos全部报错整个集群不可用。还有人把config server和shard放在同一台机器上磁盘IO互相干扰元数据读写变慢直接影响所有请求的路由速度因为mongos每次路由都要从config server缓存和获取元数据信息。config server必须至少3节点副本集而且最好用独立的小机器或容器。备份策略要和业务数据同等对待该做的快照绝不能少。config server的数据量不大但恢复代价极高一旦元数据损坏整个集群的数据找回难度是你无法承受的。我在客户那边遇到过config server数据文件损坏的情况当时的恢复过程完全是噩梦级别从那以后config server在我心里的地位和业务元数据库完全对等。5. 生死坑实录下迁移与运维期的5个致命坑5.1 坑6一次性灌入历史数据chunk卡在单shard上不动从单机迁移历史数据时我先在mongos上执行了sh.shardCollection()然后启动mongorestore。一开始数据导入非常快几个小时后发现绝大多数chunk还是落在第一个shard上集群整体负载非常不均匀其他shard几乎没写入。原因在于shardCollection初始状态下只有一个chunk所有数据先写到一个shard然后等均衡器慢慢搬。你要是导入几十GB数据还好等一阵子就自动均衡了但要是一次性灌入几十亿条历史数据均衡器根本搬不过来数据一致性窗口越拉越长业务根本等不起。正确做法是预分片。在迁移数据前根据分片键的键值范围手动用sh.splitAt()把chunk拆分成多个让数据写入时直接分散到不同shard。sh.shardCollection()支持对hashed分片做自动预分片只需要指定初始chunk数量。操作时要注意预分区数量不要过大否则会产生大量空的元数据chunk均衡器后续处理它们也会消耗资源。我一般按目标shard数的整数倍来预分区比如4个shard就预分32个初始chunk让均衡压力从第一天开始就均匀分布。5.2 坑7均衡器全天候运行业务高峰撞上chunk迁移均衡器的任务是让数据均匀分布到所有shard。听起来很美好但实际问题很大均衡器迁移chunk的时候会在源shard和目标shard之间拷贝数据磁盘IO和网络带宽全部打满直接影响正常业务读写。我有一次发现线上写延迟从10ms涨到500ms一开始以为是分片键热点排查半天才发现是均衡器正在迁移大量chunk把业务高峰期的IO全吃掉了。均衡器默认是全天候运行的它可不管你的业务高峰期是什么时候只要发现chunk分布不均就开始搬。MongoDB提供了balance window配置可以限制均衡器只能在指定时间段运行。我固定把均衡窗口设在凌晨两点到五点和业务低峰期完全对齐。还有一个实用小技巧在迁移大表之前临时停掉均衡器等迁移完成再打开防止均衡和迁移互相打架导致两边都慢。操作方式很简单用sh.stopBalancer()和sh.startBalancer()就能控制。5.3 坑8write concern还在用默认值主节点挂了直接丢数据分片集群里每个shard是副本集默认write concern是w1意味着主节点写入成功就返回确认。副本集同步是异步的如果主节点在同步完成前宕机这部分数据就永远丢了。很多人只觉得MongoDB不丢数据其实这是错觉。我第一次做故障演练时专门测试了主节点kill的场景。结果令我震惊虽然从节点选举成功了但最后几百条写入的数据丢失了。业务方反馈非常直接“数据没了你们怎么做数据库的”从那以后我把核心写入的write concern调成wmajority确保大多数节点确认后才返回成功。这样做的代价是写入延迟会有所上升因为要等副本复制完才能确认但对核心业务来说这个代价完全值得。读偏好read preference也要按业务场景来设置。默认是primary读从节点只承担备份职责如果用了secondaryPreferred或者nearest要清楚这带来的数据延迟问题。特别是分片集群里不同shard的从节点延迟可能不一样读到的数据可能比主节点旧几秒。这块配置一定要和业务方对齐别让业务拿从节点的数据做实时判断那就麻烦大了。5.4 坑9备份恢复还是单机思维真到恢复的时候傻眼单机MongoDB做备份mongodump一把梭简单直接。分片集群不能这么干原因在于每个shard是独立的副本集各自dump出来的数据在时间点上对不齐。你用单机思维的备份策略恢复出来的集群很可能数据互相矛盾业务根本不敢用。我们后来改成了文件系统快照方式配合云盘快照对每个shard同时做快照尽量保证数据一致性窗口对齐。也可以在业务低峰期短暂停写几分钟再快照这样数据一致性最好。如果用的是WiredTiger存储引擎官方还提供mongod的journal配合快照能把恢复窗口控制得很小。恢复流程也要演练。真到灾难发生的时候顺序是这样的先恢复config server再恢复各shard最后启动mongos。顺序一错整个集群起不来。我专门把这个流程写成运维手册每个季度带着运维同事演练一遍。纸上谈兵没有用一定要真刀真枪地验证过恢复时长确认每个备份文件能真正被使用才算合格。我见过太多团队备份了一堆文件真到恢复的时候才发现文件损坏或者版本不匹配那才是真正的灾难。5.5 坑10版本跨度升级组件之间互相“不认识”MongoDB的版本升级和单机版本不一样分片集群牵扯到mongos、config server、shard三套组件升级顺序错了就会出现组件协议不一致的问题。我见过有人从3.2直接跳到4.0结果shard还在3.2mongos和config server已经是4.0三者通信直接失败集群起不来。官方要求的升级路径是逐版本升级不能跨大版本。每个大版本内部得先升级所有shard再升级config server最后升级mongos。这个顺序不能乱因为新版mongos向后兼容旧版shard但新版shard不一定兼容旧版mongos反过来也一样。升级期间建议先停均衡器避免元数据在升级过程中发生变化。还要检查驱动的兼容性。老版本驱动可能不认识新版本的握手协议连接会直接报错。升级前先在测试环境把驱动、Compass、DBeaver这类工具全部验证一遍确认能连上新版本集群再动生产。DBeaver连接MongoDB如果出现协议问题通常就是驱动包版本太老去官方仓库下个新版驱动包就好。这块虽然没有技术含量但确实是我遇到过最多的“升级后连不上”原因。6. 从单机到千倍容量扩容过程中的容量估算与监控6.1 容量估算不是“加机器”那么简单标题里说“千倍扩容”从单机走到分片集群容量确实可以大几个数量级但不是说一直加机器就完事。我总结了一句话先算数据再算节点最后看chunk。数据量估算要看业务增速。假设单机每天新增10GB数据一年就是3.6TB。分片集群里每个shard建议控制在1TB以内那一年后的数据就需要至少4个shard两年后就需要8个。你还要考虑索引、oplog、磁盘碎片这些额外空间。oplog的大小和副本延迟直接相关建议按2小时以上的写入量来配置。chunk数量也要估算。chunk默认64MB1TB数据约需要16000个chunk。当你增加新shard时这些chunk会被均衡器重新分配每个chunk的迁移都要拷贝数据所以新shard要提前加进去让均衡器有足够时间摊数据。临时抱佛脚式扩容往往扩容命令执行成功后数据均衡要好几天甚至几周期间集群性能反而会下降。6.2 真正重要的监控指标这几个比CPU内存更值得盯分片集群的监控不能只盯CPU和内存。我重点看这几个指标每个shard的chunk数量分布。chunk数量差太大说明均衡有问题要么均衡窗口不够要么分片键设计有缺陷要么有jumbo chunk卡住了迁移。mongos的connections。连接数打满通常是mongos不够用或者应用连接池配置不合理。副本集的复制延迟延迟过大从节点选举后数据会丢也会影响依赖从节点读取的业务。均衡器运行状态它一动IO就占用要观察是否和业务高峰重叠。磁盘使用率和可用空间分片之后磁盘满了依然会发生只是把“单机满盘”变成了“某个shard满盘”。工具方面我用过mongostat和mongotop看实时状态用MongoDB Compass做可视化诊断DBeaver连接mongos查数据分布也很顺手。Compass对日常巡检很友好能直接看到各shard的chunk分布和集合统计信息。DBeaver的优势是SQL化查询对习惯关系型数据库的人来说上手快但连接MongoDB时偶尔要手动下载驱动包第一次连的时候要耐心等它下载完成。6.3 均衡器和chunk管理的几个微调技巧均衡器的默认行为不是万能的几个微调可以解决大问题。第一设置均衡窗口不让均衡器和业务高峰抢资源。第二大表迁移前临时停均衡迁移完再启动。第三调整chunk大小64MB是默认值可以调小到32MB来增加chunk数量、加快均衡粒度但chunk太碎也会增加元数据压力和路由转发开销。反之如果业务数据单文档就很大chunk太小会导致频繁分裂这时调到128MB反而更合适。chunk大小修改要谨慎生产环境我一般不动除非遇到chunk分裂性能问题。调整chunk大小会影响后续分裂和迁移行为但不影响已有chunk的实际大小。还有一个冷门技巧如果某个集合的chunk分布已经严重倾斜且均衡器一直搬不动可以用sh.moveChunk()手动指定目标shard并带上“_secondaryThrottle”参数限流避免迁移把IO打满。手动迁移完要再查一次chunks分布确认不要移完就不管了。7. 常见问题排查速查表问题现象可能原因排查建议解决方向写入延迟升高分片键热点、chunk迁移、磁盘IO饱和查每个shard的负载和chunk分布调整分片键、设置均衡窗口集群读变慢聚合查询未带分片键触发全集群扫描查看explain是否走了targeted查询查询带分片键或接受scatter-gather成本某个shard容量告急数据增长不均匀chunk没有及时迁移查看chunks分布和均衡器状态手动moveChunk规划新增shardmongos连接超时mongos节点太少或连接数达到上限查mongostat里的connections扩mongos节点调maxIncomingConnections副本集延迟增大从节点网络差、磁盘慢、oplog窗口不足查复制延迟时间检查oplog大小优化从节点资源配置均衡器频繁迁移分片键分布异常导致chunk倾斜查看chunk数量和迁移日志预分区优化分片键避开业务高峰这张表被我打印出来贴在工位上每次集群出问题先对一遍表再去看日志。排查思路比单点工具重要因为大多数分片集群故障不是单一原因很可能是几个因素叠加导致的。比如写入慢既可能是分片键热点也可能是均衡器在迁移chunk还可能只是某块磁盘性能下降。把这几条线同时查一遍基本就能定位到真正的根因。这里有个真实案例可以分享有一次我们线上写入延迟持续偏高我按上表逐个排查发现chunk分布完全平均均衡器也没在跑最后用iostat一看某块云盘IO延时到了近百毫秒是同一物理宿主机上的邻居实例在“吵闹”导致磁盘性能严重劣化。这种情况在云环境里很容易被忽略但只要你把排查路径走完整就一定能找到真相。8. 写在最后我的个人体会从单机MongoDB一路迁到分片集群我最深的体会是分片不是灵丹妙药它是一整套工程体系。分片键的设计一定要前置宁可多花三天想清楚也不要上线后用三个月来还债。架构方案、监控告警、备份恢复、故障演练每一个环节都得在动手之前设计好不然就是在给未来的自己埋雷。我个人觉得如果团队里没有一个人真正读过官方分片文档、亲自搭过集群就不要贸然把核心库迁到分片架构。先拿历史数据、非关键业务做试点把均衡、备份、监控全部验证一遍再谈扩容。迁移的过程一定要有回滚方案别觉得“反正数据都导过去了”就万事大吉业务切换时候的运行状态和导入状态往往不一样。最后再分享一个小技巧无论多忙都要定期做故障演练。我每个月至少kill一次某个shard的主节点看集群能不能自动恢复mongos能不能正常切换路由。很多坑都是演练的时候暴露的真等线上出问题再排查成本高到你不想回忆。这篇文章里的每一个坑都是我实际踩过、或者在生产环境帮人救火时见过的。希望你看完之后在分片键设计、迁移落地、运维监控这几个环节都能少走我走过的弯路。
