主从服务器故障切换要稳，存储配置必须跟切换动作绑成一套自动或半自动流程，否则应用切过去了，数据盘还留在老主库上，业务照样中断。
主从服务器切换失败原因：存储联动没跟上排在前列
很多运维把主从切换理解成“把VIP漂到从库”或者“把从库提升为主库”，但在实际故障现场，从库升主后数据库起不来、业务报只读、日志刷I/O错误，相当一部分不是复制参数问题，而是存储挂载状态没切过来。
常见的三个坑：
- 共享存储的锁还挂在旧主手里,新主能看到磁盘，但写入被SCSI锁拒绝，数据库写操作直接卡死。
- DRBD主从角色没有翻转,从库已经升主，但块设备还是Secondary状态，数据目录只读。
- 数据目录实际指向旧主的NFS挂载点,旧主一断电，新主上的
/data目录变成空目录，数据库启动时找不到系统表空间。
业内专家指出,主从切换演练中暴露出的故障，多数都集中在存储联动和资源释放环节，而不是数据库复制本身，团队里如果没有专职存储人员，这类坑踩中的概率会更大。
主从服务器与存储联动配置的两种路线对比
把存储联动做好的前提,是先搞清楚自己属于哪条路线，目前主流就两种：DRBD主从块设备同步，和共享存储SAN/NAS加集群锁。
| 对比项 | DRBD主从同步 | 共享存储SAN/NAS |
|---|---|---|
| 数据同步方式 | 两块本地盘实时同步 | 存储阵列集中提供卷 |
| 切换动作 | 角色翻转+重新挂载 | 释放旧主锁+新主挂载 |
| 故障恢复速度 | 通常秒级到分钟级 | 通常在分钟级 |
| 硬件依赖 | 两台服务器+本地盘 | 独立存储设备 |
| 适用场景 | 无共享存储的小集群 | 已采购SAN/NAS的机房 |
| 成本区间 | 软件开源，整体较低 | 存储设备价格通常较高 |
DRBD方案胜在便宜、不挑硬件，但要求运维能熟练处理drbdadm primary和secondary，共享存储方案把一致性压力交给存储阵列，但锁和仲裁配置不能有半点马虎。
服务器存储双活配置价格与DRBD同步方案怎么选
双活存储听起来完美：两台控制器同时读写，任一台故障不影响业务，但服务器存储双活配置价格通常比单控或DRBD方案高出一大截，还绑定厂商授权，如果你的业务RTO是分钟级、数据量在几TB以内，DRBD加脚本联动多数情况下足够，如果业务要求RTO接近零，才考虑双活存储加应用集群。
切换前必须做好的存储准备：四个检查项
切换脚本写得再漂亮,底层状态不检查，执行时还是会翻车，切换前按下面四个项过一遍。
检查共享存储锁和仲裁
在旧主上执行sg_persist -d /dev/sdb查看PR key是否仍由旧主持有，共享存储切换前，旧主必须先释放锁，新主才能注册新key，漏掉这一步，挂载命令可能成功，但写入会报“Read-only file system”。
检查DRBD状态是否一致
用drbd-overview看两节点状态，只有两节点都显示UpToDate，切换才有干净的数据基础，如果旧主是Primary，新主是Secondary，切换前别手动乱切，先等同步完成。
验证从库数据目录可写
这个动作看起来多余,却能在切换前暴露挂载配置错误，直接在从库执行：
touch /data/test_write && rm /data/test_write如果提示只读文件系统,说明从库的数据目录并不真正可写，切换后一定启动失败。
准备切换脚本并做一次空跑
脚本至少包含：停止服务、卸载或降级、角色切换、挂载或升级、启动服务、健康检查，空跑时把命令改成
echo输出，确认执行顺序没有错。
主从切换时存储联动的实操命令序列
以DRBD加MySQL为例,假设资源名为r0，挂载点为/data，切换顺序如下：
- 旧主停止数据库：
systemctl stop mysql - 卸载数据目录：
umount /data - 降级DRBD资源：
drbdadm secondary r0 - 在新主上升级DRBD资源：
drbdadm primary r0 - 挂载数据目录：
mount /dev/drbd0 /data - 启动数据库并关闭只读：
systemctl start mysql，然后执行mysql -e "SET GLOBAL read_only=OFF;" - 验证写入：
mysql -e "CREATE DATABASE switch_test; DROP DATABASE switch_test;"
共享存储路线下,步骤类似但锁处理不同：
- 旧主卸载：
umount /data - 旧主释放持久锁：
sg_persist -o -K <old_key> /dev/sdb - 新主注册锁：
sg_persist -o -S <new_key> /dev/sdb - 新主挂载：
mount /dev/mapper/mpatha /data - 启动数据库并验证。
命令里的设备名、资源名、key值都需要按实际环境替换，直接照抄生产环境容易出事。
切换后存储一致性验证：三个命令快速定位
切换完别急着通知业务,先把存储状态确认清楚。
cat /proc/mounts | grep data确认/data当前的真实挂载来源，防止还在用旧NFS。lsblk -f查看块设备、文件系统和挂载点的对应关系。drbd-overview或pcs status确认集群资源已经落到新主，没有中间状态。
同时翻一下数据库错误日志,重点搜“Read-only file system”“I/O error”“Device or resource busy”，出现这些关键字，说明存储联动没有完全成功，数据库虽然起来了，写入链路可能已经断了。
北京服务器主从切换配置中机房内网延迟的影响
地域因素在存储联动里经常被忽略,北京服务器主从切换配置如果跨了机房，比如一个节点在亦庄，另一个在酒仙桥，内网延迟从同机房的零点几毫秒可能升到几毫秒甚至更高，DRBD同步模式下，写入延迟会直接放大，业务响应变慢。
所以北京地区的服务器主从部署,如果两节点跨机房，优先考虑同城裸光纤直连，或者改用MySQL异步复制加定期存储快照，不要强行上同步复制，不然主库写入会拖垮整个业务。
主从切换从来不只是数据库复制参数的事,存储挂载状态、锁释放、块设备角色必须跟切换步骤串成一条线，把存储联动写进切换脚本并定期演练，比切换出问题后临时挂载可靠得多。
主从服务器故障切换存储配置联动常见问题
主从服务器故障切换存储配置联动需要单独买双活存储吗？
不需要,DRBD这类软件方案在两台服务器上就能实现块级同步，成本低，但要求运维能处理角色翻转，共享双活存储在硬件层解决一致性问题，代价是价格高、绑定厂商。
主从切换时共享存储挂载失败，最快的恢复路径是什么？
按这个顺序查：
- 旧主是否还在持有SCSI锁,执行
sg_persist -d /dev/sdb查看； - 集群仲裁是否因脑裂冻结了资源；
/etc/fstab是否写了_netdev导致网络存储没就绪；- 手动释放旧主锁后重新挂载,多数情况能恢复。
主从服务器故障切换存储配置联动中如何避免脑裂？
必须配置独立仲裁节点或仲裁盘,并在集群层面启用fencing，例如stonith，脑裂一旦发生，共享存储必须能拒绝旧主写入，否则数据会分叉，没有仲裁的DRBD双节点在断网时极容易双侧Primary，属于配置错误。