多台物理机容器并发挂载同一网盘直写会引发数据覆盖、索引损坏或崩溃，因ext4/xfs等本地文件系统不支持多节点并发写；正确做法是采用mysql group replication、pxc等集群方案，或使用lustre/cephfs等分布式文件系统，或通过vip读写分离、分布式锁等隔离层控制访问。
直接让多台物理机的容器并发挂载同一块网盘（如 nfs 共享目录、iscsi lun 或云共享云盘）并同时写入，极易引发数据覆盖、索引损坏甚至数据库崩溃——这不是配置问题，而是底层文件系统不支持并发写的安全边界问题。
根本原因：文件系统不允许多节点直写
ext4、xfs 等本地文件系统设计为单主机独占访问。即使挂载的是“共享存储”，只要两台主机上的进程（比如两个 MySQL 实例）同时 open+write 同一数据文件（如 ibdata1、.frm），就可能造成：
- 元数据（inode、block bitmap）被不同主机各自修改，最终冲突覆盖
- MySQL 的 WAL 日志或页缓存未同步刷新，导致事务状态不一致
- 文件系统检查（fsck.ext4）发现 multiply-claimed blocks，修复后仍无法启动服务
正确做法：用集群感知型方案替代裸挂载
不要让多个 MySQL 容器“自己决定怎么写”，而应交由具备分布式协调能力的组件统一管理数据访问：
- 用高可用数据库集群代替双主挂盘：部署 MySQL Group Replication、Percona XtraDB Cluster（PXC）或 MGR，节点间通过 Paxos 协议同步事务，而非共享磁盘
- 使用支持并发读写的分布式文件系统：如 Lustre、CephFS 或 GPFS，它们在内核层实现锁管理与元数据一致性，可安全挂载给多台主机
- 改用共享云硬盘 + 集群文件系统：华为云/阿里云等提供的共享云硬盘，需配合 GFS2 或 OCFS2 使用，并配置 fencing（如 QDevice）防止脑裂
若必须用 NFS 类共享存储，请加隔离层
NFS 本身只提供“网络文件访问”，不提供“并发控制”。要降低风险，必须引入应用层或中间件层约束：
- 只允许一个节点写入，其他节点仅挂载为只读（ro），通过 VIP 或 DNS 切换写入节点
- 在应用中集成分布式锁（如 Redis Lock 或 Etcd），确保同一时刻仅一个容器获得写权限
- 避免挂载整个 MySQL data 目录，改为只共享备份目录、日志归档目录等非结构化路径
已发生覆盖后的紧急处理
一旦发现 MySQL 启动失败、报错“Tablespace is missing”或“InnoDB: Database page corruption”，立即执行：
- 停止所有挂载该存储的主机，禁止任何写操作
- 在一台主机上 umount 存储，运行 fsck.ext4 -f /dev/xxx（注意：仅适用于 ext4，且需确认无其他节点正在挂载）
- 尝试用 innodb_force_recovery=1~6 启动 MySQL，导出可用数据
- 从最近一次完整逻辑备份（mysqldump 或 mydumper）恢复，而非依赖损坏的物理文件
