热门搜索
分布式
数据库一体机
云数据库
建设银行
保险核心
密集交易
注册
达梦数据库数据守护集群故障处理
培训园地/ 文章详情 /

达梦数据库数据守护集群故障处理

菠粒橙丷 2025/06/26 319 1 0

目录

1、数据守护集群原理

  • DM 数据守护（DM Data Watch）的实现原理：将主库（生产库）产生的 Redo 日志传输到备库，备库接收并重新应用 Redo 日志，从而实现备库与主库的数据同步。
  • DM 数据守护的核心思想是监控数据库状态，获取主、备库数据同步情况，为 Redo 日志传输与重演过程中出现的各种异常情况提供一系列的解决方案。主要由主库、备库、Redo 日志、Redo 日志传输、Redo 日志重演、守护进程（dmwatcher）、监视器（dmmonitor）组成。

1.1、集群架构图

image.png

  • 数据库与数据库实例：
    数据库（Database）是一个文件集合（包括数据文件、临时文件、重做日志文件和控制文件），保存在物理磁盘或文件系统中。
    数据库实例（Instance）就是一组操作系统进程（或者是一个多线程的进程）以及一些内存。通过数据库实例，可以操作数据库，一般情况下，我们访问、修改数据库都是通过数据库实例来完成的。
  • 主库：
    Primary 模式，提供完整数据库服务的实例，一般来说主库是用来直接支撑应用系统的生产库。
  • 备库：
    Standby 模式，提供只读数据库服务的实例。备库除了用于容灾，还可以提供备份、查询等只读功能，并且备库还支持临时表的 Insert/Delete/Update 操作。
    根据数据同步情况，备库又可以分为可切换备库和不可切换备库。可切换备库是指，主备库之间数据完全同步，主库发生故障、备库切换为主库后，不会造成任何数据丢失的备库。
  • Redo 日志：
    Redo 日志记录物理数据页内容变动情况，是数据库十分重要的一个功能，在数据库系统故障（比如服务器掉电）重启时，利用 Redo 日志可以把数据恢复到故障前的状态。
    Redo 日志也是数据守护的实现基础，数据库中 Insert、Delete、Update 等 DML 操作以及 Create TABLE 等 DDL 操作最终都会体现为对某一个或者多个物理数据页的修改，因此备库通过重做 Redo 日志可以与主库数据保持一致。
  • Redo 日志传输：
    主备库之间的 Redo 日志传输，以日志包 RLOG_PKG 为单位，主库通过 MAL 系统发送 Redo 日志到备库。各种不同数据守护类型的区别，就在于主库日志包 RLOG_PKG 的发送时机，以及备库收到 Redo 日志后的处理策略。
  • Redo 日志重演：
    Redo 日志重演的过程，就是备库收到主库发送的 Redo 日志后，在物理数据页上，重新修改数据的过程。Redo 日志重演由专门的 Redo 日志重演服务完成，重演服务严格按照 Redo 日志产生的先后顺序，解析 Redo 日志、修改相应的物理数据页，并且重演过程中备库会生成自身的 Redo 日志写入联机日志文件。
  • 守护进程：
    守护进程（dmwatcher）是数据守护系统的核心工具，监控数据库实例的运行状态和主备库数据同步情况，在出现故障时启动各种处理预案。守护进程是各种消息的中转站，接收数据库实例、其他守护进程、以及监视器发送的各种消息；同时，守护进程也会将收到的数据库实例消息转发给其他守护进程和监视器。守护进程必须和被守护的数据库实例部署在同一台机器上。
  • 监视器：
    监视器（dmmonitor）用来监控守护系统内守护进程、数据库实例信息，执行用户输入命令、监控实例故障、实现自动切换等。监视器一般配置在数据库实例和守护进程以外的机器上。

1.2、数据守护集群关键参数

