守护进程(dmwatcher)是 DM 数据守护系统不可或缺的核心部件,是数据库实例和监视器之间信息流转的桥梁。数据库实例向本地守护进程发送信息,接收本地守护进程的消息和命令;监视器(dmmonitor)接收守护进程的消息,并向守护进程发送命令;数据库实例与监视器之间没有直接的消息交互;守护进程解析并执行监视器发起的各种命令(Switchover/Takeover/Open database 等),并在必要时通知数据库实例执行相应的操作。
3.1 主要功能
守护进程是管理数据守护系统的核心部件,监视器(dmmonitor)负责发起命令,守护进程负责解析、处理、转发命令。守护进程提供了数据库监控、故障检测、故障处理、故障恢复等各种功能。
3.1.1 监控数据库实例
守护进程负责监控数据库运行状态,必要时重启数据库服务。守护进程和实例链路建立成功后,数据库实例定时发送信息到守护进程,发送到守护进程的内容包括:实例进程 ID、实例名、数据库模式、数据库状态、FILE_SEQ、FILE_LSN、CUR_SEQ、CUR_LSN、MAL 链路状态、归档状态、公钥、MPP 控制文件等信息。
守护进程更新本地记录的实例信息后,同时记录该时间戳。当检测到实例进程 ID 已经不存在或者超过一段时间没有收到实例消息(INST_ERROR_TIME),则会认定实例故障。如果配置了自动重启,则会将实例重新拉起。
注意DMDSC集群的自动重启由dmcss检测执行,单机的自动重启由守护进程检测执行。
守护进程采用超时机制判断实例是否故障,即当前时间和上次收到消息的时间差是否超过故障认定时间(INST_ERROR_TIME),因此不建议在数据守护系统运行过程中调整操作系统时间,避免导致这个差值很大,误判实例故障。
3.1.2 发送状态信息
守护进程将监控的数据库实例信息和守护进程自身的信息(包括守护类型、守护模式、守护状态、守护日志、监视器执行序列号、执行返回码等)捆绑在一起,定时发送给其他守护进程和所有监视器。
3.1.3 监控其他守护进程
接收并解析其他守护进程发送的消息,如果超过一段时间(DW_ERROR_TIME)没有收到远程守护进程消息,会将远程守护进程状态认定为 ERROR 状态。另外还会结合本地数据库信息和守护进程自身状态,切换数据库的运行模式和系统状态。
注意守护进程采用超时机制判断远程守护进程是否故障,即当前时间和上次收到消息的时间差是否超过故障认定时间(DW_ERROR_TIME),因此不建议在数据守护系统运行过程中调整操作系统时间,避免导致这个差值很大,误判远程守护进程故障。
3.1.4 接收监视器消息
主备切换、备库接管等操作都是通过监视器命令进行,监视器将操作命令分解成多个步骤顺序执行。守护进程接收这些消息并通知实例进行相应操作,例如执行 SQL 语句修改实例模式、状态、INI 参数、设置归档状态等一系列动作,这些步骤依次执行完成后,即可完成主备库的切换或备库的接管等操作。
例如,主备切换操作,监视器首先通知待切换主备库的守护进程修改为 Switchover 状态,设置成功以后,其他监视器将不能再进行命令操作。守护进程收到监视器将实例 Mount 的命令,转发到本地实例执行,实例执行完成后返回执行结果。执行结果包含在实例向守护进程发送的消息中,守护进程根据消息中的执行码判断是否执行成功,并响应监视器。
注意监视器和守护进程之间也是采用超时机制判断对方是否故障,即当前时间和上次收到消息的时间差是否超过故障认定时间(守护进程配置的DW_ERROR_TIME),因此不建议在数据守护系统运行过程中调整操作系统时间,避免导致这个差值很大,误判监视器故障。
3.1.5 主备库启动运行
数据守护系统刚启动时,所有实例处于 Mount 状态,守护进程处于 Startup 状态,启动时需要将实例转换到 Open 状态,守护进程也切换到 Open 状态,对外提供服务。
启动条件和流程详见数据守护使用说明章节中的数据守护启动流程 6.2 数据守护的启动。
3.1.6 备库故障处理
故障自动切换模式下,备库故障后,如果主备库之间的归档状态仍然有效,主库的守护进程会先切换为 Confirm 状态,等待确认监视器的确认消息,如果确认为符合故障处理条件,主库守护进程再切换至 Failover 状态,将故障备库的归档失效。
故障手动切换模式下,备库故障后,如果主备库之间的归档状态仍然有效,会直接切换到 Failover 状态,并将故障备库的归档失效,不需要备库故障确认。
备库故障后,备库的守护进程如果还处于活动状态且监控功能没有被关闭,则会切换到 Startup 状态下。
备库故障重启后,如果存在活动主库,主库守护进程根据备库实例的模式、状态、备库守护进程状态、守护进程控制文件状态、备库已经同步到的 Open 记录以及备库的恢复间隔等信息判断是否可以进行故障恢复,在满足故障恢复条件的情况下,主库守护进程启动 Recovery 流程,重新恢复主备库到一致状态。
如果一直没有观察到主库守护进程发起 Recovery 流程,可以借助监视器的 check
recover 命令查找备库不满足条件的原因,并做对应的处理。
注意读写分离集群下,主库向即时备库发送归档失败后,会直接修改归档状态无效,并将数据库修改为Suspend状态。
如果主备库之间出现网络故障,并且在网络故障期间,主库没有修改操作触发归档日志发送,则主库会一直保持Open状态。
如果网络故障期间备库接管,网络恢复后,dmwatcher会通知主库强制关闭。
3.1.7 备库异常处理
备库异常,指备库的数据库实例正常,但响应速度出现异常,这里的响应速度可能受主备库之间的网络影响,比如网络不稳定、网速大幅下降,也可能受备库自身的软硬件影响,比如操作系统原因或磁盘读写速度异常降低等异常情况导致响应主库的速度变慢,这种情况下会极大拖慢主库性能,影响主库正常处理对外的业务请求。
守护进程提供 RLOG_SEND_THRESHOLD 参数用于监控主备之间的日志发送速度,此参数应配置为大于 0 的值,否则守护进程不会打开监控功能。
主库守护进程在 Open 状态下对日志发送速度进行检测,一旦检测到异常,主库守护进程会切换到 Standby check 状态,并通知主库将异常备库的归档失效,暂停到此备库的数据同步,避免拖慢主库性能。
完整的备库异常处理流程如下(Standby check 状态处理):
- 收集所有的异常备库。
- 将主库守护进程上记录的这些异常备库的最近一次恢复时间修改为当前时间。恢复间隔仍然为 dmwatcher.ini 中配置的 INST_RECOVER_TIME 值。这一步骤的目的是为了防止修改备库归档为 Invalid 无效状态后,主库立马启动 recovery,但是还未取到备库最新的 LSN 信息,导致 recovery 无法正确执行的情况发生。
- 通知主库修改这些异常备库的归档为 Invalid 无效状态。
- 守护进程切回 Open 状态。
注意下面情况会导致Standby check过程中断:
1. 在此状态下发现其他备库故障,且符合failover条件,则守护进程主动中断Standby check异常处理,先做failover故障处理。
2. 主库是DSC集群,在此期间启动故障处理或者故障重加入,则守护进程会主动中断Standby check异常处理。
3.1.8 主库故障处理
故障自动切换模式下,主库故障后,确认监视器会捕获到故障信息,自动选出可接管的备库,并通知备库进行接管。备库接管由确认监视器自动触发,无需用户干预。
故障手动切换模式下,主库故障后,需要人工干预,通过监视器执行接管命令,将可接管备库切换为主库。
故障自动切换模式下,可以实时处理故障,但对网络稳定性要求更高,需要确保主备库之间,主备库与守护进程、确认监视器之间的网络稳定可靠,否则可能会误判主库故障,备库自动接管后,出现多个 Open 状态的主库,引发脑裂。故障手动切换模式下,备库不会自动接管,出现节点故障或者网络故障时,由用户根据各种故障情况,进行人工干预。
主库故障重启后,守护进程根据本地和远程库的 Open 记录、LSN 信息以及模式和状态信息来判定重启后的恢复策略,可能继续作为主库加入守护系统,也可能修改为 Standby 模式,以备库身份重新加入守护系统,如果出现分裂,则需要用户干预。
3.1.9 故障恢复处理
故障恢复状态(Recovery)由守护进程自行判断是否切换,和监视器无关。如果符合以下条件,主库的守护进程可自动进入 Recovery 状态,进行数据恢复:
- 本地主库 [Primary,Open],守护进程 Open 状态;
- 远程备库[Standby,Open],归档状态 Invalid,守护进程 Open 状态;
- 远程备库[Standby,Open]的 ASEQ/ALSN 和 SSEQ/SLSN 相等,没有待重做日志;
- 根据 Open 记录等信息判断备库可加入;
- 远程备库[Standby,Open]达到了设置的启动恢复的时间间隔。
对于前 4 点,只是概括说明,详细的条件比较多,这里不再逐一列出,如果某个备库一直没有被恢复,可以借助监视器的 check recover 命令来查找备库无法进行恢复的原因。
对于第 5 点,可通过配置主库守护进程 dmwatcher.ini 的 INST_RECOVER_TIME 来控制,取值(3s~ 86400 s),该值对所有备库有效,可通过监视器的 show arch send info 命令查看当前设置的到指定备库的恢复时间间隔。
也可以使用监视器的 set recover time 命令来动态设置指定备库的恢复间隔,该命令只会修改命令中指定的备库的恢复间隔,并且只保存在主库的守护进程内存中,不会写入到 dmwatcher.ini 文件。
在主备库运行正常,不需要执行备库故障恢复的情况下,主库守护进程内存中对备库的恢复间隔值和 dmwatcher.ini 中配置的 INST_RECOVER_TIME 值是一致的,在某些场景下会被设置为不同的值,下面分别进行说明:
1. 主库守护进程主动设置恢复间隔为 3s
在以下场景中,主库的守护进程会重置内存中的 INST_RECOVER_TIME 为 3s,对满足前述前 4 个条件的备库在 3s 后会立即启动恢复流程:
- 数据守护系统启动完成之后;
- 守护系统运行过程中,主库手动重启或者守护进程自动启动 Open 之后;
- 监视器执行 Switchover 主备切换/Takeover 备库接管/强制 Open 主库的操作之后。
2.使用监视器命令动态设置恢复间隔
监视器提供有以下命令可动态修改 INST_RECOVER_TIME 值:
- set database [group_name.]db_name recover time time_value
动态修改指定备库实例的恢复间隔,只修改对应主库守护进程内存中的 INST_RECOVER_TIME 值。
- set group [group_name] recover time time_value
动态修改指定组或所有组中所有备库的恢复间隔,只修改对应主库守护进程内存中的 INST_RECOVER_TIME 值。
- set group [group_name] para_name para_value
动态修改指定组或所有组中所有守护进程的配置参数值,para_name 允许指定为 INST_RECOVER_TIME,同时修改 dmwatcher.ini 文件和主库内存中的 INST_RECOVER_TIME 值。
以上 3 个命令都可以用来修改 INST_RECOVER_TIME 值,修改完成后,一旦主库对指定备库执行过恢复操作,不管恢复执行成功或失败,通过监视器动态修改的内存值都不再有效,主库守护进程在恢复完成后,会根据恢复结果重置内存中的恢复间隔值(对 dmwatcher.ini 中的值没有影响)。
3. 主库守护进程根据恢复结果设置恢复间隔
如果备库恢复成功,会重置此备库的恢复间隔为主库 dmwatcher.ini 中配置的值。
如果备库恢复失败,会根据失败 code 区分设置为不同的值,比如 1800s,一般是在主备库日志校验不连续的情况下设置,其他还可能设置为 3s、30s、300s 或者 dmwatcher.ini 中设置的值,这里不再详细说明,具体可通过服务器和守护进程的 log 日志查看详细的设置信息,也可以通过监视器的 show arch send info 命令查看相关 code 信息。
完整的故障恢复流程如下:
- 通知备库丢弃 KEEP_RLOG_PKG;
- 通知主库发送归档日志,同步历史数据;
- 通知主库切换为 Suspend 状态;
- 再次通知主库发送归档日志;
- 通知主库设置备库归档为 Valid 状态;
- 通知主库切换为 Open 状态。
整个恢复过程中最耗时的是发送归档日志,当存在多个备库需要恢复时,为了提高恢复的效率,采用多备库并行发送归档的方式进行。守护进程每次搜集一个可恢复备库到恢复列表,按照上述故障恢复流程执行单个步骤,在等待发送归档日志的过程中,继续检测是否有备库可以恢复,如果有则加入恢复列表,也对其开始进行恢复流程处理;如果没有则检查恢复列表中是否有归档日志发送完成的备库,有则对其进行后续步骤处理,直至归档变成有效状态后从恢复列表中删除。对于恢复过程中出错的备库,也从恢复列表中删除。当恢复列表为空时,恢复流程执行结束,守护进程恢复为 OPEN 状态。
恢复过程中,守护进程会继续检测是否有恢复列表之外的备库需要恢复,如果有则可以动态加入恢复列表,实现动态并行恢复。
警告以下情况会导致Recovery过程中断:
以下情况会导致Recovery过程中断:
1. Recovery过程中收到监视器的命令。
2. 存在多个备库时,Recovery过程中发现其他正常备库故障,且符合failover条件,则守护进程主动中断Recovery,先做failover处理。
3. 存在多个备库时,Recovery过程中发现到其他正常备库归档发送异常,则守护进程主动中断Recovery,先做异常处理。
4. Recovery过程中,当前正在被恢复的备库出现异常。
5. 正在执行Recovery的主库或备库是DMDSC集群,Recovery过程中DMDSC集群启动故障处理或者故障重加入,也会中断当前的Recovery动作。
注意在守护进程打开备库异常监控的情况下,对于异常备库的恢复处理需要注意下面两点:
1. 如果主备库的LSN已经相等,但是根据统计出来的时间信息判断主库的归档发送时间或备库的日志重演时间仍然大于设置的阈值,则不会再进入Recovery状态,直到主库上有新的日志产生需要同步到备库,可以对统计的历史时间信息进行更新的情况下才会再进入Recovery状态尝试恢复。
2. 在进入Recovery状态后,通知主库Suspend之前(主备库数据已经同步一致),会对主库的归档发送时间和备库的日志重演时间进行检查,在两者都小于或等于设置的阈值的情况下,才允许继续执行Suspend,并恢复备库归档为有效状态,否则不允许再往下执行,本次Recovery执行失败。
3.2 守护类型
守护进程支持两种守护类型:
- 本地守护
提供最基本的守护进程功能,监控本地数据库服务。如果实例使用 Mount 方式启动,守护进程会通知实例自动 Open,如果连续一段时间没有收到来自其监控数据库的消息,即认定数据库出现故障,根据配置(INST_AUTO_RESTART)确定是否使用配置的启动命令重启数据库服务。异步备库也是采用这种方式配置。
- 全局守护
实时主备、MPP 主备和读写分离集群系统中,需要将守护进程配置为全局守护类型;DMDSC 数据守护除了仅配置异步备库,也需要将守护进程配置为全局守护类型。守护进程根据数据库服务器配置的归档类型以及 MPP_INI 参数情况,自动识别具体的集群类型(实时主备、MPP 主备、读写分离集群或 DMDSC 数据守护),全局守护类型在本地守护类型的基础上,通过和远程守护进程的交互,增加了主备库切换、主备库故障检测、备库接管、数据库故障重加入等功能。
注意配置全局守护类型后,守护进程守护的数据库实例,必须配置实时或即时归档,否则dmwatcher会启动失败。
3.3 守护模式
守护进程支持两种故障切换模式:
- 故障自动切换
主库发生故障时,确认监视器自动选择一个备库,切换为主库对外提供服务。故障自动切换模式,要求必须且只能配置一个确认监视器。具体的实现机制和使用注意事项可参考 4.4 自动接管小节。
- 故障手动切换
主库发生故障时,由用户根据实际情况,通过监视器命令将备库切换为主库。在用户干预之前,备库可以继续提供只读服务和临时表的操作。
实时主备/MPP 主备/读写分离集群都可以配置为故障自动切换或故障手动切换模式,这两种模式下守护系统的启动流程、数据同步和故障处理机制存在一定的差异,主要差异参考表 3.1。、
比较内容 | 故障自动切换 | 故障手动切换 |
---|---|---|
硬件要求 | >=3 台机器 | >=2 台机器 |
主库故障需要人工干预 | 否 | 是 |
备库 KEEP_RLOG_PKG | 有(实时主备和 MPP 主备专用) | 有(实时主备和 MPP 主备专用) |
需要确认监视器 | 是 | 否 |
支持实时主备 | 是 | 是 |
支持 MPP 主备 | 是 | 是 |
支持读写分离集群 | 是 | 是 |
主库故障处理 | 备库自动接管 | 备库手动接管 |
备库故障处理 | 主库可能先进入 Confirm 状态,向确认监视器求证备库故障后, 再进行 Failover 处理。也可能直接 Failover 处理,具体参考[6.9 备库故障处理](#6.9 备库故障处理) |
主库直接 Failover 处理 |
主备库切换 | 支持 | 支持 |
注意一个数据守护集群,只能配置一个确认监视器。如果同时启动多个确认监视器,后启动的确认监视器将报错并自动退出。
3.4 守护状态
守护进程包括以下一些状态:
- Startup 守护进程启动状态,需要根据远程守护进程发送的状态信息,结合本地数据库的初始模式、状态和数据同步情况,确定本地数据库的启动模式和状态后,进入 Open 状态。
- Open 守护进程正常工作,监控数据库,并定时发送数据库的状态信息,接收其他守护进程发送的信息,接收监视器发送的用户请求。
- Shutdown 守护进程停止监控数据库状态,不再提供主备库切换、主备库故障处理和备库故障恢复等功能。
- Switchover 主备库正常情况下,手动主备切换过程中设置为 Switchover 状态。
- Failover 远程备库故障后,本地主库执行故障处理时,守护进程设置为 Failover 状态。
- Recovery 故障恢复同步历史数据过程中设置为 Recovery 状态。
- Confirm 通过监视器确认远程主(备)库是否活动的过程中,守护进程设置为 Confirm 状态。
- Takeover 主库确认故障后,备库手工接管或监视器通知自动接管过程中,守护进程设置为 Takeover 状态。
- Open force 借助监视器命令强制 Open 主库或备库实例时,守护进程设置为 Open force 状态。
- Error 超过一段时间(DW_ERROR_TIME)没有接收到远程守护进程消息,本地守护进程或监视器认定远程守护进程故障,修改远程守护进程为 Error 状态。
- Login check 监视器执行登录命令时,守护进程所处的状态。
- Mppctl update 修改主库 MPP 控制文件(dmmpp.ctl)时,守护进程所处的状态,只在 MPP 主备系统出现。
- Change arch 监视器执行 set arch invalid 命令时守护进程所处的状态。
- Standby check 主库守护进程监控到备库异常后,切换到此状态下通知主库修改此备库归档无效。
- Clear send info 清理主库上的归档发送信息时,守护进程所处的状态。
- Clear rapply stat 清理备库上的重演信息时,守护进程所处的状态。
- Unify ep 统一 DMDSC 集群各节点实例状态,或者各实例状态已经一致时,守护进程在 Startup 或 Open 状态下通知实例执行相关操作,都进入 Unify_ep 状态执行。
- Css process 监视器发起的对 DMDSC 集群的部分命令,比如启动、关闭、强杀 DMDSC 库,或者打开、关闭节点实例的自动拉起功能等命令,需要借助 dmcss 执行时,守护进程会切换到此状态下。
守护进程所有状态变换和它监控的数据库的状态变换都会生成相应的 LOG 信息,写入到../log 目录中以’dm_dmwatcher_实例名_当前年月.log’方式命名的日志文件中。用户可以通过查看日志文件,分析数据库和守护进程的运行状态、监控故障处理过程。
守护进程的状态转换如下图所示:
从图中可以看出,守护进程主要工作在 Startup 和 Open 状态,几乎任何状态都可以转到这两种状态,并且这两种状态之间也可以相互转换。
另外,当远程守护故障,任何状态都可转到 Error 状态。
3.5 控制文件
数据守护 V4.0 对守护进程控制文件(dmwatcher.ctl)进行了简化,仅用于记录本地数据库的分裂状态和分裂描述信息。守护进程在检测到本地库分裂时,自动创建 dmwatcher.ctl 文件,保存在本地库的 SYSTEM_PATH 路径下,并且文件中记录的状态一定是 Split 分裂状态。如果 dmwatcher 加载到 dmwatcher.ctl 文件,则认为对应的库一定是分裂状态。如果需要对分裂库进行重建,则需要手动将 dmwatcher.ctl 文件删除,否则守护进程仍然会认定本地库为分裂库。
守护进程控制文件仅包含版本号、状态及分裂描述信息这三项内容。
状态字段包含以下两种:
- 有效(VALID) 正常运行时状态。
- 分裂(SPLIT) 数据和有效主库的数据不一致时设置。
3.6 可加入(分裂)判断规则
守护进程首先对本地和远程库的 Open 记录(SYSOPENHISTORY)进行比较,再结合数据库的模式、状态以及守护进程认定的 OK/ERROR 状态判断可加入或者分裂,这里仅对守护进程的判断规则进行大概说明,如果发现守护系统中有分裂库,可以从服务器和守护进程的 log 日志中找到具体的分裂原因。
Open 记录的比较结果分为四种:
- 本地库和远程库相等
如果其中一个库是 Primary&Open 或者 Primary&Suspend 状态,则直接将其认定为主库,另一个库认定为备库。
否则需要进一步比较两个库的 APPLY 信息,比较结果可能会选出有效的主库和备库,也可能出现分裂,需要用户干预。
- 远程库包含在本地库中
使用本地库包含关系之后的第一条 Open 记录项中的 APPLY 信息和远程库的 APPLY 信息比较大小,远程库小于或等于的情况下,远程库的守护进程再继续根据模式、状态信息确定下一步动作,最终可以将其作为备库重加入守护系统。
- 本地库包含在远程库中
使用远程库包含关系之后的第一条 Open 记录项中的 APPLY 信息和本地库的 APPLY 信息比较大小,本地库小于或等于的情况下,本地库的守护进程再继续根据模式、状态信息确定下一步动作,最终可以将其作为备库重加入守护系统。
- 本地库和远程库不相等,也没有包含关系
如果其中一个库处于 Primary&Open 状态,另一个库是备库,或者是 Mount 状态的主库,则另一个库的守护进程会将自己设置为 Split 分裂状态,创建 dmwatcher.ctl 文件,并通知本地库强制关闭。如果守护进程无法选出有效主库,则切换为 Startup 状态,并等待用户干预。
需要注意的是,SYSOPENHISTORY 表最多只维护 128 条 Open 记录,达到 128 条以后会从第一条记录开始自动覆盖,并依次往后循环使用。在主备库的数据差异很大的情况下,备库的最后一条 Open 记录有可能在主库上已经被覆盖掉,备库无法根据 Open 记录确定自己的包含关系,也无法重加入数据守护系统。这种情况下只能通过人工干预,使用备份还原的方式将备库重新恢复到和主库数据一致的状态并重新加入数据守护系统。
3.7 守护进程命令
守护进程(dmwatcher)既能以控制台方式启动,也可以配置为服务方式启动。可以在守护进程的控制台上输入命令,关闭守护进程,显示守护进程组的状态信息等,具体命令参考下表:
命令 | 含义 |
---|---|
help | 显示帮助信息 |
exit | 退出守护进程 |
status | 显示守护进程运行状态信息 |
show | 显示所有守护进程组中的本地库信息 |
show group group_name | 显示指定守护进程组中的本地库信息 |
show version | 显示守护进程自身版本信息 |
show monitor config | 帮助监视器配置 ini 文件的信息 |
show link | 显示守护进程上的 tcp 连接信息 |
下面对守护进程各命令含义进行详细介绍:
- help
打印守护进程使用帮助信息。
2. exit
退出守护进程。
3. status
打印守护进程状态信息,各字段含义说明如下:
GROUP_NAME:守护进程组名。
DW_STATUS:守护进程状态。
DW_SUB_STATUS:守护进程子状态。
4. show
显示所有守护进程组中的本地库信息,不显示远程库信息。
各字段含义说明如下:
1) 组全局字段信息
GROUP_NAME:守护进程组名。
TYPE:配置的守护类型。
MODE:配置的切换模式,AUTO 表示故障自动切换模式,MANUAL 表示故障手动切换模式。
OGUID:守护进程组配置的唯一 OGUID 值。
MPP_FLAG:当前是否为 MPP 主备环境,值为 TRUE 或 FALSE。
AUTO_RESTART:守护进程是否配置有自动拉起,值为 TRUE 或 FALSE。
DW_STATUS:守护进程状态。
DW_SUB_STATUS:守护进程子状态。
DW_CTL_STATUS:守护进程控制文件状态。
2) 各节点实例字段信息
INST_OK:守护进程认定的节点实例状态,Ok 或 Error。
NAME:节点实例名称。
SVR_MODE:节点实例模式,包括 Normal/Primary/Standby 这三种模式。
SYS_STATUS:节点实例状态,包括 Startup/After Redo/Mount/Open/Suspend/
Shutdown 这几种状态。
RTYPE:节点实例配置的归档类型,只统计 REALTIME/TIMELY/SYNC 这三种归档类型,如果这三种归档都没有配置,则显示为 NONE。
FSEQ:节点实例已经写入联机日志的 RLOG_PKG 包序号。
FLSN:节点实例的文件 LSN,指已经写入联机日志文件的最大 LSN 值。
CSEQ:节点实例的系统当前 PKG_SEQNO,指当前数据库最新产生的 RLOG_PKG 包的序号。
CLSN:节点实例的系统当前 LSN,指当前数据库最新产生的 LSN 值。
DW_STAT_FLAG:节点当前的执行标记。
如果是备库模式,show 命令还会显示备库控制节点当前的重演信息,重演信息的行数和产生日志的主库节点个数一致,可以查看备库对主库不同节点日志的重演情况。
REDOS_PARALLEL_NUM:备库并行重演线程数。
DSC_SEQNO:主库节点序号,如果主库是单节点,则序号为 0。
SSEQ:备库可重演到的最大日志包序号。
SLSN:备库可重演到的最大 LSN,对应日志包序号为 STDBY_PKG_SEQNO。
KSEQ:非自动切换模式下,备库保持不重演的日志包序号。
KLSN:非自动切换模式下,备库保持不重演最大 LSN,对应的日志包序号为 KSEQ。
RSEQ:备库针对主库此节点已经重演到的日志包序号。
RLSN:备库针对主库此节点已经重演到的 LSN 值,对应的日志包序号为 RSEQ。
N_TSK:备库针对主库此节点的待重演任务个数。
TSK_MEM_USE:备库当前针对主库此节点的日志重演已经占用的内存大小(单位:字节)。
REDO_LSN_ARR: 备库各路并行重演线程已重演到的 LSN 值,数组中每个元素对应一路重演 LSN。
5. show group group_name
显示所有守护进程组中的本地库信息,不显示远程库信息。各字段含义同 show 命令。
6. show version
显示守护进程自身版本号。
守护进程版本信息格式为“DMWATCHER[数据守护版本号] 全局版本号”,例如:“DMWATCHER[4.0] V8”。
同一套数据守护系统中,服务器、守护进程和监视器要求中括号内的数据守护版本号必须一致,否则不允许建立 TCP 连接,各自的控制台工具上和 log 日志中都会记录版本不匹配报错信息。
7. show monitor config
此命令为辅助用户配置 dmmonitor.ini 使用。
守护进程根据自己的组名、oguid、ip/port 等配置信息,生成一份 dmmonitor.ini 配置文件供用户参考使用。
此命令只会显示包含在守护进程守护的本地实例归档配置文件中的实例对应的守护进程信息,比如本地实例配置的实时归档、即时归档、异步归档的目标实例所在守护进程信息,对于未配置的目标实例守护进程信息则不会显示,比如其他实例上配置的异步备库守护进程信息不能显示。因此对监视器来说,单个守护进程上的显示结果配置信息可能是不完整的。只做配置参考使用,可以借助多个守护进程的显示结果,综合起来进行配置。
8. show link
此命令为辅助用户查看本地守护进程和本地各节点实例、远程守护进程、dmcss、监视器的 TCP 连接状态使用。
此命令只显示当前连接正常的链路信息,如果连接已经断开,则不会被显示出来。
各字段含义说明如下:
FROM_FLAG:和本地守护进程建立 tcp 连接的对方程序名称,dmserver、dmcss、dmwatcher 或者 dmmonitor。
FROM_INAME:和本地守护进程建立 TCP 连接的对方实例名或者 css 名称。
HANDLE:TCP 连接句柄。
MID:只对监视器有效,监视器唯一标识 ID。
N_FIX:TCP 连接句柄当前被使用个数。
MON_ADDR:连接对方 IP 地址。
MON_CONFIRM:只对监视器有效,标识是否为确认监视器。
CONN_TIME:TCP 连接建立时间。