分片集群生产环境必须显式配置persistence：shardPodSpec用multiple隔离data（≥20Gi）、journal（2Gi）、logs（3Gi）并指定storageClass；configSrvPodSpec强制single且PVC≥10Gi；mongos和backup不支持persistence。
分片集群的持久化存储不能靠默认配置撑住生产环境，必须显式声明 persistence 并按组件拆分策略。
shardPodSpec 中 persistence: multiple 是刚需
每个分片（mongod）节点的数据、日志、journal 必须隔离存储，否则扩容、故障恢复或 PVC 调整时会互相干扰。用 single: true 看似省事，但实际会导致 journal 和 data 共享同一 PV，IO 争抢严重，且无法单独扩 data 容量。
-
data存主数据，建议至少"20Gi"起，配合storageClass显式指定（如"gp3"或"standard"） -
journal建议固定"2Gi"，太小易触发写阻塞，太大浪费空间 -
logs可设为"3Gi"，避免日志打满导致 Pod 驱逐 - 所有子项都必须带
storageClass，Operator 不会 fallback 到 default StorageClass
configSrvPodSpec 必须用 persistence: single
配置服务器副本集（CSRS）对一致性要求极高，多个 PV 会引入挂载顺序和 readiness 不一致风险。官方文档明确要求 config server 使用单卷 —— 所有数据、journal、日志共存于一个 PVC。
- 不要尝试在
configSrvPodSpec下套multiple，Operator 会拒绝校验 -
storage建议不低于"10Gi"，因为 config server 会缓存整个集群元数据（分片路由表、chunk 分布等） - 必须确保该 PVC 绑定的 PV 支持
ReadWriteOnce，且底层 storageClass 开启allowVolumeExpansion: true
mongos 和备份组件不支持 persistence 字段
mongos 是无状态代理，Operator 根本不提供 persistence 配置入口；备份守护进程（backup CR）也只挂临时卷。强行加字段会导致 CR 创建失败，报错类似：ValidationError(MongoDB.spec.mongosPodSpec): unknown field "persistence"。
- 如果需要保留 mongos 日志，只能通过 sidecar 容器 + emptyDir 或 hostPath 挂载，但不推荐用于生产
- 备份数据应落盘到对象存储（如 S3、OSS），而非本地 PVC —— Operator 的 backup CR 默认走云存储路径
- 别被 statefulset 表象误导：mongos 的 Pod 名字虽带序号，但它不是真正意义上的有状态服务
StorageClass 必须提前验证 allowVolumeExpansion
线上扩容 data PVC 时，如果底层 StorageClass 没开 allowVolumeExpansion，kubectl patch 会静默失败，PVC status 一直卡在 Pending，Pod 不重启，但新容量不会生效。
- 检查命令：
kubectl get sc <name> -o yaml | grep allowVolumeExpansion</name> - 开启方式：
kubectl patch sc <name> --type='json' -p='[{"op": "add", "path": "/allowVolumeExpansion", "value": true}]'</name> - 注意：某些云厂商（如 AWS EBS）要求先 unmount 再扩容，Operator 的滚动重启机制能自动处理，但你要确认节点上没有其他进程占用该卷
最常被忽略的是 config server 的 PV 容量预估——它不随数据量线性增长，但随着分片数、数据库数、集合数增加，元数据体积会指数上升；上线前用 db.printShardingStatus() 估算当前大小，再乘以 2～3 倍作为初始值。
