高可用数据库架构依赖共享存储还是本地盘，不能一概而论：共享存储以更高成本换取强一致和简化切换，本地盘以更低延迟和硬件成本换取灵活，但高可用必须靠软件层补齐。
高可用数据库架构选型：共享存储和本地盘哪个好
共享存储和本地盘代表了两种完全不同的数据管理哲学,共享存储像个靠谱的老管家，所有数据库节点共用一份数据文件，切换时新主节点直接挂载同一个卷，天然不会出现主备数据分叉，本地盘像手脚麻利的年轻店员，每台服务器自己管自己的数据盘，靠复制链路把数据同步到其他节点，主库故障后备库接替。
要理解“共享存储和本地盘哪个好”，得先看它们各自在数据库高可用场景下的核心表现。
共享存储架构的核心逻辑
共享存储方案中,数据库计算节点和数据存储是分离的，Oracle RAC、SQL Server Always On FCI、达梦DSC都属于这一类，多个数据库实例通过SAN或分布式存储访问同一份数据文件，主节点故障时，备节点直接挂载存储卷并启动实例，整个过程通常不需要数据同步，因此恢复时间目标（RTO）可以压到很短。
共享存储的优势集中体现在三点：
- 数据只有一份,节点切换不涉及数据追赶，强一致天然成立。
- 存储容量可以独立扩容,不影响计算节点数量。
- 适合对数据一致性要求极高的场景,如金融账务、支付交易、核心ERP。
缺点同样明显：
- 中高端双控存储阵列价格不低,多数情况下占整体硬件投资较大比例。
- 存储网络需要FC交换机、HBA卡、光纤模块，运维复杂度抬升。
- 存储设备如果自身成为单点,需要额外配置双控制器和冗余链路。
本地盘高可用方案为什么受互联网公司青睐
本地盘方案中,每个数据库节点使用本机NVMe SSD或SATA SSD，数据通过软件复制，MySQL主从半同步、MGR组复制、PostgreSQL流复制、MongoDB副本集都是常见实现，由于直接读写本地盘，IO路径短，延迟可以做到微秒级，吞吐也更贴近硬件上限。
本地盘高可用方案的优势：
- 本地NVMe延迟低,适合高并发小事务。
- 使用通用x86服务器,硬件成本比专用存储低不少。
- 水平扩展简单,增加节点即可分担读压力。
它的短板在于：
- 复制存在天然延迟,异步复制下主备切换可能丢少量数据。
-
需要额外设计仲裁机制,防止脑裂。
- 运维人员要熟悉复制拓扑、GTID、故障切换工具，人力成本更高。
共享存储数据库集群成本与性能如何权衡
共享存储数据库集群成本不是一个小数字,很多团队在选型时只看到存储阵列报价，忽略了配套网络和运维投入，共享存储数据库集群成本通常包含三块：
- 存储阵列：中高端双控阵列价格较高，尤其是支持双活或同步复制的型号。
- 存储网络：FC交换机、HBA卡、光模块，单台FC交换机价格通常高于同级万兆以太网交换机。
- 运维人力：需要懂多路径、文件系统、存储性能调优，人员培养周期更长。
性能方面,共享存储的IO路径包含主机HBA、存储网络、控制器缓存、后端磁盘，整体延迟普遍高于本地NVMe，对于读多写少、单次事务较大的分析型负载，共享存储的缓存命中率可以抵消一部分延迟劣势，但对于高频小事务OLTP，本地盘方案往往吞吐更高。
共享存储部署中的关键配置
实际部署共享存储数据库集群时,有几项操作路径必须掌握：
- 配置多路径软件,安装
device-mapper-multipath，编辑/etc/multipath.conf，设置path_grouping_policy为failover或multibus。 - 使用
multipath -ll检查聚合后的路径状态。 - 文件系统不要用普通ext4,Oracle RAC场景使用OCFS2或ASM，SQL Server FCI使用NTFS或ReFS，多节点同时挂载必须用集群文件系统。
- 心跳网络与存储网络隔离,避免存储抖动引发节点误切换。
什么时候共享存储反而划算
如果业务要求数据库7×24小时强一致，本地盘软件方案的人力投入可能超过存储硬件差价，例如金融核心账务、订单支付、合同系统，共享存储的成熟方案能大幅减少排障时间，多个业务数据库实例共享一套高端存储，也能摊薄单位容量成本，北京、上海等地机房托管费用高，机柜空间有限，共享存储可以减少服务器数量，间接节省机柜租金。
本地盘高可用数据库架构怎么搭才稳
本地盘高可用数据库架构的关键不在硬件,而在软件层的复制、故障检测和切换，以MySQL 8.0为例，一套相对稳的本地盘高可用方案通常包含半同步复制加自动故障切换工具。
基于MySQL半同步复制的本地盘高可用步骤
- 主库和备库安装MySQL 8.0，确保
server-id不同，开启GTID。
- 主库执行命令安装并启用半同步插件：
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';SET GLOBAL rpl_semi_sync_master_enabled = 1; - 备库执行命令：
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';SET GLOBAL rpl_semi_sync_slave_enabled = 1; - 使用MHA或Orchestrator进行自动故障检测和切换,配置VIP漂移，应用侧连接VIP。
- 监控复制延迟,设置
rpl_semi_sync_master_timeout，避免半同步退化为异步后无感知。
防止脑裂的关键配置
本地盘高可用最怕两个节点同时认为自己是主库,行业共识认为，多数派仲裁是相对可靠的防脑裂手段，具体操作：
- 部署三节点MGR组复制,写入必须获得多数节点确认，双节点故障时集群自动只读。
- 使用Corosync配QDevice仲裁盘,或使用云厂商提供的仲裁服务。
- 心跳链路与业务网络隔离,避免交换机故障引发误判。
- 对共享VIP设置arping冲突检测,新主节点提升前先检查旧主是否存活。
本地盘方案的数据恢复场景
当主库本地盘损坏,备库数据可能落后，通过GTID对比，用mysqlbinlog补齐差异，如果半同步配置正确，多数情况下RPO接近零，但不能绝对保证，异步复制下RPO取决于网络延迟和复制积压大小，因此本地盘方案必须定期做恢复演练，否则真到故障时会发现备份不可用。
北京机房数据库高可用部署：共享存储还是本地盘
北京机房托管费用较高,机柜电力和制冷成本也高于部分二三线城市，北京机房数据库高可用部署”场景下，成本敏感型团队更倾向于本地盘方案，同城多机房之间专线质量较好，裸光纤延迟通常可以控制在1-2ms，本地盘方案可以做同城半同步复制，跨机房MGR多数派部署。
北京同城双机房方案怎么选
同城双机房距离通常在几十公里内,本地盘方案可以做同城半同步复制，主机房两节点，备机房一节点，避免单机房故障导致整个集群不可用，共享存储跨机房一般需要存储级双活，硬件门槛和链路成本都比较高。
北京地区金融和互联网企业集中,运维人才也相对充足，金融企业常用“同城双活、异地灾备”架构，核心交易库用共享存储双活保证RPO=0，非核心业务库用本地盘复制降低成本，互联网企业多数直接采用本地盘加多机房异步复制，配合消息队列补偿最终一致。
高可用数据库架构选型决策路径
选型不是拍脑袋,建议按下面步骤推进：
- 第一步,明确业务RPO和RTO，强一致RPO=0优先共享存储。
- 第二步,评估预算，预算有限优先本地盘软件方案，把省下的钱投入监控和演练。
- 第三步,看团队能力，有存储运维经验选共享存储，有主从复制、MGR经验选本地盘。
- 第四步,小范围压测，分别用共享存储和本地盘跑真实负载，对比延迟、吞吐、故障切换时间。
- 第五步,考虑扩展性，未来跨地域多活，本地盘方案更容易水平扩展。
| 维度 | 共享存储 | 本地盘 |
|---|---|---|
| 数据一致性 | 强一致 | 取决于复制，半同步较强 |
| 延迟 | 较高 | 较低 |
| 硬件成本 | 较高 | 较低 |
| 运维复杂度 | 存储运维重 | 数据库复制运维重 |
| 扩展方式 | 垂直扩展 | 水平扩展 |
| 跨机房能力 | 较弱 | 较强 |
结束语
高可用数据库架构没有万能方案,共享存储卖的是省心和一致，本地盘卖的是性能和灵活，真正决定成败的不是硬件选型，而是架构设计和故障演练是否到位，把RPO、RTO和预算摆到桌面上，答案自然会出现。
高可用数据库架构常见问题解答
共享存储和本地盘哪个更适合中小业务？
中小业务通常数据量不大,预算有限，本地盘配合MySQL主从或MGR多数派更常见，如果业务涉及支付、合同等强一致场景，可租用云上共享存储数据库服务，先理清RPO需求，比盲目上高端存储更实际。
本地盘高可用数据库如何防止脑裂？
部署奇数节点多数派,如三节点MGR，任一节点网络隔离时票数不足自动降级，配合Consul或etcd做服务发现锁，应用侧只连接持有锁的节点，同时设置STONITH机制，通过IPMI或云API强制隔离故障节点，避免双主写入。
北京机房部署高可用数据库架构要注意什么？
北京机房托管费用较高,本地盘方案能降低硬件成本，但需要关注机柜电力和制冷，同城多机房之间专线质量较好，可做同步或半同步复制，北京地区金融和互联网企业集中，运维人才相对充足，本地盘软件高可用方案落地案例较多。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/639719.html
