DM8 单机双节点 DSC 集群部署与故障验证共享存储、CSS、ASM 与节点接管一、DSC 与普通主备的本质差异普通主备架构中每个实例有自己的一套数据库文件主库通过日志传输保持备库数据一致。DSC 的两个数据库实例则共享数据文件应用 / JMeterDSC 服务名DSC08236DSC18237ASM0 / ASM1共享 DMDATA共享 DMARCHCSS0 / CSS1DCR / VOTE这意味着DSC0 写入的数据不需要“复制”给 DSC1DSC1 能立即读到相同数据是因为两个节点访问同一套数据库文件节点故障时存活节点继续访问共享存储集群成员关系、投票和资源协调必须先于数据库实例工作。因此DSC 部署不能只关注dm.ini。底层 DCR、VOTE、CSS 和 ASM 任一环节不正确数据库层都无法形成正常集群。二、实验环境本次记录中的环境如下项目配置操作系统银河麒麟 V10 SP1 x86_64数据库版本DM8 Enterprise 8.1.5.60DM 安装目录/home/dmdba/dmdbms服务器地址192.168.200.253DSC0 数据库端口8236DSC1 数据库端口8237MAL 端口8336 / 8337ASM 端口8436 / 8437CSS 端口8636 / 8637共享设备规划如下用途设备DCR/dev/dm/asm-dmdcrVOTE/dev/dm/asm-dmvote数据磁盘/dev/dm/asm-dmdata归档磁盘/dev/dm/asm-dmarch虽然是单机部署两个逻辑节点仍应使用不同实例名、端口、配置目录和运行目录。这样才能模拟节点独立启动、停止和恢复的过程。三、部署前检查1. 用户与设备权限数据库、CSS 和 ASM 进程通常由dmdba用户运行。首先确认裸设备存在ls-l/dev/dm/asm-dmdcrls-l/dev/dm/asm-dmvotels-l/dev/dm/asm-dmdatals-l/dev/dm/asm-dmarch需要重点检查设备属主、属组是否允许dmdba读写设备映射在重启后是否仍然存在DCR、VOTE、DATA、ARCH 是否误指向同一块设备设备是否已经被其他实验环境占用udev 规则是否保证设备名稳定。裸设备权限错误时ASM 可能直接启动失败设备名变化时则会出现“配置正确但找不到磁盘”的现象。2. 端口冲突单机双节点所有监听地址都落在同一台主机上端口冲突比多机部署更常见ss-lntp|grep-E8236|8237|8336|8337|8436|8437|8636|8637如果旧的 DSC、主备或 DMDPC 进程没有停止即使数据库端口不冲突也可能占用 MAL、ASM 或 CSS 端口。3. 资源边界单机部署时应先停止无关数据库实例。尤其不要在压测期间同时运行DSC0 DSC1 DW01 GRP3_RT_01 GRP3_RT_02 GRP3_LOCAL_01这些实例会共同竞争 CPU、内存和磁盘导致性能曲线的变化无法归因。四、为什么 DCR 和 VOTE 必须最先完成DCR 保存集群控制信息VOTE 用于成员投票和脑裂防护。二者是 CSS 判断节点身份和集群状态的基础。部署顺序应当遵循操作系统与裸设备 ↓ DCR / VOTE 初始化 ↓ CSS0 / CSS1 ↓ ASM0 / ASM1 ↓ DMDATA / DMARCH 磁盘组 ↓ DSC 数据库初始化 ↓ DSC0 / DSC1最常见的错误是跳过底层检查直接启动 DMSERVER。此时日志只会显示无法连接 ASM、无法读取集群控制信息或节点未加入集群而问题根源实际上在 DCR、VOTE 或 CSS。五、CSS 与 ASM 的配置要点1. CSSCSS 负责集群成员管理、资源协调和节点状态判断。双节点配置必须保证节点编号唯一CSS 实例名唯一CSS 通信端口不冲突两个节点引用相同的 DCR 和 VOTEOGUID 与所属 DSC 集群一致。启动后应先通过 CSS 监视工具确认两个逻辑节点均已加入再继续启动 ASM。2. ASMASM 向数据库实例提供共享存储。ASM0 和 ASM1 需要访问相同的数据与归档裸设备但各自具有独立的实例名和通信端口。创建磁盘组时应将/dev/dm/asm-dmdata → DMDATA /dev/dm/asm-dmarch → DMARCH数据库初始化目录、数据文件和归档目标应引用 ASM 磁盘组而不是某个节点自己的普通文件系统目录。否则即使两个实例都能启动也不是真正的共享存储 DSC。六、初始化 DSC 数据库在 CSS 和 ASM 均正常后初始化 DSC 数据库。两个节点的dm.ini要保证以下关系# DSC0 INSTANCE_NAME DSC0 PORT_NUM 8236 # DSC1 INSTANCE_NAME DSC1 PORT_NUM 8237此外还要分别配置 MAL 通信DSC0 MAL8336 DSC1 MAL8337数据库级配置的关键不是单个参数而是整体一致性两个节点必须属于同一数据库数据文件、控制文件和日志规划一致节点号、实例名和端口唯一ASM 连接信息正确DCR 中登记的节点与实际配置一致。七、启动顺序与状态确认推荐启动顺序如下# 1. 启动 CSS0、CSS1# 2. 启动 ASM0、ASM1# 3. 检查 DMDATA、DMARCH 磁盘组# 4. 启动 DSC0、DSC1# 5. 启动 dmcssm 观察集群关闭时采用相反顺序DMSERVER → ASM → CSS最终实验状态为DSC0 Control Node OPEN DSC1 Normal Node OPEN n_ok_ep 2这里的n_ok_ep2表示两个数据库端点均处于可用状态。只看到两个dmserver进程并不能证明集群正常必须结合dmcssm中的节点角色、工作状态和有效端点数判断。八、共享数据验证在 DSC0 建表并写入CREATETABLEDSC_TEST(IDINT,WRITE_NODEVARCHAR(20),CREATE_TIMEDATETIME);INSERTINTODSC_TESTVALUES(1,DSC0,SYSDATE);COMMIT;随后连接 DSC1SELECT*FROMDSC_TESTORDERBYID;如果 DSC1 能立即查询到 DSC0 写入的数据可以证明两个节点访问同一数据库。但为了把证据链做完整还应记录SELECTINSTANCE_NAME,STATUS$,MODE$FROMV$INSTANCE;这样截图中可以同时看到“当前连接的是 DSC1”和“查询到了 DSC0 写入的数据”避免把同一个端口的重复查询误认为跨节点验证。九、单节点故障验证实验中停止 DSC1 后dmcssm显示DSC0 OPEN WORKING OK TRUE DSC1 OPEN WORKING ERROR FALSE n_ok_ep 1此时在 DSC0 上仍然可以执行查询和写入。测试表已有1552行并在故障期间继续插入INSERTINTODSC_TESTVALUES(1553,DSC1_DOWN_WRITE,SYSDATE);COMMIT;这项验证证明单节点故障没有使共享数据库整体不可用存活节点仍可处理写事务故障节点恢复后应重新加入相同集群而不是重新初始化数据库高可用依赖服务名和客户端重连不能只测试存活节点固定端口。十、压力下的 DSC 故障故障测试使用 10 线程、60 秒升压和 720 秒持续时间。三轮单节点故障结果如下场景总请求失败错误率稳态 TPSCV普通节点下线首轮489,303100.0020%701.16414.229%普通节点下线复测463,731100.0022%661.98017.160%控制节点下线481,198100.0021%687.37314.797%错误类型主要是 JDBC 连接重置和网络通信异常。这说明已经建立在故障节点上的连接会失败但业务通过重连或节点重选后可以恢复。图 1 DSC 控制节点下线场景的 JMeter HTML 原始页面截图。以控制节点下线为例21:52:14 开始下线 21:53:37 停机操作完成 第 200 秒窗口出现 10 个失败 第 210、220 秒窗口无完成请求 第 230 秒窗口恢复成功吞吐由 10 秒窗口只能得出“业务约 30 秒级恢复”合理观察区间约为 2040 秒。停机命令执行了 83 秒但这不是业务 RTO因为存活节点在停机命令结束前已经开始恢复服务。十一、摸高结果80 线程成功不等于 80 线程才到极限DSC 摸高覆盖 580 线程所有有效轮次均为零错误线程数稳态 TPSCV平均响应5773.0678.315%—10668.120711.7004.550%7.795%0.976 ms20659.9506.023%1.028 ms30593.3107.351%1.012 ms40576.8204.810%0.958 ms50580.67010.332%1.123 ms60619.3107.634%1.169 ms80603.9104.514%1.253 ms图 2 DSC 80 线程摸高轮次的 JMeter Dashboard 原始截图。图 3 DSC 80 线程摸高轮次的 JMeter HTML 吞吐页面。结论本次最高验证到 80 线程且零错误520 线程已经接近本环境的吞吐平台3080 线程主要落在约 577619 TPS增加线程没有带来线性吞吐增长80 线程表示“仍能承载”不表示“到 80 线程才达到性能上限”。十二、从双节点 DSC 扩展到 DSC 加实时备库实验后续还形成了DSC0 DSC1 DW01架构实例数据库端口MALWatcher实例守护DSC08236833687368836DSC18237833787378837DW018238833887388838守护组为GDSCDW1数据守护 OGUID 为826072DSC CSS OGUID 为826071。这两个 OGUID 用途不同不能混用。创建 DW01 时不能单独初始化一个新库而应使用 DMRMAN 对 DSC 数据库进行备份在 DW01 还原数据执行恢复更新 DB_MAGIC配置与 DSC 一致的初始化参数配置实时归档、MAL 和 Watcher将 DW01 设置为 STANDBY。这一架构同时获得了DSC 节点级高可用共享存储数据库之外的独立实时副本DSC 整体故障或共享存储故障时的灾备接管基础。十三、部署中最容易卡住的地方1. 启动顺序错误数据库依赖 ASMASM 依赖 CSSCSS 依赖 DCR/VOTE。应从底层向上启动从上层向下关闭。2. 裸设备权限或映射变化普通目录权限正确并不能代表裸设备可读写。重启后设备名变化也会使原配置失效。3. 把跨节点查询当作复制验证DSC 使用共享数据文件DSC1 读到 DSC0 的数据并不是日志复制。博客和报告中应使用“共享数据可见性”不要使用“主备同步成功”描述。4. 固定端口掩盖客户端高可用问题直接连接 DSC0 或 DSC1只能验证该节点。业务必须通过 DSC 服务名访问才能验证节点重选和重连。十四、结论本次实验完成了双节点 DSC 从裸设备、DCR/VOTE、CSS、ASM、数据库初始化到节点启动的完整链路。DSC0 和 DSC1 均处于 OPEN 状态n_ok_ep2通过跨节点写入与查询验证了共享数据可见性。持续压力下停止普通节点或控制节点整体错误率约为0.002%存活节点继续提供服务。现有 10 秒窗口支持“业务约 30 秒级恢复”的判断但不足以给出秒级精确 RTO。摸高测试已验证至 80 线程零错误但吞吐在低并发已进入平台区因此不能将 80 线程直接解释为生产容量上限。
DM8 单机双节点 DSC 集群部署与故障验证：共享存储、CSS、ASM 与节点接管
发布时间：2026/7/29 15:52:05
DM8 单机双节点 DSC 集群部署与故障验证共享存储、CSS、ASM 与节点接管一、DSC 与普通主备的本质差异普通主备架构中每个实例有自己的一套数据库文件主库通过日志传输保持备库数据一致。DSC 的两个数据库实例则共享数据文件应用 / JMeterDSC 服务名DSC08236DSC18237ASM0 / ASM1共享 DMDATA共享 DMARCHCSS0 / CSS1DCR / VOTE这意味着DSC0 写入的数据不需要“复制”给 DSC1DSC1 能立即读到相同数据是因为两个节点访问同一套数据库文件节点故障时存活节点继续访问共享存储集群成员关系、投票和资源协调必须先于数据库实例工作。因此DSC 部署不能只关注dm.ini。底层 DCR、VOTE、CSS 和 ASM 任一环节不正确数据库层都无法形成正常集群。二、实验环境本次记录中的环境如下项目配置操作系统银河麒麟 V10 SP1 x86_64数据库版本DM8 Enterprise 8.1.5.60DM 安装目录/home/dmdba/dmdbms服务器地址192.168.200.253DSC0 数据库端口8236DSC1 数据库端口8237MAL 端口8336 / 8337ASM 端口8436 / 8437CSS 端口8636 / 8637共享设备规划如下用途设备DCR/dev/dm/asm-dmdcrVOTE/dev/dm/asm-dmvote数据磁盘/dev/dm/asm-dmdata归档磁盘/dev/dm/asm-dmarch虽然是单机部署两个逻辑节点仍应使用不同实例名、端口、配置目录和运行目录。这样才能模拟节点独立启动、停止和恢复的过程。三、部署前检查1. 用户与设备权限数据库、CSS 和 ASM 进程通常由dmdba用户运行。首先确认裸设备存在ls-l/dev/dm/asm-dmdcrls-l/dev/dm/asm-dmvotels-l/dev/dm/asm-dmdatals-l/dev/dm/asm-dmarch需要重点检查设备属主、属组是否允许dmdba读写设备映射在重启后是否仍然存在DCR、VOTE、DATA、ARCH 是否误指向同一块设备设备是否已经被其他实验环境占用udev 规则是否保证设备名稳定。裸设备权限错误时ASM 可能直接启动失败设备名变化时则会出现“配置正确但找不到磁盘”的现象。2. 端口冲突单机双节点所有监听地址都落在同一台主机上端口冲突比多机部署更常见ss-lntp|grep-E8236|8237|8336|8337|8436|8437|8636|8637如果旧的 DSC、主备或 DMDPC 进程没有停止即使数据库端口不冲突也可能占用 MAL、ASM 或 CSS 端口。3. 资源边界单机部署时应先停止无关数据库实例。尤其不要在压测期间同时运行DSC0 DSC1 DW01 GRP3_RT_01 GRP3_RT_02 GRP3_LOCAL_01这些实例会共同竞争 CPU、内存和磁盘导致性能曲线的变化无法归因。四、为什么 DCR 和 VOTE 必须最先完成DCR 保存集群控制信息VOTE 用于成员投票和脑裂防护。二者是 CSS 判断节点身份和集群状态的基础。部署顺序应当遵循操作系统与裸设备 ↓ DCR / VOTE 初始化 ↓ CSS0 / CSS1 ↓ ASM0 / ASM1 ↓ DMDATA / DMARCH 磁盘组 ↓ DSC 数据库初始化 ↓ DSC0 / DSC1最常见的错误是跳过底层检查直接启动 DMSERVER。此时日志只会显示无法连接 ASM、无法读取集群控制信息或节点未加入集群而问题根源实际上在 DCR、VOTE 或 CSS。五、CSS 与 ASM 的配置要点1. CSSCSS 负责集群成员管理、资源协调和节点状态判断。双节点配置必须保证节点编号唯一CSS 实例名唯一CSS 通信端口不冲突两个节点引用相同的 DCR 和 VOTEOGUID 与所属 DSC 集群一致。启动后应先通过 CSS 监视工具确认两个逻辑节点均已加入再继续启动 ASM。2. ASMASM 向数据库实例提供共享存储。ASM0 和 ASM1 需要访问相同的数据与归档裸设备但各自具有独立的实例名和通信端口。创建磁盘组时应将/dev/dm/asm-dmdata → DMDATA /dev/dm/asm-dmarch → DMARCH数据库初始化目录、数据文件和归档目标应引用 ASM 磁盘组而不是某个节点自己的普通文件系统目录。否则即使两个实例都能启动也不是真正的共享存储 DSC。六、初始化 DSC 数据库在 CSS 和 ASM 均正常后初始化 DSC 数据库。两个节点的dm.ini要保证以下关系# DSC0 INSTANCE_NAME DSC0 PORT_NUM 8236 # DSC1 INSTANCE_NAME DSC1 PORT_NUM 8237此外还要分别配置 MAL 通信DSC0 MAL8336 DSC1 MAL8337数据库级配置的关键不是单个参数而是整体一致性两个节点必须属于同一数据库数据文件、控制文件和日志规划一致节点号、实例名和端口唯一ASM 连接信息正确DCR 中登记的节点与实际配置一致。七、启动顺序与状态确认推荐启动顺序如下# 1. 启动 CSS0、CSS1# 2. 启动 ASM0、ASM1# 3. 检查 DMDATA、DMARCH 磁盘组# 4. 启动 DSC0、DSC1# 5. 启动 dmcssm 观察集群关闭时采用相反顺序DMSERVER → ASM → CSS最终实验状态为DSC0 Control Node OPEN DSC1 Normal Node OPEN n_ok_ep 2这里的n_ok_ep2表示两个数据库端点均处于可用状态。只看到两个dmserver进程并不能证明集群正常必须结合dmcssm中的节点角色、工作状态和有效端点数判断。八、共享数据验证在 DSC0 建表并写入CREATETABLEDSC_TEST(IDINT,WRITE_NODEVARCHAR(20),CREATE_TIMEDATETIME);INSERTINTODSC_TESTVALUES(1,DSC0,SYSDATE);COMMIT;随后连接 DSC1SELECT*FROMDSC_TESTORDERBYID;如果 DSC1 能立即查询到 DSC0 写入的数据可以证明两个节点访问同一数据库。但为了把证据链做完整还应记录SELECTINSTANCE_NAME,STATUS$,MODE$FROMV$INSTANCE;这样截图中可以同时看到“当前连接的是 DSC1”和“查询到了 DSC0 写入的数据”避免把同一个端口的重复查询误认为跨节点验证。九、单节点故障验证实验中停止 DSC1 后dmcssm显示DSC0 OPEN WORKING OK TRUE DSC1 OPEN WORKING ERROR FALSE n_ok_ep 1此时在 DSC0 上仍然可以执行查询和写入。测试表已有1552行并在故障期间继续插入INSERTINTODSC_TESTVALUES(1553,DSC1_DOWN_WRITE,SYSDATE);COMMIT;这项验证证明单节点故障没有使共享数据库整体不可用存活节点仍可处理写事务故障节点恢复后应重新加入相同集群而不是重新初始化数据库高可用依赖服务名和客户端重连不能只测试存活节点固定端口。十、压力下的 DSC 故障故障测试使用 10 线程、60 秒升压和 720 秒持续时间。三轮单节点故障结果如下场景总请求失败错误率稳态 TPSCV普通节点下线首轮489,303100.0020%701.16414.229%普通节点下线复测463,731100.0022%661.98017.160%控制节点下线481,198100.0021%687.37314.797%错误类型主要是 JDBC 连接重置和网络通信异常。这说明已经建立在故障节点上的连接会失败但业务通过重连或节点重选后可以恢复。图 1 DSC 控制节点下线场景的 JMeter HTML 原始页面截图。以控制节点下线为例21:52:14 开始下线 21:53:37 停机操作完成 第 200 秒窗口出现 10 个失败 第 210、220 秒窗口无完成请求 第 230 秒窗口恢复成功吞吐由 10 秒窗口只能得出“业务约 30 秒级恢复”合理观察区间约为 2040 秒。停机命令执行了 83 秒但这不是业务 RTO因为存活节点在停机命令结束前已经开始恢复服务。十一、摸高结果80 线程成功不等于 80 线程才到极限DSC 摸高覆盖 580 线程所有有效轮次均为零错误线程数稳态 TPSCV平均响应5773.0678.315%—10668.120711.7004.550%7.795%0.976 ms20659.9506.023%1.028 ms30593.3107.351%1.012 ms40576.8204.810%0.958 ms50580.67010.332%1.123 ms60619.3107.634%1.169 ms80603.9104.514%1.253 ms图 2 DSC 80 线程摸高轮次的 JMeter Dashboard 原始截图。图 3 DSC 80 线程摸高轮次的 JMeter HTML 吞吐页面。结论本次最高验证到 80 线程且零错误520 线程已经接近本环境的吞吐平台3080 线程主要落在约 577619 TPS增加线程没有带来线性吞吐增长80 线程表示“仍能承载”不表示“到 80 线程才达到性能上限”。十二、从双节点 DSC 扩展到 DSC 加实时备库实验后续还形成了DSC0 DSC1 DW01架构实例数据库端口MALWatcher实例守护DSC08236833687368836DSC18237833787378837DW018238833887388838守护组为GDSCDW1数据守护 OGUID 为826072DSC CSS OGUID 为826071。这两个 OGUID 用途不同不能混用。创建 DW01 时不能单独初始化一个新库而应使用 DMRMAN 对 DSC 数据库进行备份在 DW01 还原数据执行恢复更新 DB_MAGIC配置与 DSC 一致的初始化参数配置实时归档、MAL 和 Watcher将 DW01 设置为 STANDBY。这一架构同时获得了DSC 节点级高可用共享存储数据库之外的独立实时副本DSC 整体故障或共享存储故障时的灾备接管基础。十三、部署中最容易卡住的地方1. 启动顺序错误数据库依赖 ASMASM 依赖 CSSCSS 依赖 DCR/VOTE。应从底层向上启动从上层向下关闭。2. 裸设备权限或映射变化普通目录权限正确并不能代表裸设备可读写。重启后设备名变化也会使原配置失效。3. 把跨节点查询当作复制验证DSC 使用共享数据文件DSC1 读到 DSC0 的数据并不是日志复制。博客和报告中应使用“共享数据可见性”不要使用“主备同步成功”描述。4. 固定端口掩盖客户端高可用问题直接连接 DSC0 或 DSC1只能验证该节点。业务必须通过 DSC 服务名访问才能验证节点重选和重连。十四、结论本次实验完成了双节点 DSC 从裸设备、DCR/VOTE、CSS、ASM、数据库初始化到节点启动的完整链路。DSC0 和 DSC1 均处于 OPEN 状态n_ok_ep2通过跨节点写入与查询验证了共享数据可见性。持续压力下停止普通节点或控制节点整体错误率约为0.002%存活节点继续提供服务。现有 10 秒窗口支持“业务约 30 秒级恢复”的判断但不足以给出秒级精确 RTO。摸高测试已验证至 80 线程零错误但吞吐在低并发已进入平台区因此不能将 80 线程直接解释为生产容量上限。
