知识卡片
Config Server纳入复制集：元数据节点同样需要共识机制，不能只是互相无感知的多副本
内容
MongoDB自动分片架构依赖Config Server保存分片元数据（哪些数据分布在哪些分片上），但早期版本的多个Config Server节点彼此是互相无感知的独立个体，既没有统一的一致性保证，扩容或迁移时（尤其是要更换某个节点的hostname时）操作起来也异常痛苦，因为没有一套机制能保证多个Config Server节点看到的元数据是一致的。3.2版本让Config Server也支持复制集模式，写入要求多数派（Majority）确认、读取默认走Primary，才真正解决了这个一致性和高可用问题。这个演进给出一条容易被忽视的启示：系统里负责保存”元数据/配置信息”的组件，即使它自身不直接承载业务数据的读写压力，也同样需要像业务数据存储一样纳入正规的复制与共识机制，”元数据节点只是几个互相独立摆放的副本”这种朴素方案，本身就是潜在的一致性和运维风险点。
参考来源
- 位置：《高可用架构（第1卷）》第6章《大数据与数据库》"6.11 MongoDB2015回顾：全新里程碑式的WiredTiger存储引擎"节，"6.11.3 自动分片机制"（源文件：_epub-src/OEBPS/Text/Chapter6_11_4.xhtml）
- 结论依据：原文说明"对于自动分片的话，最大的一个改进是Config Server支持复制集模式。Config Server从3.2版本开始支持复制集模式，在这之前Config Server的多个节点间是彼此无感知的，不仅有可能出现一致性问题，扩容和迁移时也会非常痛苦，尤其是在更换hostname的情况下"，直接支撑本卡片结论。
- 原始内容：Config Server从3.2版本开始支持复制集模式，在这之前Config Server的多个节点间是彼此无感知的，不仅有可能出现一致性问题，扩容和迁移时也会非常痛苦，尤其是在更换hostname的情况下。