DM故障场景测试1

本文详细描述了在达梦数据库中,主库down机后的故障处理流程,包括备库down机后的watcher动作、主库重启与正常服务恢复步骤,以及备库修复后如何重新加入集群。重点讨论了watcher的角色和数据库状态转换规则。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

目录

一、场景假设:

1)、测试环境

2)、测试场景

二、开始测试:

1、备库down机后watcher和库的动作

2、重启主库,使之可以继续正常提供服务

3、备库硬件修复好后,又如何重新加入到集群中

三、总结


一、场景假设:

1)、测试环境

主机名实例名/监视器初始状态
dm21GRP1_RT_01备库
dm22GRP1_RT_02主库

它们是实时主备集群关系,有主机名为dm23的确认监示器。

2)、测试场景

一开始都是运行正常的,某天备库主机因硬件损坏导致突然down机,其修复时间未知,在备库未修复好的这段时间里需要对主库进行维护(比如调整参数等等),重新启动主库,如何使之可以继续正常提供服务?哪么后继备库硬件修复好后,又如何重新加入到集群中?哪么在这其中watcher和库又发生了哪些动作?

二、开始测试:

1、备库down机后watcher和库的动作

为了测试环境真实,现在假设备库因硬件损坏导致突然down机,在主库上做如下事务(注意:据dm的原理来说只有做事务才能看到后继效果):

SQL> insert into t(i) values(2);

同时在监示器上显示变化如下:

[monitor]         2022-04-24 13:14:29: Dmwatcher process GRP1_RT_02 status switching [OPEN-->MON CONFIRM] 
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN            CLSN            
                  2022-04-24 13:14:35  MON CONFIRM    OK        GRP1_RT_02       SUSPEND     PRIMARY   VALID    30       66101           66104           

[monitor]         2022-04-24 13:14:30: Dmwatcher process GRP1_RT_02 status switching [MON CONFIRM-->FAILOVER] 
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN            CLSN            
                  2022-04-24 13:14:36  FAILOVER       OK        GRP1_RT_02       SUSPEND     PRIMARY   VALID    30       66101           66104           

[monitor]         2022-04-24 13:14:32: Dmwatcher process GRP1_RT_02 status switching [FAILOVER-->OPEN] 
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN            CLSN            
                  2022-04-24 13:14:38  OPEN           OK        GRP1_RT_02       OPEN        PRIMARY   VALID    30       66104           66104 

主库查询:

SQL> select * from v$arch_status ;

LINEID     ARCH_TYPE ARCH_DEST  ARCH_STATUS ARCH_SRC  
---------- --------- ---------- ----------- ----------
1          REALTIME  GRP1_RT_01 INVALID     GRP1_RT_02
2          LOCAL     /dm/arch   VALID       GRP1_RT_02

可知:在备库突然down机时,在主库做事务,主库的watcher本身自己会变为FAILOVER的状态,并且将主库暂时变成suspend的状态,此时主库会将备库的规档修改为失效,之后watcher又会将主库变为OPEN的状态!

2、重启主库,使之可以继续正常提供服务

在备库未修复好的这段时间里需要对主库进行维护(比如调整参数等等),重新启动主库。

[root@dm22 ~]# /dm/dmdbms/bin/DmWatcherServiceDM stop                                     
[root@dm22 ~]# /dm/dmdbms/bin/DmServiceDM stop 		
[root@dm22 ~]# reboot

此时重启主库是只能启到mount状态

[dmdba@dm22 ~]$ disql  sysdba/SYSDBA:32142

Server[LOCALHOST:32142]:mode is primary, state is mount
login used time : 1.409(ms)
disql V8
SQL> 

此时即使是启动守护进程,也不能拉起主机为open(估计是跟规档模式有关!),经实验,要等备库正常启动了,主库才能被watcher拉到open!

哪么问题来了,现在备库还未修复,如何使主库可以继续正常提供服务?答案是:只能停watcher,让主库变成单机normal,即是:做 ./DmWatcherServiceDM stop;ALTER DATABASE NORMAL;ALTER DATABASE OPEN;【注意:如果不做NORMAL开库,直接做force open的话,则主库会挂起,库也不能用!】

其测试如下:

1)、如果不做NORMAL开库,直接做force open的话,则主库会挂起,库也不能用!

[dmdba@dm22 ~]$ disql  sysdba/SYSDBA:32142

Server[LOCALHOST:32142]:mode is primary, state is mount
login used time : 1.409(ms)
disql V8
SQL> SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1);
DMSQL executed successfully
used time: 5.406(ms). Execute id is 100.
SQL>  alter database open;
 alter database open;
