配置服务器副本集必须显式配置clusterRole: configsvr，启动时未指定将报错InvalidOptions；名称不得与分片副本集重名；须为多节点副本集且先完成rs.initiate()并确认状态稳定后，再通过sh.addShard()添加。
配置服务器副本集必须用 configsvr 角色
配置服务器不是普通副本集，mongod 启动时必须显式指定 clusterRole: configsvr，否则无法加入分片集群。这个参数不能靠 rs.initiate() 补救，启动失败会直接报错 InvalidOptions: clusterRole must be 'configsvr'。
- 配置文件中写法：
sharding: { clusterRole: "configsvr" } - 命令行写法：
mongod --configsvr --replSet cfgRepl --dbpath /data/cfg1 --port 27019 - 名称不能和任何分片副本集重名，比如分片用了
shard1，配置服务器就不能叫shard1，否则sh.addShard()会拒绝添加
分片节点本身必须是副本集，不能是单节点
生产环境所有分片都必须是副本集，sh.addShard("shard1/10.0.0.1:27017,10.0.0.2:27017,10.0.0.3:27017") 这种格式才合法。如果传入单个地址如 "10.0.0.1:27017"，mongos 会报错 cannot add shard with no replica set name。
- 每个分片副本集的
replSetName必须和sh.addShard()中 URL 里的名称一致 - 副本集内所有成员的
bindIp必须包含可被其他集群节点解析的主机名（DNS），不能只写127.0.0.1或localhost；MongoDB 5.0+ 会直接拒绝启动 - 建议至少 3 节点（1 主 2 从），避免使用仲裁节点（
arbiterOnly: true）——它不存数据，无法在分片故障时提供冗余
初始化顺序不能颠倒：先配好副本集，再加到集群
常见错误是没等副本集状态稳定（rs.status() 显示 PRIMARY + SECONDARY）就急着执行 sh.addShard()，结果 mongos 会卡住或报 not master and slaveOk=false。
- 每组分片副本集要单独完成
rs.initiate()和成员添加，确认rs.status().members[n].stateStr全是PRIMARY或SECONDARY - 配置服务器副本集也必须先
rs.initiate()成功，且至少一个成员状态为PRIMARY，mongos才能连上 -
mongos启动时必须通过--configdb cfgRepl/cfg1.example.net:27019,cfg2.example.net:27019,cfg3.example.net:27019指向配置服务器副本集全地址列表，不能只写一个
验证分片集群是否真正可用，别只看 sh.status()
sh.status() 显示分片列表和块分布，但容易掩盖底层问题。真正要检查的是三件事：
- 连接
mongos后执行db.runCommand({isMaster: 1})，返回里必须有"msg":"isdbgrid"，说明当前连的是 mongos 而非普通 mongod - 插入测试数据后查
sh.status()的chunks分布，如果所有 chunk 都堆在一个分片上，说明片键选择不当或没触发自动分片 - 手动停掉一个分片的 PRIMARY，观察是否自动选举出新主、
mongos是否继续接受写入（需客户端设置w: "majority"并重试）
最常被忽略的是 DNS 解析一致性——所有节点的 /etc/hosts 或 DNS 记录必须完全一致，否则某个分片看似在线，实际 mongos 根本连不上它的 SECONDARY，导致写入超时或选举失败。