参数名称 配置值 参数解析
ARCH_WAIT_APPLY 1 库收到 Redo 日志后，是否需要重演完成后再响应主库。0 表示收到马上响应（高性能模式），1 表示重演完成后响应（事务一致模式）。配置为即时归档时，缺省值为 1；配置为实时归档时，缺省值为 0。
MAL_CHECK_INTERVAL 5 MAL 链路检测时间间隔，单位秒（s），取值范围 0~1800，缺省为 30s，配置为 0 表示不进行 MAL 链路检测，数据守护环境不建议配置为 0，防止网络故障导致服务长时间阻塞。
MAL_CONN_FAIL_INTERVAL 15 判定实例之间 MAL 链路断开的时间，取值范围 2~1800，单位秒（s），缺省为 10s。
仅当 MAL_CHECK_INTERVAL 不为 0 时有效 DW_MODE MANUAL 切换模式，缺省为 MANUAL；MANUAL：故障手动切换模式；AUTO：故障自动切换模式。
DW_ERROR_TIME 30 守护进程故障认定时间，单位秒，取值范围为 3~32767，缺省 15 秒没有收到远程守护进程消息，即认定远程守护进程故障，对本地守护无效。另外此参数也是监视器认定守护进程的故障时间，超过设置的时间间隔仍没有收到守护进程消息，监视器认为守护进程出现故障。
INST_RECOVER_TIME 60 备库故障恢复检测时间间隔，单位秒，取值范围 3~86400，缺省每 60 秒检查一下备库状态，满足故障恢复条件时，启动历史数据同步流程。数据守护系统启动完成后Switchover 主备切换后、Takeover 备库接管后以及强制 Open 主库后，主库守护进程 INST_RECOVER_TIME 内存值会强制设置成 3，确保尽快启动数据同步。另外，还可以通过监视器命令set recover time 修改 INST_RECOVER_TIME 内存值。
INST_ERROR_TIME 20 数据库故障认定时间，单位秒，取值范围为 3~32767，缺省 15 秒没有收到数据库发送的状态信息，即认定其监控的数据库出现故障。
  • 事务一致模式:
    主库事务提交触发 Redo 日志刷盘和即时归档，备库收到主库发送的 Redo 日志，并重演完成后再响应主库。主库收到备库响应消息后，再响应用户的提交请求。事务一致模式下，同一个事务的 SELECT 语句无论是在主库执行，还是在备库执行，查询结果都满足 READCOMMIT 隔离级要求。

2、集群切换场景

2.1、主备切换

  • 主库维护，滚动升级等场景，可以执行 switchover 命令，实现主备库切换。如果存在多个备库，需要先执行 choose switchover 命令，选出守护进程组中可以切换的备库。choose switchover 命令选择可切换备库的条件如下：
    （1）主库守护进程是 Open 状态
    （2）备库守护进程是 Open 状态
    （3）主、备库的 OPEN 记录项内容相同，并且守护进程控制文件是 Valid 有效状态（内存值）
    （4）主库正常运行
    （5）备库正常运行
    （6）主库处于 Open 状态
    （7）备库处于 Open 状态
    （8）主库到备库的归档是 Valid 状态
    示意图：
    image.png
    image.png

2.2、主库故障、备库接管

  • 当出现硬件故障（掉电、存储损坏等）原因导致主库无法启动，或者是主库内部网卡故障导致主库短期不能恢复正常的情况下，可使用备库接管功能，将备库切换为主库继续对外服务。故障手动切换模式下，可以先在监视器上执行 Choose Takeover 命令，选出守护进程组中可以接管的备库。为了避免备库接管后，造成守护进程组分裂，手动执行 Takeover 必须满足下列条件：
    （1）主库是 Primary 模式、Open 状态时，发生故障
    （2）手动 Takeover 允许主库守护进程故障，但是要求故障前是 Open/Recovery 状态；或者主库守护进程没有故障（非 ERROR 状态）
    （3）主库故障前到接管备库的归档状态为 Valid
    （4）接管备库是 Standby 模式、Open 状态
    （5）接管备库的守护进程控制文件状态为 Valid（内存值）
    （6）故障主库和接管备库的 Open 记录项内容相同
    示意图：
    image.png
    image.png

2.3、备库强制接管

  • 在备库接管失败后，主库仍然不能启动或者及时恢复对外服务的情况下，用户可以使用 Takeover Force 命令，进行备库强制接管。强制接管，先通过 Choose Takeover Force 选出符合强制接管条件的备库，再执行 Takeover Force 命令。备库强制接管时，如果接管备库是处于 Mount 状态/Standby 模式的库，则会自动 Open 备库，其他执行流程与备库接管一致。强制接管的条件包括：
    （1）不存在活动主库
    （2）备库守护进程处于 Open 或 Startup 状态
    （3）备库实例运行正常
    （4）备库是 Standby 模式
    （5）备库处于 Open 或 Mount 状态
    （6）备库的 KLSN 必须是所有备库中最大的
    （7）备库守护进程控制文件必须有效
    示意图：
    image.png
    image.png

2.4、备库故障处理

  • 对于手动切换模式，检测到备库故障，满足 Failover 条件时，主库的守护进程立即切换到 Failover 状态，执行对应的故障处理，如果不满足切换 Failover 条件，则保持当前状态不变。手动切换模式下，主库守护进程切换 Failover 条件：
    （1）备库实例故障，或者主备库之间出现网络故障，或者备库重演时校验 LSN 不匹配，这三种场景下引发主库同步日志到备库失败挂起，主库实例处于 Suspend 状态
    （2）主库到此备库的归档状态是 Valid（读写分离集群没有此限制）
    （3）主库的守护进程处于 Startup、Open 或 Recovery 状态
    （4）当前没有监视器命令正在执行
    示意图：
    image.png