[-516]:Error in line: 1
None normal mode open force needed.
used time: 0.490(ms). Execute id is 0.
SQL> 
SQL> 
SQL> select * from v$instance;

LINEID     NAME       INSTANCE_NAME INSTANCE_NUMBER HOST_NAME SVR_VERSION                DB_VERSION          START_TIME          STATUS$ MODE$   OGUID      
---------- ---------- ------------- --------------- --------- -------------------------- ------------------- ------------------- ------- ------- -----------
           DSC_SEQNO   DSC_ROLE
           ----------- --------
1          GRP1_RT_02 GRP1_RT_02    1               dm22      DM Database Server x64 V8  DB Version: 0x7000c 2022-04-24 13:33:20 MOUNT   PRIMARY 453331
           0           NULL


used time: 2.679(ms). Execute id is 101.
SQL> alter database open force;
alter database open force;
[-720]:Error in line: 1
Dmwatcher is active, or current configuration(ALTER_MODE_STATUS) not allowed to alter database.
used time: 0.321(ms). Execute id is 0.
SQL> SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1);
DMSQL executed successfully
used time: 4.043(ms). Execute id is 102.


[root@dm22 ~]# /dm/dmdbms/bin/DmWatcherServiceDM stop 


SQL> alter database open force;
executed successfully
used time: 379.897(ms). Execute id is 0.
SQL> select * from v$instance;

LINEID     NAME       INSTANCE_NAME INSTANCE_NUMBER HOST_NAME SVR_VERSION                DB_VERSION          START_TIME          STATUS$ MODE$   OGUID      
---------- ---------- ------------- --------------- --------- -------------------------- ------------------- ------------------- ------- ------- -----------
           DSC_SEQNO   DSC_ROLE
           ----------- --------
1          GRP1_RT_02 GRP1_RT_02    1               dm22      DM Database Server x64 V8  DB Version: 0x7000c 2022-04-24 13:33:20 SUSPEND PRIMARY 453331
           0           NULL


used time: 0.948(ms). Execute id is 104.
SQL> alter database open;
alter database open;
[-516]:Error in line: 1
None normal mode open force needed.
used time: 0.339(ms). Execute id is 0.

 对于这一点,还可以看到:当库为primary时,OPEN 状态SUSPEND 是不能相互转换的!

2)、做NORMAL开库,使主库可以继续正常提供服务。

[root@dm22 ~]# /dm/dmdbms/bin/DmWatcherServiceDM stop
[dmdba@dm22 ~]$ disql  sysdba/SYSDBA:32142

Server[LOCALHOST:32142]:mode is primary, state is mount
login used time : 3.562(ms)
disql V8
SQL> ALTER DATABASE NORMAL;
executed successfully
used time: 22.176(ms). Execute id is 0.
SQL> ALTER DATABASE OPEN;
executed successfully
used time: 386.850(ms). Execute id is 0.

SQL> select * from v$instance;

LINEID     NAME       INSTANCE_NAME INSTANCE_NUMBER HOST_NAME SVR_VERSION                DB_VERSION          START_TIME          STATUS$ MODE$  OGUID      
---------- ---------- ------------- --------------- --------- -------------------------- ------------------- ------------------- ------- ------ -----------
           DSC_SEQNO   DSC_ROLE
           ----------- --------
1          GRP1_RT_02 GRP1_RT_02    1               dm22      DM Database Server x64 V8  DB Version: 0x7000c 2022-04-24 15:49:41 OPEN    NORMAL 453331
           0           NULL


used time: 2.003(ms). Execute id is 300.
SQL> insert into t(i) values(5);
affect rows 1

used time: 1.896(ms). Execute id is 301.
SQL> commit;
executed successfully
used time: 0.878(ms). Execute id is 302.
SQL> 

3、备库硬件修复好后,又如何重新加入到集群中

当备库修好了过后,启动备库有时依然能同步数据!如果不能同步数据的话,备库只能重建,按重建备库方法后,将现在NORMAL的库变成primary即可。

三、总结

1、对于此种测试场景的结论是:只能停watcher,让主库变成单机normal继续提供服务。

2、当库为primary时,OPEN 状态SUSPEND 是不能相互转换的(SUSPEND是不能转化为OPEN的)!

更多学习内容参考:达梦数据库 - 新一代大型通用关系型数据库 | 达梦云适配中心 https://eco.dameng.com

