搞容灾的都知道数据库集群不等于灾备更不等于高可用。DM8数据共享集群通常叫 DMDSC把多个实例挂在同一套共享存储上应用切换时基本无感但机房断电、存储阵列整体故障的时候照样打不开库。这篇就聊其中一个很实际的话题把 DMDSC 作为灾备底座配合数据守护机制搭一套能接管、能切换、平时还能辅助扛读的灾备体系。适合谁看做数据库运维、负责核心系统容灾的 DBA以及刚接触国产数据库、想理清共享集群和灾备关系的同学。1. 项目概述DMDSC 在灾备体系里的定位1.1 为什么单独把共享集群拿出来做灾备先说一个很多人容易混淆的点DMDSC 解决的是“同一机房、同一存储、多实例高可用”的问题。两个节点通过网络互联共享一套底层数据库文件任何一个节点宕机另一个节点可以继续提供数据库服务应用端几乎感知不到切换。但共享集群有一个天然边界——它依赖同一个存储池。存储所在的那一层出问题比如阵列控制器故障、机房级断电、甚至整个机房被“端掉”共享集群自身是无法自救的。真正的灾备要的是“另一套环境、另一块地盘、另一组副本”。DMDSC 在灾备体系中的角色不是代替备份也不是替代容灾软件而是作为“灾备端拉起数据库服务”的执行引擎配合日志实时同步机制形成一套异地或同城异机房的完整副本。用大白话说生产端 DMDSC 负责跑业务灾备端 DMDSC 负责“随时能被拉起来当生产用”。这正是生产系统和灾备系统同为“共享集群”架构的原因两边架构一致切换过去之后应用不需要改动连接方式和事务逻辑。1.2 灾备场景下 DMDSC 能提供什么能力作为灾备端DMDSC 并不只是“冷冰冰地躺着等同步”。在达梦生态里生产集群和灾备集群之间的数据流转依靠数据守护Data Watch这套机制完成。主集群把产生的日志持续传到备集群备集群在后台重演日志、更新数据页尽量让灾备端的数据状态与生产端保持一致。这套结构能拿来做几类事异地容灾接管生产中心发生灾难性故障时由灾备集群升主对外继续提供数据库服务。计划内维护窗口切换生产端要升级、换硬件、调整参数时可以用人工切换的方式先让灾备端顶上业务几乎不停。灾备端只读查询一些实时性要求不高的统计报表、数据抽取任务可以挂到灾备端执行给生产集群减轻压力。前提是确认业务能容忍备库数据的秒级延迟。所以这里对 DMDSC 灾备的预期不能只停留在“每十分钟传一个备份文件”的层面而是要做到分钟级甚至秒级的同步等待窗口达到可切换的标准。这个目标决定了后面所有配置和参数的选择。2. 架构设计与同步机制背后的逻辑2.1 选型思路为什么用日志同步而不是定期拷贝做灾备方案之前先想清楚最关键的问题数据怎么从生产端到灾备端。选择无外乎几类手工拷贝备份文件、定期做物理备份恢复、靠数据库自身日志重演机制。前面的方式成本低但恢复点目标没法看生产端凌晨坏掉最理想也只能恢复到头天夜里的备份。而对于 DMDSC 这种连续运行的核心系统业务不允许这么长的数据丢失窗口必须放弃备份恢复路线改走日志同步路线。DM8 的数据守护平时吹得不多实际用起来就是一套“主库持续往外传日志、备库持续吃掉日志”的机制。生产端 DMDSC 的每个实例都开启归档并且配置实时/即时归档发送到灾备端对应的实例。灾备端收到日志后进行重演数据状态跟随生产端变化。整个过程对业务透明不需要在应用侧做任何改造这是日志同步最大的优势。除此之外还有一个考虑DMDSC 共享集群自身的实例数通常不止一个灾备端同步的节点要和生产端实例一一对应形成一个“配对”的关系。这样任意一个生产实例故障灾备端总有一个对等的实例已经热好了数据接管时不会出现某个节点数据落后一大截、另一个节点却追不上来的尴尬局面。2.2 保护模式、RPO 与网络带宽的约束关系灾备方案最终要回答两个指标RPO最多丢多少数据和 RTO多久能恢复服务。这两个指标不是拍脑袋定的而是由保护模式、网络延时、日志产生速度共同决定。DM8 数据守护按保护级别分为自动、手动等不同模式。实操中我按自己的理解把它们归成三类最大保护模式生产实例提交事务时需要确保对应日志已经被灾备实例接收业务写入的实时性最强。RPO 趋近于零但生产端提交延时会增加对网络质量要求高。高性能模式生产实例提交事务后不等灾备确认日志异步发送灾备端延迟稍大。业务影响最小RPO 取决于日志积压量。手动/即时模式介于两者之间通常用于满足特定场景比如确认灾备端已经追平日志后再放行业务。真正实施时保护模式还要和网络带宽放在一起算。假设某个业务高峰期每秒产生 4MB 重做日志灾备链路如果只有 10Mbps 换算过来约 1.25MB/s 的吞吐显然追不上日志产生速度延迟只会越来越大。带宽估算建议取峰值日志速度的三倍以上给突发活动和重演追赶留出余量。带宽不足时 DMDSC 日志堆积在本地归档目录短时间内没风险但时间一长磁盘会被撑满进程异常。2.3 主备群拓扑与角色划分整条链路涉及的角色可以分成四类生产集群、灾备集群、守护进程、监视器。生产集群和灾备集群各自主机上都有一个独立的守护进程负责监控本集群内实例的状态。监视器则独立运行在一个稳定的环境里负责协调全局决定谁来当主、谁来当备。拓扑选择上最常见的是一组生产 DMDSC 配一组灾备 DMDSC两个集群通过内部专线互通比如生产在某个园区的 A 机房灾备在同城或异地的 B 机房。如果还想再稳一点可以放两个监视器节点避免单一监视器故障导致切换决策没人拍板。这里有一个很关键的细节守护组里的主备角色不是绑定在物理节点上的而是绑定在“集群”这一层。生产端 DMDSC 整组为主灾备端 DMDSC 整组为备。切换发生时灾备组整体升级为主组原生产组降为备组。整个灾备体系关心的是“组”的升降级而不是单个实例的启停。这也是 DMDSC 与普通主备架构在容灾概念上的最大区别。3. 实操过程从初始化到可切换的灾备集群3.1 环境准备与前置条件开始动手前先把环境理顺。下面这些是跑通这套架构的基本条件少一个后面都会出幺蛾子。两套独立的物理服务器或虚拟化资源池生产端建议配置至少两个节点灾备端同样至少两个节点保证集群形态对等。两套共享存储严格分开生产存储和灾备存储不能有交集否则机架一震两边一起完蛋。节点间网络至少分两路业务网和内部通信网内部通信网用于 DMDSC 实例互联及日志同步不要和业务流量抢带宽。灾备端数据库版本与生产端保持一致建议连补丁版本也一样跨小版本跑日志重演容易遇到兼容性问题。操作系统用户、磁盘权限提前规划好数据库软件安装在本地磁盘数据文件全部放在共享存储上别把数据文件放在系统盘。环境准备好之后确认一下防火墙和 SELinux 策略。集群内节点之间要放行专用的通信端口把安全策略先调成“允许范围内最小开放”再用 telnet 或 nc 测一遍端口连通性不要等到启动实例才发现端口不通。3.2 初始化实例与共享存储准备DMDSC 所有实例共享同一套数据文件所以初始化时只需要在其中一个节点先构建数据库数据文件落在共享存储路径上。初始化用的命令我习惯写成下面这样dminit PATH/dm/data PAGE_SIZE8 EXTENT_SIZE32 CHARSET1 CASE_SENSITIVEN DB_NAMEPRODDB INSTANCE_NAMEPROD_DM01各参数说明PATH数据文件存放路径必须是共享存储挂载的目录。PAGE_SIZE数据页大小8KB 是通用选择初始化后不可修改一定要提前定好。EXTENT_SIZE簇大小32 表示每个簇 32 个数据页数值大小对顺序扫描性能有影响。CHARSET字符集1 代表 UTF-8具体按应用要求定。CASE_SENSITIVE标识符大小写敏感开关建议和开发规范保持一致否则后期改不了。其他节点不再重复 dminit而是通过“追加实例”的方式把第二个实例加入共享存储的数据库环境。每套 DMDSC 的实例都有独立的内存、独立的 redo 日志和独立的控制信息但数据文件是同一套。追加实例的具体命令在不同版本里略有差异操作时以当前版本自带工具输出的提示为准。3.3 配置核心文件dm.ini、dmmal.ini、dmarch.ini、dmwatcher.ini、dmmonitor.ini数据守护体系看起来文件多、配置散实际记住一条主线就够dm.ini负责把各种子系统开关打开dmmal.ini负责把节点之间的通信地址定下来dmarch.ini负责告诉主库日志往哪里传dmwatcher.ini定义每组主机的守护参数dmmonitor.ini定义监视器如何管理所有节点。先看每个实例的dm.ini里面至少要把下面这些参数确认到位INSTANCE_NAME PROD_DM01 PORT_NUM 5236 MAL_INI 1 ARCH_INI 1 DMDSC_DUAL 1MAL_INI等于 1 表示启用 MAL 通信子系统DMDSC 实例互联和数据守护的日志传输都依赖这套通道。ARCH_INI等于 1 表示启用归档配置没有归档就没有日志发送。DMDSC_DUAL这类共享集群相关的参数按官方文档与版本要求设置不要随意改动。再看dmmal.ini。它主要描述每个实例的 MAL 监听地址和端口我通常把心跳网段的独立 IP 填在这里MAL_CHECK_INTERVAL 5 MAL_CONN_FAIL_INTERVAL 10 [MAL_INST1] MAL_INST_NAME PROD_DM01 MAL_HOST 主节点1内部通信IP MAL_PORT 6101 MAL_DW_PORT 6102 [MAL_INST2] MAL_INST_NAME PROD_DM02 MAL_HOST 主节点2内部通信IP MAL_PORT 6103 MAL_DW_PORT 6104灾备集群同样有自己的一份dmmal.ini实例名换成灾备端的实例名IP 换成灾备端节点地址。端口不要跟业务端口混用。归档配置dmarch.ini是日志发送的核心策略。生产端每个实例都要配一个本地归档和一个远程归档。本地归档把日志存到本地目录用于故障恢复远程归档把日志实时发送到灾备实例。[ARCHIVE_LOCAL1] ARCH_TYPE LOCAL ARCH_DEST /dm/arch ARCH_FILE_SIZE 512 ARCH_SPACE_LIMIT 102400 [ARCHIVE_REALTIME1] ARCH_TYPE REMOTE ARCH_DEST 灾备端目标实例标识 ARCH_TIMER 3ARCH_TIMER3表示每隔 3 秒尝试发送一次归档日志。这个数值不要太极端设成 1 会频繁建立连接设成 10 会让 RPO 变差。灾备端这边一般只配本地归档用于接收和保存来自生产端的日志文件不需要再往别处转。守护进程的配置文件是dmwatcher.ini主备集群各自维护一个守护进程。配置内容大致描述守护组名、集群内包含哪些实例、实时归档开关等。关键字段需要注意的包括守护模式、切换时长、错误处理间隔等按实际网络状况调整。网络状况差时错误处理间隔要适当加大避免网络抖动直接触发误切换。最后是监视器的dmmonitor.ini。监视器可以单独放在一台机器上接入生产端和灾备端所有实例的 MAL 地址。这样它的视角是整个灾备体系能看到两边的状态也能下发切换命令。3.4 启动顺序与首次建立同步配置文件的启动顺序有讲究不能乱点。先启动灾备端各 DMDSC 实例再启动生产端各实例保证生产端实例起来之后能立刻在 MAL 通道里找到对端节点。启动方式要看 DM8 是否配置了服务比较顺手的做法是直接用dm_ini指定实例路径后台启动。实例全部起来后启动各节点的守护进程dmwatcher /dm/data/PRODDB/dmwatcher.ini灾备端和生产端的守护进程都起来后最后启动监视器dmmonitor /dm/data/dmmonitor.ini进入监视器命令行后可以先看整体状态show global info正常情况下生产端集群各实例状态应显示为主库 OPEN灾备端集群显示为备库 MOUNT 或接管状态。如果两端实例的日志都实时写到了灾备端说明链路已经通了一半。接下来要在生产端发起一次增量备份或直接使用日志重演完成初始数据同步。最省事的方式是在生产端做一个在线备份把备份恢复到灾备端然后开启日志同步追赶剩余日志。第一次搭建时普遍的做法是先全量恢复再让日志同步追平避免从零开始重演造成漫长的追赶。初始化同步完成后在监视器里看到两边的 LSN 或归档日志序号接近一致状态处于一主一备灾备体系就基本可用了。3.5 计划内切换与灾难接管演示灾备体系只有真正切过一次你才敢在故障时依赖它。日常运维中比较高频的操作是计划内切换比如生产端要做硬件升级。操作路径是在监视器里把角色主动调整先确保灾备端日志追平再执行切换命令让灾备集群整体升主。login switchover 守护组名.灾备实例名执行后等待两个集群完成角色互换原灾备集群对外提供服务原生产集群降级为备。切换完成后要重点检查应用能否正常连接新主库以及新的备库是否重新开始接收日志。遇到过最迷惑的情况是“切完看到应用已经恢复但新的备库归档没接上”原因是切完没有重新拉起归档任务后续全靠人工盯着。灾难接管更直接不需要等生产端回应在监视器执行接管命令takeover 守护组名.灾备实例名接管会直接把灾备集群拉成主库。执行前务必要确认原生产端确实已经没法恢复服务避免两边同时在写数据形成“双主”的局面。双主对数据造成的伤害比单个故障更大处理起来也更痛苦。4. 常见问题与排查技巧实录4.1 同步延时越拉越大到底卡在哪里灾备端日志重演速度跟不上生产端日志产生速度是最常见的隐形问题。表象是监视器里日志序号差距越来越大重启灾备实例也没用。排查方向我从难到易排三个网络吞吐是不是被打满。DMDSC 实例间会产生大量缓存融合消息日志同步也走内部网络业务高峰期带宽被占满日志自然传不过来。灾备端重演线程是否被其他任务阻塞。比如灾备端接了查询业务大量慢查询占用系统资源日志重演排队。本地归档目录和灾备接收目录是否落在慢磁盘上。灾备端如果用了低性能存储写日志文件本身就会拖慢重演进度。定位这类问题我习惯先在操作系统层面看网卡流量和磁盘 IO 等待时间再看数据库会话里有没有堆积的归档任务最后才动数据库参数。盲调参数很容易把问题带偏。4.2 切换失败或切换后异常的几个高频坑切换失败的案例我总结出几个反复出现的套路。第一个坑备库日志没追平就切换。很多人看到备库状态是正常的就忽略了日志进度存在滞后。切过去之后业务虽然起来但最近几分钟的数据丢了属于典型的 RPO 不达标。规范做法是切换前必须确认日志进度已追平或者在手动模式下执行日志补齐后再切换。第二个坑两边实例名或 MAL 配置不一致。DMDSC 要求生产端实例名、MAL 实例名、守护组里的实例标识完全对应。曾经遇到过一个灾备端实例名少写了一个字母主端日志发送一直重试排错半天才发现是笔误。这类问题很难靠报错信息直接看出来必须逐项核对配置文件。第三个坑切换后没有及时修改连接入口。数据库角色切过去了应用配置还指向原主库地址业务自然连不上。生产中常借助统一的服务名或负载均衡入口来规避让连接地址不绑定单机实例。建议无论如何都用一个虚拟服务地址对外切换时只改映射关系。第四个坑故障接管后原主库又恢复自行启动。这时两边都在写同一套数据文件如果是共享存储故障恢复或者各自写自己的副本立即就会脑裂。应急处理方式是把原主库强制离线并停止千万不要抱着侥幸心理同时保留两边写入。4.3 日常巡检清单与预警阈值灾备系统不是配好就不管的我给自己定了一套最低限度的巡检清单按天和按周分开每天检查一次监视器状态确认生产端和灾备端角色没有漂移日志发送连续没有长时间未成功发送的归档。每天看一次灾备端磁盘剩余空间特别是归档目录和数据文件目录空间不足会直接导致接收中断。每周做一次日志追平验证选择一个低峰时段对比主备两端最新日志时间点评估当前同步延迟是否在可接受范围内。每周检查一次网络连通与丢包率内部通信网一旦开始丢包DMDSC 实例之间会出现频繁的缓存融合等待业务性能也会被拖累。定期做切换演练至少一个季度一次。演练不只是验证技术也是验证人和流程。真正出灾难时最怕的不是数据库切不动而是没人知道怎么切、切完联系谁、应用入口在哪里改。预警阈值方面同步延迟超过 30 秒就要关注超过 5 分钟必须介入处理。本地归档目录使用率超过 80% 就要开始清理或扩容。监控方式可以接入现有运维平台的告警通道但不能只依赖平台命令行巡检同样要有。# 一个常用的检查思路在监视器里观察两端状态 show global info # 查看当前守护模式下各组的角色、实例状态、日志进度5. 经验补充分享最后聊一点实际折腾出来的体会。第一灾备建设里最容易被低估的不是技术难度而是对 RPO 和 RTO 的确认。很多人上来就问“能不能支持秒级切换”却没有先确认业务能丢多少数据。我建议接到灾备需求时先让应用方把两个数字写清楚再倒推要用实时同步还是准实时同步、网络带宽够不够、是否需要最大保护模式。指标模糊后面所有参数都很难定。第二DMDSC 灾备体系里的“切换”必须当成一个常规操作来练。我有一个习惯每次演练结束之后整理一份切换操作单写明具体命令、需要观察的状态、各类异常分支。真正故障时照着单子执行比临场想命令靠谱得多。操作单也要随环境和版本变更及时更新旧单子最坑人。第三备份仍然不能丢。灾备集群是“热”的但它防不住逻辑错误比如某个人手滑执行了一条批量删除这条 delete 会通过日志同步原样带到灾备端。遇到这种情况任何基于日志重演的灾备体系都救不了你只有时间点备份才能恢复。灾备和备份从来都是搭档不是替代关系。如果你正准备给 DM8 核心系统做灾备我建议从最小环境开始验证一套生产 DMDSC、一套灾备 DMDSC、一台监视器先把日志同步跑通再做第一次切换演练。整个链路一旦转过一圈后面再加节点、加异地机房都只是量的扩展架构思路是完全一致的。