3、集群故障场景处理

3.1、故障场景状态

3.1.1、网络故障

  • 公共网络故障：
    主库公共网络故障，主备库正常、内部网络正常情况下，用户无法连接主库执行正常的数据库操作。这种情况下，用户可以通过 Switchover 命令，将备库切换为主库，确保数据库服务不受影响。
  • 内部网络故障：
故障类型 故障集群状态
主库内部网卡故障 主库 Failover，备库归档设置无效，主库异步工作。
备库内部网卡故障 主库 Failover，备库归档设置无效，主库异步工作。
主备库交换机故障 主库 Failover，备库归档设置无效，主库异步工作。
主备网卡同时故障 主库 Failover，备库归档设置无效，主库异步工作。

3.1.2、服务故障

故障类型 故障集群状态
主库守护服务故障 主备库集群正常，对外提供服务正常
备库守护服务故障 主备库集群正常，对外提供服务正常
主备库守护服务故 主备库集群正常，对外提供服务正常
主库实例服务故障 主库无法提供正常服务，需要人工介入进行主备状态切换。切换后由备库作为新主库对外提供业务，因主备为事务一致性模式切换后不存在数据丢失。
备库实例服务故障 主库 Failover，备库归档设置无效，主库异步工作。
主备库实例服务故障 主备库均无法正常提供服务，需人工介入处理

3.1.3、硬件故障

故障类型 故障集群状态
主库服务器故障 需人工介入并强制接管备库。
备库服务器故障 主库 Failover，备库归档设置无效，主库异步工作。
主备服务器故障 主备库均无法正常提供服务，需人工介入处理
主库磁盘故障 参照主库实例服务故障情况
备库磁盘故障 参照备库实例服务故障情况
主备库磁盘故障 参照主、备库实例服务故障情况

3.2、网络故障处理

3.2.1、公共网络故障

3.2.1.1、主库公共网络故障，备库公共网络正常

  • 主库公共网络故障，主备库正常、内部网络正常情况下，用户无法连接主库执行正常的数据库操作。这种情况下，用户可以通过 switchover 命令，将备库切换为主库，确保数据库服务不受影响。同时应用链接会自动漂移到新主库集群上（前提应用连接池配置了自动重连机制）。主库网络恢复后，可将主角色重新切回，同时应用链接也会自动漂移到新主库集群上。
  • 具体操作流程如下：
##登录监视器
dmmonitor dmmonitor.ini
##登录监视器
login 
##选择可切换为Primary库的备库列表
choose switchover [group_name]
##切换指定组的指定库为PRIMARY库
switchover [group_name[.]] [db_name]

3.2.1.2、主备库公共网络均故障

  • 主备库公共网络均故障、内部网络正常情况下。此时数据库集群状态正常，但应用用户无法连接到整个数据库集群。此时需要排查公共网络故障，如果主库公共网络先恢复正常，则运维人员无需干预，主库应用链接会自动恢复。
  • 如果备库公共网络先恢复正常，则参考上一小节[主库公共网络故障，备库公共网络正常]情况处理，尽可能减少业务影响时间。

3.2.2、内部网络故障

  • DM 数据守护对内部网络的可靠性提出了很高的要求，但是在实际应用中（比如异地容灾），存在很多不可控因素，内部网络无法保证绝对可靠。守护进程和守护进程之间、守护进程和监视器之间通过超时机制来检测是否出现故障，当内部网络出现故障时，超过设置时间未收到远程消息，会认定远程故障。
  • 根据目前集群模式配置，阐述不同内部网络故障场景下集群不同表现和故障处理方式。

3.2.2.1、主库内部网络故障，备库内部网络正常

（1）故障现象

人为使用ip link set ens33 down 关闭主库内部通信网络
##关闭主库网卡
ip link set ens33 down

监视器反馈接收守护进程(RW1)消息超时
image.png
show命令查看集群状态：
image.png
发现无法获取到主库实例状态，此时主库WSTATUS为ERROR。
模拟外部应用测试连接访问主库，可以正常连接
image.png
模拟外部应用测试往主库写入数据(人工插入1条和jmter模拟应用写入50条)，结果能够正常写入数据。
image.png
image.png
在主库查询数据结果，发现能查到写入数据，共51条
image.png
在备库查询数据结果，发现不能查到写入数据
image.png
（2）故障处理

  • 情况1：
    如果能够在短时间正常恢复主库网络（归档不覆盖），在主库网络恢复后，备库会自动发起故障处理流程从主库重新同步数据。期间如果应用有DML操作也会在主库正常入库。不会丢失数据。
  • 情况2：
    如果不能够在短时间正常恢复主库网络（归档覆盖），在主库网络恢复后，备库需要先踢出集群，随后进行备库重做。重做完后即重新加入集群恢复正常。
  • 情况3：
    如果在主库内部网卡故障一段时间后，且故障时间段写入进行了数据变更，此时如果主库实例发生宕机，就应该对主备集群进行分离，然后将主库最新的全备和最全的归档拷贝到备库进行全量恢复。
  • 情况4：
    如果在主库内部网卡故障一段时间后，且故障时间段写入进行了数据变更，此时如果主库实例所在服务器整个宕机，如果能够及时恢复服务器，则按照情况3进行备机（单机）恢复。
  • 如果不能即时恢复服务器，但又想让业务正常恢复，可以将主备集群进行分离，将备库拆成单机，同时应用调整jdbc连接串，让应用连备库继续进行业务访问。但此时故障时间段写入进行的数据变更内容在主库服务器恢复正常前无法找回。

