上个月帮一个做商品目录的客户看他们的 MongoDB：三台物理机，256G 内存，NVMe 也上了，慢查询日志里却堆着一堆一百多毫秒的 find。登上去一查，工作集早就超过物理内存的七成，WiredTiger cache 命中率一路往下掉，eviction 线程一直忙。老板的第一反应是"上分片吧"，我劝住了——他们总数据量才 380GB，分片一上，运维复杂度翻倍，延迟一点都不会降，因为瓶颈根本不在数据分布，而在内存装不下热数据。
MongoDB 硬件选型的核心就一句话：内存有多大，热数据就有多快。WiredTiger 存储引擎把索引和热文档缓存起来，工作集装得进内存，读就是毫秒级；装不进去，每一次读都可能落到磁盘，延迟直接跳到几十毫秒甚至百毫秒级。CPU 通常不是瓶颈，除非你在跑大量聚合管道或者地理空间查询。所以这篇不讲玄学，只把内存怎么估、SSD 怎么挑、副本集与分片怎么摆、内网带宽留多少、三档数据量各花多少钱，一条条拆开说清楚。
开篇要点，先记住这五条：
一、50GB 以下别谈分片。单副本集三节点（一主两从）足够，把钱花在内存上比花在 mongos 上有用得多。
二、500GB 上下是主力副本集的舒适区。三节点、大内存、NVMe，加上一个够大的 oplog，是绝大多数团队最划算的形态。
三、5TB 且写吞吐已经压不住，才真的需要分片。很多人是"以为自己需要分片"，结果片键选错，热点全压在一个 shard 上。
四、预算优先级永远是内存 > 磁盘 > CPU。MongoDB 的单文档操作不吃 CPU，但极度吃内存命中率和磁盘写延迟。
五、oplog 窗口决定你能不能扛住一次全量初始同步。窗口太短，节点掉线一会儿就得重做全量同步，那是要吃满磁盘和内网带宽的。
MongoDB 真正顺手的场景，是那些字段经常变、结构不统一、读写以"整篇文档"为主的业务。内容管理系统的文章正文加标签加评论区，商品目录里不同品类的属性字段天差地别，用户画像里每个人身上挂的标签数量和行为序列长度都不一样——这类半结构化数据，放进关系库要么得上百张关联表，要么天天改表结构。文档模型把它塞进一个 JSON 结构里，一次读就拿到完整对象，省掉十几次 join。这里要提醒一句：文档模型省的是 join，不是内存。一个嵌套了上千条行为记录的用户文档，读一次就是几百 KB 进 cache，工作集估算时这种"大文档"最容易算漏。
第二大类场景是高频写入。日志与行为埋点、IoT 设备定时上报、游戏玩家存档，写入模型都是"只追加、很少改、按时间查"。这类业务对磁盘的要求和商品目录完全不同：写入是顺序的，但量极大，而且 oplog 也在同步写同一块盘。如果你的写入是每秒上万条，SATA SSD 的写延迟和写放大会在几个月后显现出来——尤其是开了 journal 之后，一次逻辑写背后是 journal 写加 checkpoint 写，实际落盘量远大于你看到的写入量。这类场景我一律要求 NVMe，并且要盯住 DWPD（每日全盘写入次数）这个指标，别只看容量。
第三类是地理位置业务：附近的人、门店半径检索、轨迹点查询。MongoDB 的 2dsphere 索引是 GeoJSON 结构，索引体积比普通的单字段索引大不少，而且地理查询往往是范围扫描加排序，命中不了索引就得在内存里排序，超过 32MB 的排序会直接报错。所以做地理业务的团队，估内存时要把 2dsphere 索引单独拎出来算，别按普通索引的经验值估。
数据量 50GB 以内、日增量两三 GB 的业务，一台 64G 内存的机器就能把工作集整个装进去。这种规模上分片纯属自找麻烦：mongos 要单独部署、config server 要三节点、balancer 要盯着、片键要设计，运维面翻了几倍，性能一点没涨。我的建议是三节点副本集——一主两从，主节点扛写，从节点可以分担读（注意 read preference 配错了会把读到过期数据当成 bug 查三天）。如果预算实在紧，一主一从加一个 arbiter 也能跑，但 arbiter 只投票不存数据，等于把高可用打了折扣，后面会展开说。
到了几百 GB 这个量级，单台机器的内存很可能已经装不下完整工作集了，这时候要做的第一件事不是分片，而是先把工作集算清楚。很多业务看着 500GB 数据，实际上真正被高频访问的只有最近三个月、三五十 GB，剩下的冷数据一年查不了几次。这种情况下，256G 内存的物理机依然能跑得很舒服，因为热数据全在 cache 里。真正的分界线不是"数据总量"，而是"工作集能不能装进内存 + 写吞吐是不是已经把单机的磁盘和网络压满"。500GB 数据、每秒几千次写、内存 256G，这套配置跑三五年没问题，完全没必要分片。
什么情况下必须分片？我一般看三个信号：单机磁盘撑不住数据总量（比如已经 2TB 还在每月涨 200GB）、写吞吐超过了单个主节点的 oplog 写入能力、或者单机的 checkpoint 抖动已经影响到了业务延迟。这三条里满足任意两条，就该认真做分片方案了。只满足一条，尤其是只因为"数据量大"就分片，十有八九是过度设计——分片解决的是横向扩展能力，不是"数据多"这个感觉。一个 3TB 的日志库，如果查询只查最近七天，那它本质上还是个小工作集业务。
工作集（working set）指的是一段时间内被反复访问的数据和索引的总量，不是你数据库的总大小。估算思路可以复算，不需要拍脑袋：索引部分用 db.collection.stats() 里的 indexSizes 直接拿到每个索引的字节数，把所有集合的索引加起来就是索引总量；热文档部分看你业务的时间窗口，比如"最近 90 天被访问过的文档"，用集合的 avgObjSize 乘以这段时间的活跃文档数就能估出来。两个数字相加，再乘一个 1.2 到 1.3 的余量，就是你对内存的最低要求。这个算法不精确，但它能把你从"感觉要 128G"拉回到"算出来要 180G"，差别很大。
WiredTiger 的 cache 默认取两个值里较大的那个：物理内存的 50% 减去 1GB，或者 256MB。也就是说一台 256G 内存的机器，cache 大概在 127G 左右。这个默认值是保守的，可以通过 storage.wiredTiger.engineConfig.cacheSizeGB 调大，但我一般不建议超过物理内存的 70%。原因有三：操作系统需要页缓存去做文件系统的读写缓冲和 mmap；连接数上来之后每个连接都有栈和缓冲开销，几千个连接能吃掉几个 G；备份工具、监控 agent、mongos（如果同机部署）也要内存。给太满，一旦触发 OOM，mongod 被系统杀掉的后果比慢一点严重得多。稳妥的做法是 cache 给到 60% 到 65%，剩下的留给系统和其他进程。
判断内存够不够，别只看监控上的内存使用率，要看 WiredTiger cache 的命中与淘汰。用 db.serverStatus().wiredTiger.cache 可以看到 pages read into cache 和 pages read from disk 的比例，前者里从磁盘读的占比持续偏高，就说明工作集没装下。另一个更直观的信号是 eviction 相关的线程持续忙碌、bytes currently in the cache 长期贴近上限。出现这些现象，加内存的效果立竿见影；而加 CPU 核数基本没用——这是 MongoDB 和很多关系库最大的不同。
oplog（operations log）是主节点记录所有写操作的定长集合（capped collection），从节点靠拉取 oplog 来追数据。它是循环覆盖的，所以能覆盖多长时间，取决于你写多快、oplog 给多大。窗口太短的后果很实在：一个从节点宕机或者因为维护下线几小时，再上线时发现它需要的那段 oplog 已经被覆盖了，那就只能做 initial sync（全量初始同步）——把整个数据集从主节点重新拷一遍，几百 GB 走内网，磁盘写入和网络带宽一起吃满。我的经验是，oplog 窗口至少要覆盖 24 到 72 小时的写入量，做跨城部署的团队要按 72 小时以上算。oplog 大小可以用 db.getSiblingDB("local").oplog.rs.stats() 看，改大小要重启并重做 oplog，属于要提前规划的操作。
MongoDB 的实际落盘量比逻辑写入量大：journal 先写一份，checkpoint 再把脏页刷一次，WiredTiger 的压缩在写路径上还要做一次处理。粗略地说，逻辑写 1GB，落到盘上可能是 2 到 3GB，这就是写放大。消费级 SSD 的 DWPD 通常是 0.3 左右，企业级能到 1 甚至 3，意味着每天可以全盘写 1 到 3 次还保五年寿命。一个每天写 500GB 的日志库，配 1.92TB 的盘，消费级盘可能一两年就到达寿命上限，企业级盘则还有余量。这笔钱别省，盘写挂了要做全量同步，业务停摆的时间比盘贵得多。
结论很直接：主节点和从节点的数据盘一律 NVMe，SATA SSD 只适合做备份盘或者部署在延迟不敏感的归档节点上，机械盘在 MongoDB 的生产路径上基本没有位置——随机读延迟是毫秒级，一旦工作集没装下，落盘读就是灾难。容量方面，别只看当前数据量，要按"数据量 × 2 + 一年的增长"来配，因为 WiredTiger 的压缩能省掉一部分空间，但备份、临时文件和初始同步期间的临时数据都要占地方。多盘的意义不只是容量：RAID 或者多块盘分摊 IO，能让 checkpoint 的写入抖动不至于直接打到业务延迟上。一万网络的裸金属可以按需加盘，加之前先问清楚是 NVMe 还是 SATA，这两个在 MongoDB 上的表现差着一个量级。
三节点副本集（一主两从）是官方推荐也是行业常态，因为它能在任意一台机器宕机时自动完成选举，剩下两台依然构成多数派（2/3），数据还有完整的一份副本加一份副本。两副本加一个 arbiter 看起来也是三票，也能选举，但 arbiter 不存数据，所以真正的完整数据只有两份，一旦主节点和一个从节点同时出问题，你就只剩一份数据而且没有自动恢复能力。arbiter 适合的是"第三个机房实在放不下完整数据"的过渡方案，或者测试环境省成本。生产环境省这个钱，等于把高可用打折卖掉。真要省钱，我宁可把第三台配成延迟从节点（priority 0、hidden），它至少还存着一份完整数据。
副本集成员之间默认每 2 秒发一次心跳，选举超时（electionTimeoutMillis）默认 10 秒。也就是说，主节点失联超过 10 秒才会触发选举，加上选举本身的时间，故障切换通常是十几秒到几十秒。如果你的节点分布在两个城市，跨城公网链路抖动一下就可能是几百毫秒甚至几秒的延迟，心跳偶尔丢一两个包不至于触发选举，但网络质量差的时候会反复出现"疑似主节点不可用"的状态，从节点的读也会跟着抖。所以生产环境我要求 mongod 之间走同机房内网互联，跨城的那台只做延迟副本或者备份节点，不要参与选举。同机房内网延迟通常在一毫秒以内，心跳稳定，选举行为也可预测。
两个最吃内网带宽的动作，一个是新节点的 initial sync，一个是分片集群的 chunk 迁移。initial sync 要把整个数据集拷过去，500GB 的数据在 1Gbps 内网上理论要一个多小时，实际还要算上建立索引的时间，往往更久；如果是 10Gbps 内网，十几分钟就能拉完。分片集群的 balancer 迁移 chunk 是常驻行为，数据分布不均时会持续搬数据，占用的是 shard 之间的带宽和磁盘 IO。所以我给的建议是：副本集节点之间至少 1Gbps 内网，分片集群的 shard 之间上 10Gbps，而且不要和业务流量抢同一张网卡。一万网络这类自营机房，同账号下的机器走内网互联不额外计流量，这一点对 MongoDB 这种"机器之间说话比机器对外说话还多"的系统特别划算。
最经典的片键错误是用自增 ID 或者时间戳做 shard key。MongoDB 按片键范围切 chunk，单调递增的片键意味着新写入永远落在范围的最大端，也就是最后一个 chunk 上，所有的写压力全部压在一个 shard 上，其他 shard 闲着。这个现象叫写热点，表现出来就是集群整体资源用了一半，但写入延迟高得离谱。正确的做法是 hashed shard key 或者复合片键：把高频查询的字段放在前缀，后面接一个有区分度的字段来打散写入。比如 { tenantId: 1, _id: "hashed" }，既保证了按租户的查询能路由到少数 shard（targeted query），又避免了写入集中。
chunk 默认 64MB（新版本默认已提高到 128MB 上下，具体看版本配置），超过阈值会触发分裂。但如果一个 chunk 里所有文档的片键值完全一样，它就永远无法分裂，成为 jumbo chunk。jumbo chunk 不能被 balancer 迁移，于是那个 shard 上的这块数据就永远挪不走，数据分布慢慢失衡。产生 jumbo chunk 的典型原因是片键的基数太低——比如用"城市"做片键，一个超大城市的文档全在一个值上。所以选片键时一定要看基数：片键的取值范围要足够大、分布要足够均匀，这是分片设计里最不该偷懒的一步。
分片上了之后，你要维护的东西立刻多出来：mongos 路由层（而且要多个实例做负载）、config server 三节点（它本身就是一个副本集，挂了整个集群不可写）、balancer 的窗口配置、每个 shard 各自的备份与监控。而且查询行为会变：没有带片键的查询会变成 scatter-gather，mongos 要把请求发给所有 shard 再归并结果，延迟可能比不分片还高。我见过太多团队在数据量刚过 200GB 时就把分片上了，之后半年一直在调 balancer 窗口和追 scatter-gather 的慢查询。判断该不该分片，就盯住前面那三个信号：容量撑不住、写吞吐压不住、checkpoint 抖动影响业务。三个里没占两个，别上。
mongos 是无状态的路由进程，本身不存数据，只从 config server 拉元数据做路由。所以最合理的部署方式是把 mongos 和应用服务器放在一起，或者放在应用同机房的独立小机器上——这样应用到 mongos 的链路最短，mongos 到 shard 走内网。把 mongos 单独放一个机房、让应用跨城访问它，是典型的自找延迟。config server 则相反，它是有状态的（存着 chunk 分布元数据），必须部署成三节点副本集，和 shard 放在同样的网络环境里，而且不要和 shard 混在同一台物理机上——config server 挂了，集群的元数据就不可写，chunk 迁移和分裂都会停。
同城三机房是最省心的方案：延迟一两个毫秒，心跳稳定，任意一个机房断电，另外两个机房自动选主，业务几乎无感。两地部署（比如深圳加上海）看起来容灾级别更高，但跨城链路的延迟通常在十几到三十毫秒之间，写多数派（write concern majority）的确认要等到两个城市都写完，写延迟会明显上升。我的建议是：生产写节点放同机房内网互联，异地放延迟副本做灾备，异地节点设 priority 0 且不参与选举，避免跨城抖动误触发切换。真正做到两地三中心自动切换的团队，需要非常扎实的网络和运维功底，小团队不要为了"看起来高级"去够这个架构。一万网络在华南、华东、华北、中国香港以及海外都有节点，做同机房内网互联的 MongoDB 集群是最常见的落地形态，跨节点的备份与容灾可以在同账号下用内网互联完成。
下面这张表把前面讲的原则落到具体档位上。价格一列，凡官网明示的起步价我直接标注来源，整集群的合计属于按档位推算，一律标「（预估）」并说明以咨询或下单时核算为准。三档之间不是"越贵越好"，而是对应不同的数据量级与运维复杂度，选错档位的浪费远比档位本身的价格差大。
| 配置档位 | 适用数据量 | 硬件规格建议 | 部署形态 | 月付参考 |
|---|---|---|---|---|
| 单副本集入门 | 50GB 以内，日增 < 3GB | 8–16 核 / 64G 内存 / 1×960G NVMe / 1Gbps 内网 | 同机房三节点（一主两从） | 华南裸金属 ¥799 起、华东 ¥699 起（官网明示起步价，以官网实时价为准） |
| 三节点主力副本集 | 100GB–800GB，工作集 < 内存六成 | E5-2698v4×2 / 128–256G 内存 / 2×1.92T NVMe / 10Gbps 内网 | 同机房三节点 + 异地延迟备份节点 | 单台裸金属 E5-2698v4×2 ¥3999 起（官网价）；三节点整集群 ¥1.4万–2万（预估，以咨询/下单时核算为准） |
| 分片集群 | 1TB–5TB+，写吞吐 > 5000 ops/s | 每 shard 同主力档 / config server 三节点 / mongos 与应用同机 / 10Gbps 内网 | 2–3 个 shard × 三副本 + 3 台 config + mongos | 整集群 ¥3万–5万（预估，非官网报价，以咨询/下单时核算为准） |
关于年付：行业通行的做法是年付比月付省一到两个月，折算下来大约 83 到 92 折（预估，以咨询时政策为准），GPU 定制类官网明示年付 8 折、H100 整机年付 85 折，裸金属海外还有买一送一的限时活动。MongoDB 这种一跑就是几年的业务，年付通常划算，但签约前一定把"中途降配、迁机房、加盘怎么算"写进合同。
关键词维度：E5-2698v4×2 | 256G 内存 | 双 NVMe | 10Gbps 内网互联 | 深圳南山自营机房 | 7×24 中文工单
推荐配置：三台同配物理机，每台双路 E5-2698v4（合计 40 核 80 线程）、256G DDR4 ECC、2×1.92TB 企业级 NVMe（一块跑数据、一块分担 journal 与备份）、双口 10Gbps 内网互联。系统盘走免费的每日三份快照，30 秒可回滚——MongoDB 升级版本或者改 oplog 大小之前，先打一份快照，比任何方案都管用。WiredTiger cache 按 256G 的 60% 配，约 150G，工作集 100G 上下的业务跑起来非常从容。
价格参考：单台裸金属 E5-2698v4×2 ¥3999 起（官网明示价，以官网实时价为准），三节点按档位推算整集群约 ¥1.4万–2万/月（预估，以咨询/下单时核算为准）。一万网络深耕 IDC 19 年、成立于 2007 年，总部在深圳南山，自营机柜最快 1 分钟上架，硬件故障 10 分钟自动迁移，7×24 中文工单平均 5 分钟响应——MongoDB 这种"主节点挂了要马上有人管"的系统，响应速度比配置表更重要。另外免费送 5–20G DDoS 防护和网站备案协助，省掉一堆杂事。
适配场景：商品目录、内容管理、用户画像、SaaS 多租户的主库；数据量 100GB 到 800GB，读写混合，要求主节点故障后几十秒内自动完成选举。
关键词维度：3 shard × 三副本 | config server 三节点 | mongos 与应用同机 | 10Gbps 内网 | BGP 多线 + CN2 优化回国
推荐配置：2 到 3 个 shard，每个 shard 一套三副本（共 6–9 台主力档物理机），config server 单独三节点（配置可以低一档，但必须独立且三副本），mongos 部署在应用服务器同机房。shard 之间、shard 与 config 之间全部走 10Gbps 内网互联，因为 balancer 迁移和 initial sync 都要吃这条链路。片键在设计阶段就要定死，上线后再改片键（resharding）代价极大。
价格参考：整集群按档位推算约 ¥3万–5万/月（预估，非官网报价，以咨询/下单时核算为准）。如果业务还在验证期，我更建议先租主力副本集三节点跑半年，确认写吞吐真的压不住了再扩分片——一万网络支持随时加机器，同机房内网互联，扩容不用重新拉链路。
适配场景：IoT 海量上报、日志与行为埋点归档、游戏全区玩家数据；单表过 TB、写入持续上万 ops/s、且查询大多能带上片键前缀。
为什么坑：很多团队看到 db.stats() 里 800GB 就去租 1TB 内存的机器，预算直接爆掉；或者反过来，看到只有 200GB 就租 64G 内存，结果索引加最近三个月的活跃文档就 90G，cache 命中率一路掉到八成以下，慢查询成堆。
怎么避：用 indexSizes 加 avgObjSize 按时间窗口算一遍，得出一个能复算的数字，再乘 1.2 的余量。按工作集买内存，剩下的冷数据交给磁盘。这个数字每次业务有大版本改动都要重算一次。
为什么坑：MongoDB 的写放大让实际落盘量是逻辑写入量的两到三倍，SATA SSD 的写延迟和 DWPD 扛不住长期高频写入；机械盘更糟，工作集一旦溢出，随机读是毫秒级，整个集群的 P99 延迟会难看到没法看。
怎么避：主节点和从节点的数据盘只选企业级 NVMe，盯住 DWPD 指标（建议 1 以上），容量按"数据量 × 2 + 一年增长"配。备份盘可以用 SATA SSD 省点钱，但别放到写路径上。
为什么坑：oplog 默认大小是按物理内存的一定比例分配的，很多机器上只有几个 G。写入一上来，窗口可能只有两三个小时。从节点重启、机房割接、一次稍长的主从切换，都可能让节点追不上，被迫做全量初始同步——几百 GB 的数据重传，磁盘和网络一起被吃满，业务延迟跟着抖。
怎么避：上线前按写入速率算好 oplog 需要多大，目标窗口是 24 到 72 小时，跨城部署按 72 小时以上算。改 oplog 要提前规划，别等出事了再动。
为什么坑：arbiter 只投票不存数据，等于你只有两份完整数据却以为自己有三份容灾。主节点和唯一的数据节点同时出问题时，没有自动恢复能力，只能靠备份重建，恢复时间不可控。
怎么避：生产环境老老实实上三个数据节点。实在预算有限，把第三个节点配成延迟副本（priority 0、hidden、延迟同步），它至少存着一份完整数据，还能当误删数据的后悔药。
为什么坑：副本集心跳默认 2 秒一次、选举超时 10 秒，跨公网链路的抖动会让你反复看到"疑似主节点不可用"的告警；initial sync 和 balancer 迁移还会把公网带宽吃满，同时拖慢业务流量。
怎么避：所有 mongod 之间走同机房内网互联，跨城的节点配成不参与选举的延迟副本。一万网络同账号下的机器走内网互联，不额外计流量，这也是我推荐把 MongoDB 集群整套放在同一个服务商、同一个机房的原因。
看工作集不看总量。把所有集合的 indexSizes 加起来得到索引总量，再用 avgObjSize 乘以最近一个月的活跃文档数得到热文档量，两个相加乘 1.2 就是内存下限。按你这个描述，索引可能 40–60G，最近一个月的热数据几十 G，那 128G 内存基本够用，256G 更从容。真正要警惕的是聚合管道和排序——它们会在内存里临时放大数据，超过排序阈值会直接报错而不是变慢，这类业务要在内存上再留一档余量。
不建议。默认取 50% 减 1GB 与 256MB 中的较大值，手动调到 60%–65% 是比较稳的区间。剩下的内存要给操作系统页缓存、连接缓冲、备份与监控进程，如果 mongos 同机部署还要再留一块。给到 80% 短期看着命中率漂亮，一旦连接数暴涨或者跑一次全量备份，OOM 杀掉 mongod 的代价远大于命中率提升带来的收益。真要判断够不够，看 cache 的 pages read from disk 占比，而不是看内存使用率。
值得，而且是优先级很高的那种值得。差的不只是顺序吞吐，更重要的是写延迟和队列深度下的稳定性。MongoDB 开启 journal 后一次逻辑写背后是多次落盘，SATA SSD 在高队列下延迟会爬升，checkpoint 期间的抖动会直接反映到业务 P99。再加 DWPD 这个寿命指标：消费级盘 0.3 DWPD 撑不住日志类业务每天几百 GB 的写入，企业级 NVMe 的 1–3 DWPD 才能扛住三五年。这笔钱是花在"不出事"上，不是花在跑分上。
800GB 本身不构成分片的理由。判断标准看三条：单机磁盘撑不住总量且增长很快、写吞吐已经超过单个主节点 oplog 的写入能力、checkpoint 抖动开始影响业务延迟。三条里占两条才该认真做分片方案。你们 800GB 如果工作集只有 100G、每秒写入几千次，那加内存和换 NVMe 的效果远好过分片。分片不是性能银弹，它带来 mongos、config server、balancer 一整套新组件，还有 scatter-gather 查询的额外延迟。
新版本支持 resharding，可以在线改片键，但你要清楚代价：resharding 期间要复制整份数据、吃满磁盘 IO 和内网带宽，整个过程对在线业务是有影响的，而且耗时可能以天计。所以片键一定要在设计阶段定死，别想着"先上再说，以后再改"。选片键的三个要点是基数足够大、分布足够均匀、并且能覆盖主要查询模式——高频查询带不上的片键，会让 mongos 把请求广播给所有 shard，延迟比分片前还差。
我的建议是别在自动化上够太远。生产三节点放同机房内网互联，保证心跳和选举稳定；异地放一个延迟副本（priority 0、hidden），专门做灾备和误删恢复。跨城链路十几到三十毫秒的延迟，会把 write concern majority 的确认时间拉长，写延迟明显上升，而且链路抖动还可能误触发选举。真正做到两地自动切换，需要很强的网络和运维能力，小团队硬上多半是把自己绕进去。一万网络在华南、华东、华北、中国香港及海外都有节点，做同机房主集群加异地备份节点是最常见的落地方式。
最稳的办法是加节点而不是搬数据：先在目标机房加一个从节点，让它做 initial sync 追平数据，追平后把它的 priority 提上去、把原主节点降下来，再下线旧节点。整个过程业务不中断，回滚也简单。直接导出导入（mongodump/mongorestore）只适合小库，大库这么干一是慢，二是恢复期间索引要重建，耗时可能比同步还久。搬之前记得把 oplog 窗口调大，避免同步期间窗口被覆盖导致重做。一万网络的自营机柜最快 1 分钟上架、硬件故障 10 分钟自动迁移，加节点扩缩容这件事本身不难，难的是提前把 oplog 和内网带宽算清楚。
说点得罪人的话：相当一部分团队上 MongoDB，是因为"JSON 看着方便"，而不是因为业务真的匹配。如果你的核心场景是订单、账务、库存扣减这类强一致事务，或者业务里充满了十张表以上的关联查询和复杂的报表统计，MongoDB 会让你痛苦——多文档事务虽然有，但代价明显高于关系库，而且会加重 oplog 与写放大；复杂关联在文档模型下只能靠多次查询加应用层拼装，或者用 $lookup，性能通常不如一次优化过的 SQL join。这类业务请老老实实用关系型数据库，把 MongoDB 放在它擅长的位置上：半结构化内容、高频写入的日志与埋点、需要灵活字段的画像与目录。技术选型里最贵的错误不是选错数据库，是选错了之后硬撑三年。
本文涉及的一万网络产品规格、服务承诺与价格，参考自一万网络官网公开页面（裸金属服务器、一万云弹性云、华南/华东/华北/华西各节点起步价、中国香港自营服务器、GPU 定制与 AI 算力云、服务与响应承诺等栏目）：https://www.idc10000.net/ 。文中标注「起」的为官网明示起步价，以官网实时价为准；标注「（预估）」的整集群合计与折扣区间为按档位推算，非官方报价，以咨询或下单时核算为准。硬件规格建议基于 MongoDB 官方文档对 WiredTiger、副本集与分片集群的通用要求整理，实际配置请结合自身工作集与写入模型评估，具体以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