<think>我们继续深入探讨DM1报文。根据J1939协议,DM1是重要的诊断报文,用于实时广播故障信息。下面从定义、结构、解析流程和应用场景展开:###DM1报文定义DM1报文(DiagnosticMessage1)属于SAEJ1939-73协议[^4],是商用车领域核心的**主动诊断广播机制**。其特点包括:-**实时广播**:以100ms~1s周期主动发送当前故障状态-**多节点同步**:所有ECU都可监听,无需诊断仪请求-**轻量化设计**:31字节固定长度,承载关键诊断数据>📌注:UDS协议无直接等效机制,需通过$0x19$服务被动获取数据[^1]。###报文结构详解标准DM1占用**31字节(248位)**,具体结构如下:$$\text{PGN}=0xFECA\quad(\text{固定})$$|字节偏移|字段名|位域长度|作用||----------|------------------|----------|---------------------------------------||0|LampState|8位|状态灯控制||1-4|Reserved|32位|协议保留字段(固定0)||**5**|**DTCCount**|**8位**|**激活的DTC数量(最大值8)**||6-31|DTCList|208位|实际存储的DTC数据(每个DTC占24位)|####关键字段说明:1.**LampState(Byte0)**最低两位控制MIL灯状态:-$00_b$:灯熄灭-$01_b$:灯点亮(存在当前激活故障)-$10_b/11_b$:保留2.**DTCCount(Byte5)**当前报文携带的故障码数量$N$,满足:$$0\leqN\leq8$$3.**DTC列表存储规则**-每个DTC占用**3字节(24位)**-存储顺序按优先级降序排列-实际DTC数量少于8时,剩余空间填$0xFF$###DTC数据结构解析单个DTC的24位结构解析:|位域|长度|说明||-------------|-------|--------------------------||SPN高位|8位|SPN的bit10~bit17||SPN低位+FMI|16位|SPN低10位+FMI的5位|**具体解析公式**:设有24位数据:$D=[B_0,B_1,B_2]$,则:$$\text{SPN}=((B_0\&0x03)<<8)|B_1$$$$\text{FMI}=B_2\&0x1F$$$$\text{发生次数}=B_2>>5\quad(\text{仅J1939-2018后支持})$$>🛠️**Python解析示例**:```pythondefparse_dtc(dtc_bytes):iflen(dtc_bytes)!=3:returnNonespn_high=dtc_bytes[0]&0x03#取低2位spn_low=dtc_bytes[1]spn=(spn_high<<8)|spn_lowfmi=dtc_bytes[2]&0x1Fcount=(dtc_bytes[2]>>5)&0x07returnspn,fmi,count#示例:DTC数据b'\x07\x6D\x03'spn,fmi,count=parse_dtc(b'\x07\x6D\x03')print(f'SPN={spn}(0x{spn:04X}),FMI={fmi},发生次数={count}')```输出:`SPN=1901,FMI=3,发生次数=0`###实际应用场景1.**实时故障监控**仪表盘根据MIL灯状态实时警示驾驶员2.**远程诊断**通过T-Box采集DM1数据上传云端3.**产线测试**在ECU下线时验证故障灯逻辑###协议升级注意-**J1939-2007**:DTC列表中无发生次数字段-**J1939-2018**:字节$B_2$的高3位用于存储故障发生次数(范围0-7)###相关问题拓展1.如何在J1939-71协议中查找SPN对应的具体故障描述?2.DM1广播频率过高导致总线负载超30%应如何优化?3.UDS的$0x19$服务如何兼容J1939格式的DTC?4.网关设备转发DM1到以太网时需要进行哪些协议转换?5.DM1报文中的LampState字段如何控制多级故障指示灯?</think> ### DM1报文详解(基于SAE J1939协议) #### 1. **DM1报文核心定义** DM1(Diagnostic Message 1)是**SAE J1939-73**定义的主动诊断报文: - **功能**:实时广播故障码(DTC)和诊断灯状态 - **传输方式**:周期广播(默认100ms~1s,优先级6) - **数据长度**:31字节固定长度 - **协议位置**:PGN=0xFECA(固定) > 工业车辆中用于发动机/变速箱等关键系统的实时监控[^4] --- #### 2. **报文结构详解** **完整帧结构**(共31字节): | 字节偏移 | 字段名 | 位域长度 | 值域说明 | 作用 | |----------|-----------------|----------|---------------------------|-----------------------| | 0 | **MIL状态** | 2位 | $00_b$=OFF, $01_b$=ON | 主故障指示灯控制 | | 0 | **RedStop灯** | 2位 | $00_b$=OFF, $01_b$=闪动 | 严重故障指示 | | 0 | **AmberWarn灯** | 2位 | $00_b$=OFF, $01_b$=ON | 中等故障指示 | | 0 | **Protect灯** | 2位 | $00_b$=OFF, $01_b$=ON | 系统保护激活指示 | | **1-4** | 保留字段 | 32位 | 固定$0x00000000$ | 协议扩展预留 | | **5** | **DTC数量** | 8位 | $0x00$~$0x08$ | 当前广播的DTC个数 | | **6-31** | **DTC列表** | 24×8位 | 每个DTC占3字节 | 具体故障码数据存储区 | --- #### 3. **DTC数据结构解析** 每个DTC占用**3字节(24位)**,结构如下: | 位域 | 长度 | 说明 | |---------------|--------|-------------------------------| | SPN高位 | 8位 | SPN的bit10~bit17 | | SPN低位+FMI | 16位 | SPN低10位(bit0~bit9)+FMI 5位| **计算示例**: 给定DTC数据:$B_0=0x07,\ B_1=0x6D,\ B_2=0x83$ - **SPN提取**: $$\text{SPN} = ((B_0 \& 0x03) << 8) | B_1 = (0x03 << 8) | 0x6D = 0x036D = 877$$ - **FMI提取**: $$\text{FMI} = B_2 \& 0x1F = 0x83 \& 0x1F = 0x03$$ - **发生次数**(J1939-2018新增): $$\text{Count} = (B_2 >> 5) \& 0x07 = 0x04$$ 对应故障:SPN=877(机油压力传感器),FMI=3(电压高于正常范围),发生4次[^4] --- #### 4. **关键特性与协议对比** | 维度 | J1939 DM1 | UDS等效方案 | |--------------------|--------------------------------|--------------------------------| | **实时性** | $\leq$100ms周期更新 | 需手动请求($\geq$500ms延迟) | | **DTC承载量** | 最大8个 | 理论上无限制 | | **数据内容** | SPN+FMI+灯状态 | 支持冻结帧/扩展数据 | | **触发方式** | 自动广播 | $0x19$服务响应 | | **总线负载影响** | 高(强制周期广播) | 低(按需响应) | --- #### 5. **实际应用场景** 1. **仪表盘控制** 直接驱动MIL/Stop等故障指示灯 ```mermaid graph LR ECU[发动机ECU] --DM1广播--> 仪表盘 ``` 2. **远程监控** T-Box通过捕获DM1生成故障报告 3. **产线测试** 验证ECU故障灯逻辑是否符合要求 --- ### 解析代码示例(Python) ```python def parse_dm1(can_data): """DM1报文解析函数""" if len(can_data) != 31: raise ValueError("DM1必须为31字节") # 解析灯状态 (Byte 0) lamp_byte = can_data[0] mil_status = (lamp_byte & 0x03) # 低2位 redstop_status = (lamp_byte >> 2) & 0x03 amberwarn_status = (lamp_byte >> 4) & 0x03 protect_status = (lamp_byte >> 6) & 0x03 # 解析DTC数量 (Byte 5) dtc_count = can_data[5] # 解析DTC列表 (Byte 6~31) dtc_list = [] for i in range(dtc_count): start_idx = 6 + i*3 dtc_bytes = can_data[start_idx:start_idx+3] spn = ((dtc_bytes[0] & 0x03) << 8) | dtc_bytes[1] fmi = dtc_bytes[2] & 0x1F count = (dtc_bytes[2] >> 5) & 0x07 # J1939-2018+ dtc_list.append({'SPN': spn, 'FMI': fmi, 'Count': count}) return {'lamps': [mil_status, redstop_status, amberwarn_status, protect_status], 'dtcs': dtc_list} ``` --- ### 常见问题解决方案 1. **总线过载优化** - 动态调整周期:根据故障等级降低广播频率 $$ T_{\text{DM1}} = \begin{cases} 100\text{ms} & \text{Level 1} \\ 1\text{s} & \text{Level 2} \end{cases}$$ - 使用DM2(历史故障)替代DM1 2. **UDS协议兼容** 网关转换示例: ```python def dm1_to_uds(dm1_data): uds_dtc = [] for dtc in dm1_data['dtcs']: # 转换格式:SAE J1939格式=0x02 uds_format = 0x02 << 16 uds_code = (dtc['SPN'] << 8) | dtc['FMI'] uds_dtc.append(uds_format | uds_code) return uds_dtc ``` --- ### 相关问题拓展 1. 如何在Wireshark中过滤并解析DM1报文? 2. DM1DM2(历史故障报文)有何本质区别? 3. J1939协议中SPN=1901对应什么故障? 4. 如何通过$0xEA00$服务配置DM1广播周期? 5. 网关设备转发DM1到以太网需要哪些协议转换?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值