3.2.2.2、主库内部网络正常，备库内部网络故障

（1）故障现象

人为使用ip link set ens33 down 关闭备库内部通信网络
##关闭备库网卡
ip link set ens33 down

监视器反馈接受备库RW2超时，随后主库RW1守护进入FAILOVER故障处理流程，此时RW1实例状态由OPEN->SUSPEND，等待备库归档置为失效后主库RW1守护退出FAILOVER状态，此时RW1实例状态由SUSPEND->OPEN重新正常对外提供服务，整个故障处理时间在5s左右完成。
image.png
show命令可以看到此时RW2守护服务WSTATUS为ERROR状态，归档状态被置为失效。
image.png
模拟外部应用测试连接访问主库，可以正常连接
image.png
模拟外部应用测试往主库写入数据(人工插入1条和jmter模拟应用写入50条)，结果能够正常写入数据。
image.png
image.png
在主库查询数据结果，发现能查到写入数据，共51条
image.png
在备库查询数据结果，发现不能查到写入数据
image.png
（2）故障处理

  • 情况1：
    如果能够在短时间正常恢复备库网络（归档不覆盖），在备库网络恢复后，备库会自动发起故障处理流程从主库重新同步数据。期间如果应用有DML操作也会在主库正常入库。不会丢失数据。
  • 情况2：
    如果不能够在短时间正常恢复主库网络（归档覆盖），在主库网络恢复后，备库需要先踢出集群，随后进行备库重做，重做完后即重新加入集群恢复正常。
  • 情况3：
    如果在备库内部网卡故障一段时间后，且故障时间段写入进行了数据变更，此时如果主库实例发生宕机，为了保证数据不丢失，应该将主库最新的全备和最全的归档拷贝到正常机器环境重新初始化实例后，进行全量恢复。
  • 情况4：
    如果在备库内部网卡故障一段时间后，且故障时间段写入进行了数据变更，此时如果主库实例所在服务器整个宕机，如果能够及时恢复服务器，则按照情况3进行备库（单机）恢复。
  • 如果不能即时恢复服务器，但又想让业务正常恢复，可以将主备集群进行分离，将备库拆成单机，同时应用调整jdbc连接串，让应用连备库继续进行业务访问。但此时故障时间段写入进行的数据变更内容在主库服务器恢复正常前无法找回。

3.2.2.3、主库内部网络故障，备库内部网络故障

（1）故障现象

人为使用ip link set ens33 down 关闭主、备库内部通信网络
##关闭主、备库网卡
ip link set ens33 down

show命令无法获取到任何守护信息
image.png
模拟外部应用测试连接访问主库，可以正常连接
image.png
模拟外部应用测试往主库写入数据(人工插入1条和jmter模拟应用写入50条)，结果能够正常写入数据。
image.png
image.png
在主库查询数据结果，发现能查到写入数据，共51条
image.png
在备库查询数据结果，发现不能查到写入数据
image.png
（2）故障处理

  • 情况1：
    如果能够在短时间正常恢复主、备库网络（归档不覆盖），在备库网络恢复后，备库会自动发起故障处理流程从主库重新同步数据。期间如果应用有DML操作也会在主库正常入库。不会丢失数据。
  • 情况2：
    如果不能够在短时间正常恢复主、备库网络（归档覆盖），在主库网络恢复后，备库需要先踢出集群，随后进行备库重做，重做完后即重新加入集群恢复正常。
  • 情况3：
    如果在主库内部网卡故障一段时间后，且故障时间段写入进行了数据变更，此时如果主库实例发生宕机，就应该对主备集群进行分离，然后将主库最新的全备和最全的归档拷贝到备库进行全量恢复。
  • 情况4：
    如果在备库内部网卡故障一段时间后，且故障时间段写入进行了数据变更，此时如果主库实例所在服务器整个宕机，如果能够及时恢复服务器，则按照情况3进行备库（单机）恢复。
  • 如果不能即时恢复服务器，但又想让业务正常恢复，可以将主备集群进行分离，将备库拆成单机，同时应用调整jdbc连接串，让应用连备库继续进行业务访问。但此时故障时间段写入进行的数据变更内容在主库服务器恢复正常前无法找回。

