主备切换后磁盘挂载点丢失本质是新主节点未按预期挂载存储，需分三层排查：先用lsblk或fdisk确认设备是否识别，再用blkid核对fstab中UUID和TYPE是否匹配，最后用mount -a验证配置并检查挂载点路径一致性。
主备切换后磁盘挂载点丢失，本质不是数据丢了，而是新主节点没按预期把共享存储或本地数据盘挂上去。排查要聚焦“设备是否识别、配置是否生效、路径是否一致”三层。
确认备机是否识别到原主用磁盘
主备切换后，先别急着改fstab，先看底层设备是否存在：
- 运行 lsblk -f 或 fdisk -l，重点看是否有 /dev/sdb1、/dev/nvme0n1p2 等原主节点使用的设备名；若完全不显示，可能是共享存储未映射（如iSCSI未登录、SAN zone未开通）或云平台未透传设备
- 若设备存在但没文件系统信息（TYPE为空），说明可能未格式化、分区表损坏，或内核未刷新——执行 partprobe /dev/sdb 或 blockdev --rereadpt /dev/sdb 后再跑 blkid
- 对共享盘（如多路径设备），检查 ls -l /dev/mapper/ 或 multipath -ll，确认WWID一致且状态为 active
比对fstab中设备标识与当前实际UUID
主备节点硬件环境不同，/dev/sdX 编号极易变化，必须用UUID才能可靠绑定：
- 在新主节点上运行 blkid，找到目标分区的 UUID= 和 TYPE= 值
- 打开 /etc/fstab，核对对应挂载项：设备字段是否仍写的是 /dev/sdb1？→ 必须替换为 UUID=xxx
- 检查挂载点目录是否存在（如 /data/mysql），不存在就 mkdir -p /data/mysql
- 确认 TYPE 字段（如 xfs、ext4）和 blkid 输出严格一致，大小写敏感
验证fstab语法并检查挂载时机冲突
即使配置正确，也可能因启动顺序或依赖关系失败：
- 执行 sudo mount -a 测试全部 fstab 条目，报错会直接指出哪一行、什么错误（如 “wrong fs type”、“no such device”）
- 若手动 mount /dev/sdb1 /data 成功，但 mount -a 失败，大概率是 fstab 中第5、6列缺失或写错（应为 0 0）
- 查日志定位深层原因：dmesg -t | grep -i "sd\|nvme\|i/o" 看硬件层是否报错；journalctl -u systemd-fstab-generator 查 systemd 是否跳过了该条目
- 注意：某些高可用方案（如 Pacemaker）会接管挂载，此时 fstab 应留空，挂载由资源代理控制——需确认 HA 配置中是否定义了 Filesystem 类型资源
检查主备节点挂载点路径一致性
路径不一致会导致服务找不到数据，看似“丢失”，实为错位：
- 对比原主节点的 findmnt /data 输出和新主节点的挂载点，确认是否都指向同一物理路径（如 /data 而非 /mnt/data）
- 若应用（如 MySQL）配置文件里硬编码了数据路径，而新主节点挂载到了 /data2，则需同步修改应用配置，或统一挂载点
- 云环境特别注意：部分平台（如阿里云）在主备切换后，数据盘设备名可能从 /dev/vdb 变为 /dev/xvdb，仅靠设备名不可靠，必须用 UUID 或 /dev/disk/by-id/
