在构建数据库高可用性(HA)架构时,确保所有节点能够对同一份数据进行安全、一致的访问是核心挑战之一,这里的“访问”最终落实在存储层面,即如何将共享的或复制的存储设备正确地挂载到数据库服务器上,这个过程并非简单的mount
命令操作,而是紧密依赖于整个HA方案的顶层设计,理解其内在机制对于保障系统稳定性和数据完整性至关重要。
存储挂载在高可用架构中的核心原则
数据库HA的本质是在主节点故障时,备用节点能够无缝接替其职责,继续提供服务,要实现这一点,备用节点必须能够访问到与主节点“完全相同”的数据状态,这就引出了存储挂载的两个基本原则:
- 单一写入者原则:在任何时刻,存储卷只能被一个节点以读写(RW)模式挂载并访问,如果两个节点同时写入,将不可避免地导致“裂脑”问题,引发文件系统元数据混乱和数据库数据损坏。
- 自动化与原子性原则:挂载和卸载操作不能由人工手动完成,必须由集群管理器(如Pacemaker、Veritas Cluster Server、Windows Server Failover Clustering等)作为资源管理的一部分,与其他服务(如虚拟IP、数据库进程)作为一个原子操作组进行调度,这意味着挂载必须在数据库启动之前成功完成,而在节点故障或主动切换时,必须先停止数据库,再安全地卸载存储。
基于这两项原则,业界主要有两种主流的实现方式:共享存储模式和存储复制模式,它们在存储挂载的具体实现上有着显著的区别。
共享存储模式
这是最传统、最直观的HA存储方案,它依赖于一个外部的、独立的存储系统,如SAN(Storage Area Network),该存储通过光纤通道(FC)或iSCSI等网络协议,将同一个块设备(LUN)同时暴露给HA集群中的所有数据库节点。
工作流程与挂载逻辑:
在这种模式下,存储设备(/dev/sdb
)对所有节点都是可见的,为了遵循单一写入者原则,集群管理器会承担起“门禁”的角色。
正常运行时:
- 集群管理器在主节点上执行挂载操作,
mount /dev/mapper/vg_db-lv_data /database
。 - 它会严格禁止在任何备用节点上挂载此设备。
- 数据库服务启动,访问挂载点
/database
。
- 集群管理器在主节点上执行挂载操作,
故障切换过程:
- 监控系统检测到主节点故障。
- 集群管理器立即在备用节点上执行一系列预设动作:
- 通过STONITH(Shoot The Other Node In The Head,即“心跳爆头”或“隔离”机制)确保故障节点无法继续访问共享存储,这是防止“裂脑”的最关键保障。
- 备用节点接管集群的“虚拟IP地址”。
- 在备用节点上执行挂载操作:
mount /dev/mapper/vg_db-lv_data /database
。 - 在备用节点上启动数据库服务,对外提供应用。
挂载注意事项:
- 文件系统选择:强烈建议使用具备日志功能的文件系统,如XFS或ext4,虽然它们本身不是集群文件系统,但在“单节点挂载”的HA模式下是安全的,如果应用场景更复杂,需要多个节点同时只读访问,可以考虑GFS2或OCFS2这类集群文件系统,但它们配置更复杂,性能也可能有损耗。
- 隔离的重要性:STONITH是共享存储模式的生命线,如果没有可靠的物理或软件层面的隔离机制(如控制服务器电源、关闭光纤通道端口),在网络抖动等情况下,两个节点可能都认为对方宕机,从而试图同时挂载写入存储,导致数据瞬间损毁。
存储复制模式
当没有或不想依赖昂贵的SAN时,存储复制提供了一种更灵活、性价比更高的方案,其代表技术是DRBD(Distributed Replicated Block Device),在这种模式下,每个数据库节点都拥有本地存储,数据在块级别被实时、同步地从主节点复制到备用节点。
工作流程与挂载逻辑:
存储复制模式下,不存在物理上的“共享”设备,而是通过软件在两个独立设备之间构建了一个虚拟的一致性镜像。
正常运行时:
- 主节点的DRBD资源角色为“Primary”,其本地块设备(
/dev/drbd0
)可以被挂载:mount /dev/drbd0 /database
。 - 备用节点的DRBD资源角色为“Secondary”,它接收来自主节点的数据并实时更新到本地磁盘,备用节点上的
/dev/drbd0
设备是绝不允许被挂载的,它处于不可用状态。
- 主节点的DRBD资源角色为“Primary”,其本地块设备(
故障切换过程:
- 集群管理器检测到主节点故障。
- 管理器在备用节点上执行操作:
- 将备用节点的DRBD资源角色从“Secondary”提升为“Primary”,此操作确保该节点拥有最新的、一致的数据副本。
- 提升完成后,DRBD设备
/dev/drbd0
在这个新主节点上变为可用状态。 - 执行挂载操作:
mount /dev/drbd0 /database
。 - 启动数据库服务。
挂载注意事项:
- 依赖集群管理器:DRBD的角色提升和设备挂载操作必须由集群管理器统一编排,手动操作极易出错。
- 网络质量敏感:同步复制对网络延迟和带宽非常敏感,网络抖动会直接影响到主节点的数据库写入性能,在规划时需要为节点间的复制链路提供高质量、低延迟的网络保障。
资源组管理示例
无论采用哪种模式,其挂载逻辑最终都体现在集群管理器的“资源组”配置中,一个典型的数据库资源组可能包含以下资源,它们会作为一个整体在节点间迁移:
资源类型 | 示例 | 启动顺序 | 停止顺序 |
---|---|---|---|
虚拟IP地址 | 168.1.200 | 1 | 3 |
文件系统 | mount /database | 2 | 2 |
数据库服务 | postgresql | 3 | 1 |
上表清晰地展示了,文件系统(存储挂载)必须在数据库服务之前启动,在数据库服务之后停止,确保了数据访问的依赖关系和安全性。
相关问答FAQs
问题1:为什么不能直接在两个数据库节点上都把存储mount为读写模式,实现负载均衡呢?
解答: 这是一个非常危险且错误的做法,绝大多数通用文件系统(如Linux下的ext4, XFS,或Windows下的NTFS)在设计上并未支持多节点同时读写,它们没有内置的分布式锁管理机制来协调来自不同操作系统的并发写入操作,如果强行在两个节点上以读写模式挂载同一个块设备,会立刻引发灾难性的后果,通常被称为“文件系统崩溃”或“数据损毁”,两个节点的缓存和文件系统元数据会迅速变得不一致,导致文件和目录结构破坏,数据库文件内容错乱,最终数据将无法恢复,只有专为多节点并发访问设计的集群文件系统(如OCFS2, GFS2)才能支持这种模式,但它们实现复杂,性能开销较大,且并非所有数据库都能完美兼容,因此在标准的数据库故障切换HA场景中,我们严格遵守“单一写入者”原则。
问题2:使用NAS提供NFS共享目录来挂载数据库文件,作为HA存储方案可行吗?
解答: 对于要求高可靠性的生产数据库,通常不推荐使用NFS作为主存储的HA解决方案,原因主要有三点:
- 性能瓶颈:NFS是基于网络文件系统的协议,相比直接访问块设备(SAN或本地磁盘),它引入了额外的协议栈开销和网络延迟,这会导致数据库的I/O性能(特别是IOPS和延迟)显著下降,影响交易型数据库的响应速度。
- 一致性风险:尽管NFS有锁协议,但在高并发、低延迟的数据库场景下,其锁的效率和稳定性可能不如直接块设备,数据库对数据一致性的要求极为苛刻,任何微小的写延迟或锁失效都可能导致数据问题。
- 故障检测复杂性:集群管理器检测块设备级别的连接故障(如iSCSI链路中断)通常更直接、更快速,而NFS挂载的“卡死”可能更难被及时察觉,从而延长了故障切换的时间。
对于非核心业务、读压力远大于写压力的系统,或者用于灾备的只读副本,NFS方案因其部署简单、成本较低,也是一种可以考虑的选择,但对于需要同步HA的核心交易数据库,块级别的共享存储或复制方案才是更为稳健和可靠的选择。
【版权声明】:本站所有内容均来自网络,若无意侵犯到您的权利,请及时与我们联系将尽快删除相关内容!
发表回复