3.3、服务故障处理

3.3.1、守护服务故障

3.3.1.1、主库守护服务故障，备库守护服务正常

（1）故障现象

人为使kill -9 pid 关闭主库守护服务
##关闭主库守护
kill -9 pid

监视器反馈，接收守护进程(RW1)消息超时
image.png
模拟外部应用测试连接访问主库，可以正常连接
image.png
模拟外部应用测试往主库写入数据(人工插入1条和jmter模拟应用写入50条)，结果能够正常写入数据。
image.png
image.png
在主库查询数据结果，发现能查到写入数据，共51条
image.png
在备库查询数据结果，也能查询到数据，说明此时集群具备对外访问的功能
image.png
（2）故障处理

  • 此时主库能正常读写数据，应用业务不受影响，且备库能正常同步主库数据，只需要将主库守护重新拉起即可。

3.3.1.2、主库守护服务正常，备库守护服务故障

（1）故障现象

人为使kill -9 pid 关闭备库守护服务
##关闭备库守护
kill -9 pid

监视器反馈，接收守护进程(RW2)消息超时
image.png
模拟外部应用测试连接访问主库，可以正常连接
image.png
模拟外部应用测试往主库写入数据(人工插入1条和jmter模拟应用写入50条)，结果能够正常写入数据。
image.png
image.png
在主库查询数据结果，发现能查到写入数据，共51条
image.png
在备库查询数据结果，也能查询到数据，说明此时集群具备对外访问的功能
image.png
（2）故障处理

  • 此时主库能正常读写数据，应用业务不受影响，且备库能正常同步主库数据，只需要将备库守护重新拉起即可。

3.3.1.3、主库、备库守护服务均故障

（1）故障现象

人为使kill -9 pid 关闭主、备库守护服务
##关闭主库备库守护
kill -9 pid

监视器反馈，接受到接收守护进程(RW1)消息超时和接收守护进程(RW2)消息超时
image.png
模拟外部应用测试连接访问主库，可以正常连接
image.png
模拟外部应用测试往主库写入数据(人工插入1条和jmter模拟应用写入50条)，结果能够正常写入数据。
image.png
image.png
在主库查询数据结果，发现能查到写入数据，共51条
image.png
在备库查询数据结果，也能查询到数据，说明此时集群具备对外访问的功能
image.png
（2）故障处理

  • 此时主库能正常读写数据，应用业务不受影响，且备库能正常同步主库数据，只需要将主、备库守护重新拉起即可。

3.3.2、实例服务故障

3.3.2.1、主库实例服务故障，备库实例服务正常

（1）故障现象

人为使kill -9 pid 关闭主库实例服务
##关闭主库实例
kill -9 pid

（2）故障处理

  • 此时，如果主库RW1守护正常，主库实例正常，则RW1守护检测到RW1实例故障后会自动拉起，正常拉起后集群可正常对外提供服务，拉起期间应用业务不可用。
    如果主库RW1守护正常，但RW1实例无法被正常拉起，此时可以人工登录监视器执行takeover RW2进行主备切换。让RW2实例作为主库对外使用。因为配置模式为事务一致性模式，所以主备两边落盘事务一定是一致的，切换后不存在数据丢失。
  • 后续等待主库恢复，如果时间短正常拉起主库会自动进行故障处理后加入集群，如果故障恢复时间过长则参考原主库重建后再加入集群。

3.3.2.2、主库实例服务正常，备库实例服务故障

（1）故障现象

人为使kill -9 pid 关闭备库实例服务
##关闭备库实例
kill -9 pid

（2）故障处理

  • 此时，如果备库RW2守护正常，备库实例正常，则RW2守护检测到RW2实例故障后会自动拉起，正常拉起后集群可正常进入故障处理，从主库同步数据。主库可以正常对外提供服务。
  • 如果备库RW2守护正常，但RW2实例无法被正常拉起，此时不需要人工介入，主库在检查到RW2实例故障后会自动进入FAILOVER故障处理流程，此时RW1实例状态由OPEN->SUSPEND，等待归档置为失效后主库RW1守护退出FAILOVER状态，此时RW1实例状态由SUSPEND->OPEN重新正常对外提供服务，整个故障处理时间在5s左右完成。
  • 如果RW2实例故障时间过长，则参考备库重建步骤后再加入集群。

3.3.2.3、主库、备库实例服务均故障

（1）故障现象

人为使kill -9 pid 关闭主、备库实例服务
##关闭主、备库实例
kill -9 pid

