DM8数据共享集群与数据守护：构建高可用灾备架构实战

主库故障、机房断电、数据误删这种场景碰上任何一个都足够让 DBA 半夜爬起来处理。做灾备的核心思路其实很朴素同一个数据不能只存在一个地方。DM8 数据共享集群DMDSC在灾备体系里的定位就是让多台数据库实例同时对外服务再配合日志同步把数据复制到备机。这篇文章我从方案选型讲到实战搭建再聊到切换演练中的细节坑给准备上手或正在做容灾方案的朋友一个完整参考。1. 先把 DM8 数据共享集群说清楚它到底是什么灾备适合放哪里1.1 数据共享集群的核心组件与分工DM8 数据共享集群Dameng Data Share Cluster简称 DMDSC和很多人熟悉的 Oracle RAC 思路类似多台数据库实例节点通过高速网络访问同一套共享存储每个实例都在各自内存中维护缓存但数据文件只有一份。对外看起来是多台机器实际上是同一个数据库。要理解它需要先分清集群里的三个关键角色DMDSC 实例数据库服务节点每个节点跑一个完整的 DM8 数据库进程用户的应用可以连到任意一个节点执行 SQL。节点之间通过内部消息同步锁和缓存信息。DMCSS集群同步服务负责节点心跳检测、故障判定、控制节点的启动与关闭。可以理解成整个集群的“操作系统”哪个节点宕了、哪个节点要接管都由它来定。DMAS集群归档服务负责管理集群的归档日志把各个节点的 Redo 日志按顺序归并成完整的归档链路。灾备端的数据同步靠的就是这条链路。对 DBA 来说DMDSC 解决了两个核心问题一是高可用单个节点宕掉后剩余节点可以继续提供服务应用连接自动转移到存活节点二是扩展性并发压力大时可以加节点分担负载。但要注意一个边界DMDSC 本身解决的是“同一套存储上的多实例服务”问题。它不负责跨机房的数据复制。如果整个机房或共享存储坏了数据依然可能丢。所以灾备架构里DMDSC 一般作为生产端核心必须再接一层跨机房的灾备同步。常见的认知误区是“有了 DMDSC 就等于实现了灾备”。准确地说DMDSC 是高可用方案数据守护Data Watch才是灾备方案。两者组合起来才是完整的“同机房高可用 跨机房容灾”架构。1.2 灾备场景下为什么要选 DMDSC实际生产环境里选择 DMDSC 做灾备核心通常基于三个现实考虑。第一数据库数量多服务器资源有限。核心系统大多跑在物理机或虚拟化平台上如果每个系统都做一套“主备冷备”设备成本直接翻倍。DMDSC 可以复用共享存储如双活存储、分布式存储节点服务器之间还可以跑其他非核心业务资源利用率明显更高。第二业务对中断时间要求高。做了灾备不等于能容忍长时间停机。DMDSC 节点切换是秒级的配合应用连接池的快速重连应用基本无感知而传统的“一台机器 定期备份”方式恢复时间动辄半小时以上。第三数据实时性要求严格。金融、政务、医疗等系统主备之间的数据差距通常要求控制在秒级甚至“零丢失”。DMDSC 基于 Redo 日志的同步机制比定时备份、手工导数据等方式要可靠得多丢数据的窗口非常小。对于已经在用 DM8 的团队DMDSC 还有一个额外的好处达梦的数据守护和 DMDSC 是同一套体系内的组件配置和运维习惯一致不用像异构方案那样再学一套工具。2. 灾备方案选型同样做容灾为什么是“DMDSC数据守护”2.1 几种常见方案的对比灾备方案选型时最怕“一张 Oracle 的图纸拿去建 DM 的机房”。我做过几个项目的容灾评估接触过几类方案简单梳理一下各自适用场景方案类型数据一致性切换时间成本适合场景定期备份异地存储取决于备份周期小时级低非核心系统数据丢失容忍度高逻辑复制工具秒级到分钟级分钟级中异构数据库、部分表迁移场景数据守护异步备库秒级分钟级中同城灾备、异地容灾允许少量数据丢失DMDSC数据守护实时备库秒级以内秒级/分钟级高核心交易系统要求高可用和快速切换表格里最后一行就是我重点要讲的组合。生产端用 DMDSC 提供多实例高可用灾备端用数据守护把日志实时或准实时同步到异地备库。两层叠加单节点故障靠集群切换整个机房故障靠备库接管。选择这个方案还有一个重要原因达梦的数据守护支持“主库DMDSC”模式。也就是说主库可以是一套完整的 DMDSC 集群备库可以是单机、也可以是另一套 DMDSC。这种模式在 Oracle 里对应 Data Guard RAC在达梦体系里是原生支持的不需要额外中间件。2.2 数据同步机制是怎么工作的数据守护的核心是日志同步。主库产生 Redo 日志本地写联机日志同时通过日志归档把 Redo 传给备库。备库收到日志后通过重做Redo把变更应用到自己的数据文件里。主备之间的数据差距取决于日志传输和应用的延迟。同步模式有三种生产中要按业务容忍度来选实时同步REALTIME主库提交事务后日志立即传送到备库并执行重做备库始终和主库保持同步。这种方式数据丢失风险最低但对网络带宽和延迟要求高。自动同步AUTO主库提交前等待备库确认接收日志。备库确认后事务才能提交成功。这种方式理论上零丢失但会拉高主库的事务响应时间。手动同步MANUAL依赖 DBA 手工触发日志应用备库数据存在明显延迟。一般只用于初始化、迁移或临时维护场景。我做核心交易系统时主备同城一般开自动同步或者实时同步跨城异地容灾如果链路条件一般会退到实时同步甚至异步因为业务不能为了灾备牺牲太大性能。注意点DM8 数据守护备库分为“可读备库”和“不可读备库”。可读备库可以跑报表查询压榨灾备资源价值不可读备库则完全跟随主库重放日志更接近“纯备份”角色。设计灾备系统时不要为了“让备库可读”而牺牲了日志应用效率。2.3 同城双活与异地灾备怎么选同城双活的意义在于机房 A 和机房 B 在同一个城市距离近通常几十公里内网络延迟低。生产端 DMDSC 的两个节点可以分别放在两个机房共享存储则通过存储层的双活方案打通。这样任何一个机房整体故障另一个机房的节点照样提供服务业务几乎无感知。异地灾备的意义在于整个城市发生大面积故障时极端自然灾害、电网故障等还有另一个城市的机房可以接管。异地距离远网络延迟大日志同步会受到影响所以异地一般建议采用异步或实时同步模式允许最后一个事务少量丢失。成熟的架构通常分三层机房内部靠 DMDSC 节点切换同城靠数据守护实时同步异地再做一份异步灾备。层与层之间不要互相依赖也不要因为同城做得好就忽略异地——现实中发生过同城双机房同时受影响的案例。3. 落地实践一套可复现的 DMDSC 灾备架构搭建3.1 环境规划与基础配置我以一个实际项目为例目标环境是这样的生产端两节点 DMDSC共享存储由存储设备提供灾备端一台单机备库部署在异地机房。主备之间通过专线连接带宽 100Mbps 以上。硬件规划方面几项最低要求要提前确认共享存储DMDSC 所有节点必须能访问到同一套磁盘磁盘分区在两个节点上看到的设备名要一致建议用存储映射后的标准盘符或多路径设备。网络节点间用千兆以上内网主备间专线延迟最好控制在 20ms 以内。内存每个节点按业务数据量规划 buffer 池一般建议不小于物理内存的 50%。操作系统选用达梦官方兼容列表内的 Linux 发行版避免自选冷门内核版本。在操作系统层面先做几个常规设置关闭防火墙或放通数据库所需端口dmcss、dmas、实例端口等关闭 SELinux调整文件描述符限制ulimit -n 至少 65536。这些不处理好后面搭建过程中会出现各种“莫名其妙”的网络和文件访问问题。实践心得不要迷信“默认配置就能跑”。我第一次部署时没改系统文件描述符集群启动后 DMCSS 偶尔报连接失败排查了好几个小时。后来把 limits.conf 配上问题再没出现过。3.2 搭建 DMDSC 主集群DMDSC 搭建的核心是初始化共享磁盘上的数据文件和日志文件然后逐个配置节点实例。大致流程如下在共享存储上规划磁盘分区每个节点确认可以访问同一套裸设备。使用 DM 的初始化工具dminit在共享盘上初始化数据库实例指定 DMDSC 相关参数。配置 dmdcr.ini 文件每节点对应自己的 DCR 配置包含集群名称、节点编号、CSS 端口等。启动 DMCSS 进程开始集群控制服务。检查集群状态确认所有节点正常注册然后启动各节点的数据库实例。创建 DMAS 归档服务配置开始收集归档日志。关键的 dmdcr.ini 配置两节点示例节点编号 0 和 1简化后大致长这样DMDCR_PATH /dev/raw/raw1 DMDCR_MAL_PATH /dmdata/dcr_mal.ini DMDCR_SEQNO 0 DMDCR_PERMIT_MONITOR 0 DMDCR_DB_PATH /dev/raw/raw2 DMDCR_DB_LOG_PATH /dmdata/log节点 1 的配置除了 DMDCR_SEQNO 改成 1其他路径需要保持一致。DMCSS 会通过 DCR 磁盘信息来识别节点身份路径不一致会导致节点无法加入集群。启动 DMCSS 之后用达梦自带的集群监视工具检查节点状态dmcss_check看到类似“NODE 0 IS RUNNING”“NODE 1 IS RUNNING”的输出说明集群控制层正常。之后再启动两个实例并用 disql 登录确认可以正常执行查询和事务。3.3 配置数据守护灾备生产端 DMDSC 集群跑起来后下一步是配数据守护。需要准备三台角色主库DMDSC 集群整体视作一个主库逻辑备库单机 DM8以及监视器可以单独一台也可以复用备库所在机器。主库上配置归档核心文件是 dmarch.ini。一个典型的配置[ARCHIVE_LOCAL1] ARCH_TYPE LOCAL ARCH_DEST /dmdata/arch ARCH_FILE_SIZE 1024 ARCH_SPACE_LIMIT 0 [ARCHIVE_REALTIME1] ARCH_TYPE REALTIME ARCH_DEST SLAVE01ARCH_TYPE 为 LOCAL 的项负责本地归档REALTIME 的项负责实时日志传输。ARCH_DEST 填的是备库在 dm.ini 中配置的 MAL 服务名。备库上先初始化一个和主库同名的数据库实例再从主库做一次全量备份恢复到备库这样主备初始数据一致。恢复完成后配置备库的 dmarch.ini指向主库即可。配置完成后启动守护进程主库、备库都要启动 dmwatcher监视器端也要启动 dmmonitor。运行状态确认主库查询 status显示 MOUNT 状态且守护进程正常。备库查询 status显示 STANDBY 状态归档应用线程持续运行。监视器显示主备库连接正常模式为 Primary / Standby数据同步延迟在预期范围内。这里特别提醒一个容易踩的坑主备库的 dm.ini 里实例名INSTANCE_NAME和 dmarch.ini 里的 MAL 服务名必须严格对应包括大小写。我见过因为一个字母大小写不一致主库日志一直传不过去备库始终无法追赶进度的情况。3.4 灾备切换演练全流程配置好只是第一步真正的重头戏是切换演练。我做的演练流程分四步模拟主库单节点故障手动 kill 掉 DMDSC 节点 0 的数据库进程观察节点 1 是否接管应用连接是否自动重连到节点 1。这一步验证的是高可用能力。模拟主库整体故障停掉整个 DMDSC 集群确认备库没有收到新的日志后在监视器上执行主备切换操作。切换成功后备库变成主库业务连接指向新的主库。这一步验证的是灾备接管能力。原主库修复后重新加入原 DMDSC 集群恢复后作为新备库加入数据守护体系重新开始日志同步等延迟追平后整个架构恢复双活状态。记录切换时间从故障发生到业务恢复观察切换耗时是否满足 RTO 要求。切换操作一般在监视器dmmonitor里执行关键命令参考switchover 主库名 备库名如果主库完全不可用没有机会手工发切换命令备库可以执行 takeover 强制接管。注意 takeover 有风险可能导致原主库上线后数据回退或冲突所以实际操作中能先尝试恢复主库就尽量先用 switchover。4. 切换演练与故障模拟的细节坑4.1 演练中的典型问题演练是最好的照妖镜很多平时看不出来的问题一到切换就现原形。我整理几个典型问题。问题一应用连接池缓存了旧主库 IP。报表系统、接口服务等连接池如果配置了固定 IP主备切换后应用不会自动感知新的主库地址导致连接全部失败。解决办法是在应用层引入 VIP 或域名切换后绑定新主库而不是让应用改配置。问题二备库只读状态导致报表任务报错。有些团队把灾备备库做成可读库跑报表但切换后这些报表任务会继续连备库而备库此时已经变成新的主库任务逻辑可能不兼容。需要在切换前做好应用路由规划明确哪些读流量在灾备库上切换后如何切回。问题三主库故障后归档日志断档。DMDSC 挂了以后日志传输中断备库无法获取最新日志无法追平。此时要做的是尽可能抢救主库的联机日志和归档日志手动拷贝到备库并注册然后再尝试切换。这块最考验 DBA 对日志链路原理的理解。4.2 常见问题速查表现象排查思路常用处理方式DMCSS 启动失败检查 DCR 磁盘路径、节点 seqno 是否重复用 dmcss_check 查看节点注册状态备库日志不应用检查 dmarch.ini 服务名、网络连通性、主备库模式重新加载归档配置手动注册缺失日志切换时报主库不可用确认主库进程是否存活、网络是否隔离先尝试恢复主库必要时用 takeover备库追平速度慢检查专线带宽、磁盘性能、备库 REDO 并行度调大 REDO 重做线程优化备库写盘策略监视器连接不上检查监视器与主备库之间端口、实例名、密码核对 dmmonitor.ini 中的连接信息4.3 独家避坑笔记最后分享几个实践中的独家笔记都是常规文档里不会写细的东西。第一尽量用“可读备库”但不直接在上面跑核心报表。可读备库跑查询确实能减轻主库压力但一旦备库延迟增大查询数据就不一致了。我会把可读备库的查询全部限制在“延迟时间小于阈值时放行”通过守护进程的延迟监控字段做控制而不是完全开放。第二切换顺序很重要。数据守护切换时我建议先停应用或等应用连接自然断开再切主备不要一边有业务在写一边强行切换。哪怕多等几十秒换取切换过程干净稳定比业务多断几秒更有价值。第三日常巡检要有“只看日志链路”的动作。不要只盯着数据库状态要用守护进程的监控视图定期看归档传输、重放延迟、节点日志进度。我一般每天看一次延迟曲线发现备库延迟持续走高就提前排查链路和磁盘避免真出故障时备库落后太多。第四DMDSC 节点的故障转移不是无限循环的。虽然集群支持节点切换但要定期检查存储链路、节点健康状态。两个节点同时异常时集群可能无法自动恢复这时依赖的是数据守护的灾备层所以两套体系必须都保持可切换状态不能“重一轻一”。5. 延伸思考灾备架构还能往哪扩展DMDSC 数据守护的组合目前已经能覆盖绝大多数同城、异地容灾场景。再往前走一步可以把灾备体系做得更完整一个是增加一套独立的备份系统。虽然数据守护是实时复制但历史数据的完整性、可回溯性依然需要定期备份。生产端 DMDSC 的备份任务和灾备端的数据守护日志应用要错峰执行避免互相争抢 I/O。另一个是把灾备端从“被动等待切换”变成“可观测的验证平台”。可以周期性在备库做数据一致性校验比对主备两个库的表数据、约束状态、序列状态。不要等到切换时才发现备库数据有问题。第三个是自动化切换编排。目前切换决策还是 DBA 人工判断为主后续可以结合监控平台的告警规则把“心跳丢失检测、主备状态判定、切换确认、应用路由更新”这些步骤编排起来减少人为判断错误。不过自动化切换上线前必须经过多轮演练和回退验证否则一旦自动化判断失误损失会比人工处理更大。我在实际运维中的体会是灾备方案的价值不在于图纸画得多漂亮而在于故障发生时能不能真的扛住。DMDSC 给了生产环境一个稳定的高可用底座数据守护给了跨机房的数据副本两者结合是否可靠全靠平时是否认真做切换演练、是否持续关注日志链路延迟。这套架构做完之后我依然会每隔一个季度做一次完整的故障模拟把主库弄挂几次看看整套体系在真实压力下表现如何。演练中暴露的问题远比文案里的承诺更值钱。