（2）故障处理

  • 如果主备数据库守护正常，且实例正常，则主备实例会被自动拉起后恢复正常，
  • 如果主备实例不正常，则可以用主库最新归档和最新备份进行主备环境重建。重建后集群数据为故障前已落盘数据。
  • 如果主备集群机器同时故障，且无法获取到备份和归档信息，则无法恢复集群。

3.4、硬件故障处理

3.4.1、服务器故障

3.4.1.1、主库服务器故障，备库服务器正常

（1）故障现象

人为使主库服务器关闭
##关闭主库服务器
shutdown -h now

监视器上无法接收到主库信息
image.png
（2）故障处理

  • 如果主库机器此时无法短时间恢复，此时可以人工登录监视器执行takeover force RW2进行主备切换。让RW2实例作为主库对外使用。因为配置模式为事务一致性模式，所以主备两边落盘事务一定是一致的，切换后不存在数据丢失。
  • 如果主库服务器故障时间过长，等待服务器恢复后，参考备库重建步骤后再加入集群。
  • 如果主库机器可以快速拉起，则正常启动主库服务器后，按顺序依次启动主库RW1实例和守护进程，即可将集群恢复正常。

3.4.1.2、主库服务器正常，备库服务器故障

（1）故障现象

人为使备库服务器关闭
##关闭备库服务器
shutdown -h now

（2）故障处理

  • 此时不需要人工介入，主库在检查到RW2实例故障后会自动进入FAILOVER故障处理流程，此时RW1实例状态由OPEN->SUSPEND，等待归档置为失效后主库RW1守护退出FAILOVER状态，此时RW1实例状态由SUSPEND->OPEN重新正常对外提供服务，整个故障处理时间在5s左右完成。
  • 如果备库服务器故障时间过长，等待服务器恢复后，参考备库重建步骤后再加入集群。

3.4.1.3、主库、备库服务器均故障

（1）故障现象

人为使主库、备库服务器关闭
##关闭主库、备库服务器
shutdown -h now

（2）故障处理

  • 如果主备集群机器同时故障，且无法获取到备份和归档信息，则无法恢复集群。

3.4.2、磁盘故障

  • 参考实例服务故障章节

4、常用操作

4.1、主库维护

使用 SYSDBA 用户登录监视器。
dmmonitor /home/dmdba/dm/dmdbms/bin/dmmonitor.ini 
login 
用户名：SYSDBA 
密码：xxxxxx
手动切换主备库
Switchover RW2
将切换后的备库踢出集群
detach database DW1
关闭踢出的备库的守护进程、实例
$DM_HOME/bin/DmWatcherServicedw stop
$DM_HOME/bin/DmServicedw stop
维护操作
维护完成后，启动踢出的备库的实例、守护进程
$DM_HOME/bin/DmServicedw start
$DM_HOME/bin/DmWatcherServicedw start
将备库重新添加进集群
attach database DW1
手动主备切换
Switchover DW1
检查集群状态
执行以下命令，启动监视器：
dmmonitor /dmdata/dmdb/dmmonitor.ini
输入 show 命令查看集群状态

4.2、备库维护

将备库踢出集群
detach database RW2
关闭踢出的备库的守护进程、实例
$DM_HOME/bin/DmWatcherServicedw stop
$DM_HOME/bin/DmServicedw stop
维护操作
维护完成后，启动踢出的备库的实例、守护进程
$DM_HOME/bin/DmServicedw start
$DM_HOME/bin/DmWatcherServicedw start
将备库重新添加进集群
attach database RW2
检查集群状态
执行以下命令，启动监视器：
dmmonitor /dmdata/dmdb/dmmonitor.ini
输入 show 命令查看集群状态

4.3、主备库全停机重启

按顺序关闭数据库集群
关闭主库守护进程：$DM_HOME/bin/DmWatcherServicedw stop
关闭备库守护进程：$DM_HOME/bin/DmWatcherServicedw stop
关闭主库实例：$DM_HOME/bin/DmServicedw stop
关闭备库实例：$DM_HOME/bin/DmServicedw stop
全机维护
按顺序启动数据库集群
启动主库实例：$DM_HOME/bin/DmServicedw start
启动备库实例：$DM_HOME/bin/DmServicedw start
启动主库守护进程：$DM_HOME/bin/DmWatcherServicedw start
启动备库守护进程：$DM_HOME/bin/DmWatcherServicedw start

4.4、主备手动切换（集群正常时做法）

使用 SYSDBA 用户登录监视器。
dmmonitor /home/dmdba/dm/dmdbms/bin/dmmonitor.ini 
login 
用户名：SYSDBA 
密码：xxxxxx
使用Choose Switchover 命令列出能够切换为主库的备库列表
Choose Switchover 
手动切换主备库
Switchover RW2

4.5、故障主备手动切换（集群故障时做法）

使用 SYSDBA 用户登录监视器。
dmmonitor /home/dmdba/dm/dmdbms/bin/dmmonitor.ini 
login 
用户名：SYSDBA 
密码：xxxxx
使用Choose Takeover命令选出待接管备库
Choose Takeover
使用takeover命令接管故障主库。
takeover RW2
执行 show 命令查看确认。

4.6、备库重建

关闭备库守护进程、实例
$DM_HOME/bin/DmWatcherServicedw stop
$DM_HOME/bin/DmServicedw stop
启动 DIsql 登录主库，执行联机备份
disql SYSDBA/'"xxxxx"'@192.168.20.70:5236
SQL> BACKUP DATABASE FULL BACKUPSET '/dmdata/BACKUP_FILE_01';
注意，如果主库 dm.ini 中的 USE_AP 设置为 1，则需要先启动 dmap 服务。
ps -ef|grep dmap
若未启动，则先启动 DMAP 服务，dmdba 到安装目录的 bin 下执行以下命令：
DmAPService start
将备份文件拷贝至备库所在的机器上，执行脱机还原与恢复
dmrman CTLSTMT="RESTORE DATABASE '/dmdata/dmdb/dm.ini' FROM BACKUPSET '/dmdata/BACKUP_FILE_01'"
dmrman CTLSTMT="RECOVER DATABASE '/dmdata/dmdb/dm.ini' FOR STANDBY FROM BACKUPSET '/dmdata/BACKUP_FILE_01'"
dmrman CTLSTMT="RECOVER DATABASE '/dmdata/dmdb/dm.ini' UPDATE DB_MAGIC"
重新配置备库的dm.ini、dmmal.ini、dmarch.ini 和 dmwatcher.ini 配置文件
以Mount方式启动备库 
dmserver /dmdata/dmdb/dm.ini mount
新建终端使用DIsql登录备库，设置OGUID（若备库仍在同集群则忽略），修改备库模式
SQL>SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1); 
SQL>sp_set_oguid(453331); 
SQL>alter database standby; 
SQL>SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 0);
上述语句中，sp_set_oguid()设置的 OGUID 值必须与主库一致。若重建的备库仍和主库在同一个集群中，则还原后备库的 OGUID 值与主库是一致的，sp_set_oguid()步骤可省略。
启动备库的守护进程
dmwatcher /dmdata/dmdb/dmwatcher.ini
执行以上步骤后，恢复备库的准备过程已经完成。接下来，数据守护系统会将备库重加入数据守护系统，主库的守护进程会自动通知同步数据到备库，最终恢复主备库数据到一致状态。
如果数据规模比较大、联机备份耗时较长、应用压力比较大的情况下，主库联机备份、备库脱机还原过程中，主库可能又新产生了大量归档日志。使用上述步骤重建备库后，主库向备库同步历史数据的时间会比较久，主备库数据会在比较长的一段时间内处于不一致状态。对这种情况，用户可以通过归档备份、还原和归档恢复功能，将备库数据恢复到更加接近主库的最新状态，有效减少备库加入主备系统后的历史数据同步时间。执行步骤如下：
关闭备库守护进程、实例
$DM_HOME/bin/DmWatcherServicedw stop
$DM_HOME/bin/DmServicedw stop
启动 DIsql 登录主库，执行联机备份
disql SYSDBA/'"xxxxxx"'@192.168.20.70:5236
SQL>  BACKUP DATABASE FULL BACKUPSET '/dmdata/BACKUP_FILE_02' WITHOUT LOG;
注意，如果主库 dm.ini 中的 USE_AP 设置为 1，则需要先启动 dmap 服务。
ps -ef|grep dmap
若未启动，则先启动 DMAP 服务，dmdba 到安装目录的 bin 下执行以下命令：
DmAPService start
启动 DIsql 登录主库，查看备份集的 BEGIN_LSN，并从 BEGIN_LSN 开始备份主库的归档日志。（这里假设查询到的备份集 BEGIN_LSN 是 45620）
如果备份集不是在默认备份路径下，则需要先将备份集所在目录添加进来，否则会查询不到备份集信息：
SQL> SELECT SF_BAKSET_BACKUP_DIR_ADD('DISK','/dmdata');
查询备份集信息并执行备份：
SQL> SELECT BACKUP_NAME,BEGIN_LSN FROM V$BACKUPSET;
SQL> BACKUP ARCHIVE LOG FROM LSN 45620 BACKUPSET '/dmdata/ARCH_BAK_02';
将归档备份集拷贝至备库所在的机器，还原归档后、利用这些归档日志进行数据库恢复
dmrman CTLSTMT="RESTORE ARCHIVE LOG FROM BACKUPSET '/dmdata/ARCH_BAK_02' TO ARCHIVEDIR '/dmdata/arch'"
dmrman CTLSTMT="RECOVER DATABASE '/dmdata/dmdb/dm.ini' WITH ARCHIVEDIR '/dmdata/arch'"
dmrman CTLSTMT="RECOVER DATABASE '/dmdata/dmdb/dm.ini' UPDATE DB_MAGIC"
重新配置备库的dm.ini、dmmal.ini、dmarch.ini 和 dmwatcher.ini 配置文件
以Mount方式启动备库 
dmserver /dmdata/dmdb/dm.ini mount
新建终端使用disql登录备库，设置OGUID（若备库仍在同集群则忽略），修改备库模式
SQL>SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1); 
SQL>sp_set_oguid(453331); 
SQL>alter database standby; 
SQL>SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 0);
上述语句中，sp_set_oguid()设置的 OGUID 值必须与主库一致。若重建的备库仍和主库在同一个集群中，则还原后备库的 OGUID 值与主库是一致的，sp_set_oguid()步骤可省略。
启动备库的守护进程
dmwatcher /dmdata/dmdb/dmwatcher.ini

4.7、主备集群调整为单机

关闭确认监视器、守护、数据库，确认已终止；
使用dmdba用户登入确认监视器服务，查看确认监视器服务进程
su - dmdba
ps -ef |grep dmm
进入bin目录下停止确认监视器服务,查看确认监视器服务进程已经停止
$DM_HOME/bin/DmMonitorServiceDW stop
ps -ef |grep dmm
使用dmdba用户登入主备库服务器，确认服务进程以及集群状态
su - dmdba
ps -ef |grep -E "dms|dmw|dma"
$DM_HOME/bin/dmmonitor /dmdata/dmdb/dmmonitor.ini
进入后输入show查看集群状态  
WSTATUS 显示为 open 表示守护进程处于开启状态，INST_OK 为 OK 表示数据库处于正常运行状态，ISTATUS 为 open 表示数据库处于开启状态
按照主库守护-备库守护-主库实例服务-备库实例服务的顺序依次停止服务，停止后查看服务进程确认已停止
su - dmdba
关闭主库守护进程：$DM_HOME/bin/DmWatcherServicedw stop
关闭备库守护进程：$DM_HOME/bin/DmWatcherServicedw stop
关闭主库实例：$DM_HOME/bin/DmServicedw stop
关闭备库实例：$DM_HOME/bin/DmServicedw stop
ps -ef |grep -E "dms|dmw|dma"
主备库修改dm.ini内容
备份dm.ini
cp /dmdata/dmdb/dm.ini /dmdata/dmbak/dm.ini_bak$(date +%Y%m%d)
修改dm.ini参数
vi /dmdata/dmdb/dm.ini
将以下参数修改为
MAL_INI=0
ALTER_MODE_STATUS=1
主备库修改dmarch.ini，修改前备份，删除远程归档内容；
备份dmarch.ini文件
cp /dmdata/dmdb/dmarch.ini /dmdata/dmbak/dmarch.ini_bak$(date +%Y%m%d)
修改dmarch.ini内容
vi /dmdata/dmdb/dmarch.ini
将内容修改为
[ARCHIVE_LOCAL]
ARCH_TYPE = LOCAL
ARCH_DEST =/dmdata/arch
ARCH_FILE_SIZE = 512
ARCH_SPACE_LIMIT =  81920
主备库前台启动，登录数据库，修改数据库状态;
前台启动数据库
dmserver /dmdata/dmdb/dm.ini
出现SYSTEM IS READY.后，另起一个窗口登陆数据库
su - dmdba
cd $DM_HOME/bin
./disql SYSDBA/'"密码"'
SQL>alter database normal;
SQL>alter database open;
查看实例状态确定实例为STATUS$为OPEN，MODE$为NORMAL后退出数据库以及停止前台数据库服务	
SQL>select STATUS$,MODE$ from v$instance;
SQL>exit
前台启动窗口执行exit退出前台启动
主备库修改服务脚本；
修改数据库实例服务，将启动模式调整为open
cd $DM_HOME/bin
vi DmServicedw
将START_MODE修改为open
START_MODE=open
主备库通过服务正常启动数据库；
使用dmdba用户正常启动数据库实例服务
su - dmdba
$DM_HOME/bin/DmServicedw start
查看服务进程正常启动
ps -ef |grep -E "dms"
上一篇：
关于达梦备份JOB通过命令行调用总结学习
评论
后发表回复

作者

文章

阅读量

获赞

扫一扫
联系客服
logo
logo
logo
鄂Copyright © 达梦国产化应用创新实验室
达梦在线服务平台社区用户管理规范

鄂ICP备18017926号-1