达梦DW备库失联后在线恢复加入集群

于 2024-07-24 17:42:10 发布
阅读量1k 收藏 29
点赞数 31
文章标签： 网络 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/OSlinux123/article/details/140668688
版权

一、主库故障重启（备库接管前重启）

        主库故障后立即重启，此时主库的守护进程变成 Startup 状态，重新进入守护进程的 启动流程，将数据一致的备库归档设置为有效状态，其余备库归档设置成无效状态，并重新 Open主库。Open成功后继续作为主库，当检测到归档状态无效的备库正常时会启动 Recovery 处理流程，重新同步主备库数据。

1、备库故障处理

        备库产生故障（硬件故障或者内部网卡故障）时，主库的处理流程对手动切换、自动切 换模式处理上有些差异。

手动切换模式

        对于手动切换模式，检测到备库故障，满足 Failover 条件时，主库的守护进程立即 切换到Failover 状态，执行对应的故障处理，如果不满足切换 Failover 条件，则保持 当前状态不变。

手动切换模式下，主库守护进程切换 Failover 条件：

  1. 备库实例故障，或者主备库之间出现网络故障，或者备库重演时校验 LSN 不匹配，这三种场景下引发主库同步日志到备库失败挂起，主库实例处于 Suspend 状态

  2. 主库到此备库的归档状态是 Valid（读写分离集群没有此限制）

  3. 主库的守护进程处于 Startup、Open 和 Recovery状态

  4. 当前没有监视器命令正在执行

自动切换模式

        对于自动切换模式，主库的守护进程会自动判断切换到 Failover 状态或者 Confirm 确认状态，如果两种状态切换条件都不满足，则保持当前状态不变。

自动切换模式下，主库守护进程不进入 Confirm 确认状态，直接切换到 Failover 条件：

    1. 前四项条件，和上面列出的手动切换条件相同

    2. 备库实例故障，备库守护进程正常

如果只满足条件 1，不满足条件 2，则主库守护进程会先进入 Confirm 确认状态，等 待确认监视器的确认消息。主库的守护进程进入 Confirm 确认状态后，会有下面几种不同的处理：

    1. 主库和确认监视器之间网络连接正常

主库的守护进程收到了确认监视器返回的确认消息，如果确认监视器认定可以执行 Failover，则主库的守护进程会切换为 Failover 状态并执行对应的处理；如果确认监 视器认定不满足执行 Failover 条件，则主库的守护进程会一直保持在 Confirm 状态。确 认监视器认定主库可以执行 Failover 条件：

        1) 主库守护进程处于 Confirm 状态

        2) 主库实例正常，处于 Suspend 状态

        3) 主库没有被接管，不存在其他主库

        4) 没有 takeover/switchover 命令在执行

        5) 当前所有归档有效的备库均可以加入主库

    2. 主库和确认监视器之间网络连接异常，或者没有启动确认监视器。满足下面条件后 主库允许切换至 Failover 状态执行故障处理：

        1) 主库实例正常，处于 Suspend 状态

        2) 备库守护进程正常

        3) 主库没有被接管，不存在其他主库

        4) 没有 takeover/switchover 命令正在执行

        5) 备库故障前可以加入主库

    3. 主库和确认监视器网络恢复正常后，主库已经被接管。老主库的守护进程切换为 Startup 状态，重新判断是否可加入新主库。 主库守护进程进入 Failover 状态后的执行流程（自动或手动切换模式下执行流程相 同）：

        1) 对实时主备或 MPP 主备，通知主库修改发送归档失败的备库归档状态无效

        2) 通知主库重新 Open。

        3) 将主库的守护进程切换为 Open 状态

二、恢复日志

 Clear all ep g_dw_status finished, Recovery finished!
 switch sub_state to sub_stat_start!
 设置GRP1守护进程为OPEN(SUB:STARTUP)状态
 dm_connect_async connection 6 is in progress
 非自动切换模式下20s没有收到远程守护进程消息
 Local instance: 守护进程状态(OPEN) 实例状态(OK) 实例名(DM01) 模式(PRIMARY) 实例状态(OPEN) 归档状态(UNKNOWN) POCNT(8) FLSN(128083643) CLSN(1280836
 Instance: 守护进程状态(ERROR) 实例状态(OK) 实例名(DM02) 模式(STANDBY) 实例状态(OPEN) 归档状态(UNKNOWN) POCNT(8) FLSN(128042324) CLSN(128042680) S
 dm_connect_async connection 6 is timeout
 dm_connect_async connection 6 is in progress
 dm_connect_async connection 6 is timeout
 dw2_send_port_set from dmmonitor vio(6) set, mid(1673602727), from name:dmmonitor, ip:::ffff:192.168.12.125, mon_confirm:FALSE
 dw2_send_port_set to dmwatcher vio(8) set, mid(-1), to name:DM02, ip:192.168.12.126
 ohis_inst_info_copy_low, inst(DM02) apply info changed, old info[p_db_magic:1486960128, n_apply_ep:1], new info to set[p_db_magic:0, n_apply_ep:0
 远程实例的模式、状态或者归档状态发生变化，原状态是：
 Instance: 守护进程状态(ERROR) 实例状态(OK) 实例名(DM02) 模式(STANDBY) 实例状态(OPEN) 归档状态(UNKNOWN) POCNT(8) FLSN(128042324) CLSN(128042680) S
 远程实例的模式、状态或者归档状态发生变化，新状态是：
 dw2_send_port_set from dmmonitor vio(10) set, mid(1673602730), from name:dmmonitor, ip:::ffff:192.168.12.125, mon_confirm:FALSE
 远程实例的模式、状态或者归档状态发生变化，原状态是：
 远程实例的模式、状态或者归档状态发生变化，新状态是：
 Instance: 守护进程状态(STARTUP) 实例状态(OK) 实例名(DM02) 模式(UNKNOWN) 实例状态(SHUTDOWN) 归档状态(UNKNOWN) POCNT(0) FLSN(0) CLSN(0) SLSN(0) SSL
 ohis_inst_info_copy_low, inst(DM02) apply info changed, old info[p_db_magic:0, n_apply_ep:0], new info to set[p_db_magic:1486960128, n_apply_ep:1
 远程实例的模式、状态或者归档状态发生变化，原状态是：
 Instance: 守护进程状态(STARTUP) 实例状态(OK) 实例名(DM02) 模式(UNKNOWN) 实例状态(SHUTDOWN) 归档状态(UNKNOWN) POCNT(0) FLSN(0) CLSN(0) SLSN(0) SSL
 远程实例的模式、状态或者归档状态发生变化，新状态是：
 Instance: 守护进程状态(UNIFY EP) 实例状态(OK) 实例名(DM02) 模式(STANDBY) 实例状态(MOUNT) 归档状态(UNKNOWN) POCNT(8) FLSN(128045793) CLSN(12804579
 远程实例的模式、状态或者归档状态发生变化，原状态是：
 Instance: 守护进程状态(UNIFY EP) 实例状态(OK) 实例名(DM02) 模式(STANDBY) 实例状态(MOUNT) 归档状态(UNKNOWN) POCNT(8) FLSN(128045793) CLSN(12804579
 远程实例的模式、状态或者归档状态发生变化，新状态是：
 Instance: 守护进程状态(STARTUP) 实例状态(OK) 实例名(DM02) 模式(STANDBY) 实例状态(OPEN) 归档状态(UNKNOWN) POCNT(8) FLSN(128045793) CLSN(128045793)
 远程实例的模式、状态或者归档状态发生变化，原状态是：
 Instance: 守护进程状态(STARTUP) 实例状态(OK) 实例名(DM02) 模式(STANDBY) 实例状态(OPEN) 归档状态(UNKNOWN) POCNT(8) FLSN(128045793) CLSN(128045793)
 远程实例的模式、状态或者归档状态发生变化，新状态是：
 Instance: 守护进程状态(OPEN) 实例状态(OK) 实例名(DM02) 模式(STANDBY) 实例状态(OPEN) 归档状态(UNKNOWN) POCNT(8) FLSN(128045793) CLSN(128045793) SL
 [ohis_check_can_recover, p_iname:DM01, n_p_apply=0, p_apply_db_magic=1486960128, p_apply_seqno_arr=[1162045, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, s_iname:DM02, n_s_apply=1, s_apply_db_magic=1486960128, s_apply_seqno_arr=[1141458, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 switch sub_state to pre_set_dw_stat!
 设置GRP1守护进程为RECOVERY(SUB:STARTUP)状态
 [ohis_check_can_recover, p_iname:DM01, n_p_apply=0, p_apply_db_magic=1486960128, p_apply_seqno_arr=[1162045, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, s_iname:DM02, n_s_apply=1, s_apply_db_magic=1486960128, s_apply_seqno_arr=[1141458, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, p_iname:DM01, n_p_apply=0, p_apply_db_magic=1486960128, p_apply_seqno_arr=[1162045, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, s_iname:DM02, n_s_apply=1, s_apply_db_magic=1486960128, s_apply_seqno_arr=[1141458, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, p_iname:DM01, n_p_apply=0, p_apply_db_magic=1486960128, p_apply_seqno_arr=[1162045, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, s_iname:DM02, n_s_apply=1, s_apply_db_magic=1486960128, s_apply_seqno_arr=[1141458, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, p_iname:DM01, n_p_apply=0, p_apply_db_magic=1486960128, p_apply_seqno_arr=[1162045, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, s_iname:DM02, n_s_apply=1, s_apply_db_magic=1486960128, s_apply_seqno_arr=[1141458, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, p_iname:DM01, n_p_apply=0, p_apply_db_magic=1486960128, p_apply_seqno_arr=[1162045, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, s_iname:DM02, n_s_apply=1, s_apply_db_magic=1486960128, s_apply_seqno_arr=[1141458, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, p_iname:DM01, n_p_apply=0, p_apply_db_magic=1486960128, p_apply_seqno_arr=[1162045, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, s_iname:DM02, n_s_apply=1, s_apply_db_magic=1486960128, s_apply_seqno_arr=[1141458, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 dw2_notify_set_dw_stat, dseq = 1671462826, from_dw_stat: NONE, to_dw_stat: DW_RECOVERY
 Send tcp msg to local ep DM01, hpc_seqno:0, code:0
 设置GRP1守护进程子状态为WAIT_SET_DW_STAT状态
 dw2_group_get_curr_ep_retcode, ep(DM01) cmd_ret:cmd=217, dseq=1671462826, code=0
 dw2_clear_ep_cmd_info_low, clear ep(DM01) cmd info, and reset curr_ep to NULL.
 notify ep(DM01) set dw_stat to DW_RECOVERY success!
 [ohis_check_can_recover, p_iname:DM01, n_p_apply=0, p_apply_db_magic=1486960128, p_apply_seqno_arr=[1162045, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, s_iname:DM02, n_s_apply=1, s_apply_db_magic=1486960128, s_apply_seqno_arr=[1141458, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, p_iname:DM01, n_p_apply=0, p_apply_db_magic=1486960128, p_apply_seqno_arr=[1162045, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, s_iname:DM02, n_s_apply=1, s_apply_db_magic=1486960128, s_apply_seqno_arr=[1141458, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, p_iname:DM01, n_p_apply=0, p_apply_db_magic=1486960128, p_apply_seqno_arr=[1162045, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, s_iname:DM02, n_s_apply=1, s_apply_db_magic=1486960128, s_apply_seqno_arr=[1141458, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, p_iname:DM01, n_p_apply=0, p_apply_db_magic=1486960128, p_apply_seqno_arr=[1162045, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, s_iname:DM02, n_s_apply=1, s_apply_db_magic=1486960128, s_apply_seqno_arr=[1141458, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 检测到实例(DM02)可恢复，执行恢复流程
 开始向实例(DM02)发送归档日志
 [ohis_check_can_recover, p_iname:DM01, n_p_apply=0, p_apply_db_magic=1486960128, p_apply_seqno_arr=[1162045, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, s_iname:DM02, n_s_apply=1, s_apply_db_magic=1486960128, s_apply_seqno_arr=[1141458, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, p_iname:DM01, n_p_apply=0, p_apply_db_magic=1486960128, p_apply_seqno_arr=[1162045, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, s_iname:DM02, n_s_apply=1, s_apply_db_magic=1486960128, s_apply_seqno_arr=[1141458, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, p_iname:DM01, n_p_apply=0, p_apply_db_magic=1486960128, p_apply_seqno_arr=[1162045, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, s_iname:DM02, n_s_apply=1, s_apply_db_magic=1486960128, s_apply_seqno_arr=[1141458, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 dw2_rarch_send to DM02[seqno: 0], dseq = 1671462827
 [ohis_check_can_recover, p_iname:DM01, n_p_apply=0, p_apply_db_magic=1486960128, p_apply_seqno_arr=[1162045, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, s_iname:DM02, n_s_apply=1, s_apply_db_magic=1486960128, s_apply_seqno_arr=[1141458, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, p_iname:DM01, n_p_apply=0, p_apply_db_magic=1486960128, p_apply_seqno_arr=[1162045, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, s_iname:DM02, n_s_apply=1, s_apply_db_magic=1486960128, s_apply_seqno_arr=[1141458, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, p_iname:DM01, n_p_apply=0, p_apply_db_magic=1486960128, p_apply_seqno_arr=[1162045, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, s_iname:DM02, n_s_apply=1, s_apply_db_magic=1486960128, s_apply_seqno_arr=[1141458, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 Send tcp msg to local ep DM01, hpc_seqno:0, code:0
 设置GRP1守护进程子状态为WAIT_SEND_ARCH状态
 [ohis_check_can_recover, p_iname:DM01, n_p_apply=0, p_apply_db_magic=1486960128, p_apply_seqno_arr=[1162045, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 [ohis_check_can_recover, s_iname:DM02, n_s_apply=1, s_apply_db_magic=1486960128, s_apply_seqno_arr=[1141458, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
 dw2_rarch_send to DM02[seqno: 0], dseq = 1671462828
 Send tcp msg to local ep DM01, hpc_seqno:0, code:0
 dw2_rarch_send to DM02[seqno: 0], dseq = 1671462829
 Send tcp msg to local ep DM01, hpc_seqno:0, code:0
 dw2_rarch_send to DM02[seqno: 0], dseq = 1671462830
 Send tcp msg to local ep DM01, hpc_seqno:0, code:0
 dw2_rarch_send to DM02[seqno: 0], dseq = 1671462831
 Send tcp msg to local ep DM01, hpc_seqno:0, code:0
 dw2_rarch_send to DM02[seqno: 0], dseq = 1671462832
 Send tcp msg to local ep DM01, hpc_seqno:0, code:0
 检测到实例(DM02)发送归档成功,设置为当前恢复实例
 dw2_notify_sql_exec, dseq = 1671462833, sql: ALTER DATABASE SUSPEND
 Send tcp msg to local ep DM01, hpc_seqno:0, code:0
 设置GRP1守护进程子状态为WAIT_TO_SUSPEND状态
 向实例(DM02)发送归档日志成功，实例(DM01)转入suspend状态
 dw2_group_get_curr_ep_retcode, ep(DM01) cmd_ret:cmd=1, dseq=1671462833, code=100
 dw2_group_get_curr_ep_retcode, ep(DM01) cmd_ret:cmd=1, dseq=1671462833, code=0
 dw2_clear_ep_cmd_info_with_recv_inst_low, clear ep(DM01) cmd info, and reset curr_ep to NULL.
 转入suspend状态后，再次发送归档日志
 dw2_rarch_send to DM02[seqno: 0], dseq = 1671462834
 Send tcp msg to local ep DM01, hpc_seqno:0, code:0
 设置GRP1守护进程子状态为WAIT_SEND_ALL_ARCH状态
 dw2_group_get_curr_ep_retcode, ep(DM01) cmd_ret:cmd=210, dseq=1671462834, code=100
 dw2_group_get_curr_ep_retcode, ep(DM01) cmd_ret:cmd=210, dseq=1671462834, code=100
 dw2_group_get_curr_ep_retcode, ep(DM01) cmd_ret:cmd=210, dseq=1671462834, code=100
 dw2_group_get_curr_ep_retcode, ep(DM01) cmd_ret:cmd=210, dseq=1671462834, code=100
 dw2_group_get_curr_ep_retcode, ep(DM01) cmd_ret:cmd=210, dseq=1671462834, code=100
 dw2_group_get_curr_ep_retcode, ep(DM01) cmd_ret:cmd=210, dseq=1671462834, code=0
 发送归档完毕，设置实例(DM02)归档有效
 dw2_notify_chg_arch_status, dseq = 1671462835, rstat = 0
 Send tcp msg to local ep DM01, hpc_seqno:0, code:0
 设置GRP1守护进程子状态为WAIT_SET_ARCH状态
 dw2_group_get_curr_ep_retcode, ep(DM01) cmd_ret:cmd=100, dseq=1671462835, code=100
 实例(DM02)归档状态发生变化：INVALID --> VALID
 dw2_group_get_curr_ep_retcode, ep(DM01) cmd_ret:cmd=100, dseq=1671462835, code=0
 dw2_clear_ep_cmd_info_with_recv_inst_low, clear ep(DM01) cmd info, and reset curr_ep to NULL.
 设置实例(DM02)归档有效成功，通知实例(DM01)OPEN
 dw2_notify_sql_exec, dseq = 1671462836, sql: ALTER DATABASE OPEN FORCE
 Send tcp msg to local ep DM01, hpc_seqno:0, code:0
 设置GRP1守护进程子状态为WAIT_TO_OPEN状态
 dw2_group_get_curr_ep_retcode, ep(DM01) cmd_ret:cmd=1, dseq=1671462836, code=0
 dw2_clear_ep_cmd_info_with_recv_inst_low, clear ep(DM01) cmd info, and reset curr_ep to NULL.
 dw2_set_recover_info, instance:DM02, recover flag:TRUE, from monitor:FALSE, last_recv_time:1673602836, recover retry time:60
 本地守护进程为RECOVERY状态，本机实例为PRIMARY & OPEN，实例(DM02)故障恢复完成
 将实例(DM02)从恢复列表中删除
 不存在可恢复备库
 dw2_clear_ep_cmd_info_low, clear ep(DM01) cmd info.
 设置GRP1守护进程子状态为SUB_STATE_CLEAR状态
 Clear all ep dw_stat value!
 dw2_notify_set_dw_stat, dseq = 1671462837, from_dw_stat: DW_RECOVERY, to_dw_stat: NONE
 Send tcp msg to local ep DM01, hpc_seqno:0, code:0
 设置GRP1守护进程子状态为WAIT_CLEAR状态
 dw2_group_get_curr_ep_retcode, ep(DM01) cmd_ret:cmd=217, dseq=1671462837, code=100
 dw2_group_get_curr_ep_retcode, ep(DM01) cmd_ret:cmd=217, dseq=1671462837, code=0
 dw2_clear_ep_cmd_info_low, clear ep(DM01) cmd info, and reset curr_ep to NULL.
 notify ep(DM01) set dw_stat to NONE success!
 dw2_clear_ep_cmd_info_low, clear ep(DM01) cmd info.
 Clear all ep g_dw_status finished, Recovery finished!
 switch sub_state to sub_stat_start!
 设置GRP1守护进程为OPEN(SUB:STARTUP)状态

三、恢复流程图

OSlinux123
关注
达梦数据库-主备集群重建备库
05-11 535
背景介绍 已经搭建了实时主备集群，但是模拟的是备机的数据库服务器异常死机。 修改dm 主备集群的IP地址的操作。 从监视器上看到的是这样的景象，没有看到的守护进程的2。 然后怀疑是网络问题，遂去检查网络的通道的情况。 检查结果显示，网络是通的，对方也启动了这个服务端口。 遂去检查是备机的端口日志。看看备机的守护进程出现了什么问题。 在数据库启动服务的日志中发现这如下报错，原来是我在修改dmmal.ini 时把IP地址少写了一位，导致备库的守护进程不能连接到监视器。修改这个错..
达梦数据库搭建备库
soonyhuang的博客
05-04 338
OS版本: NeoKylin Linux Advanced Server 7.0 数据库版本: 8 DM_HOME: /dmdba/dmdbms 环境 DatabaseType IP PrivateIP HOSTANME 端口 数据库名 ======================================================================== 主库 xx.xxx.xx.xx xx.xxx.xx.xx xxxxdb...
达梦主备之备库失联后在线恢复加入集群
weixin_42018955的博客
01-18 1537
达梦主备之备库失联后在线恢复加入集群
达梦数据库-备机恢复方法
qq_17576885的博客
06-29 452
达梦数据库——备机恢复 ip 数据库软件安装目录 实例目录 主机 192.168.150.130 /home/dmdba/dmdbms /data/DAMENG 备机 192.168.150.130 /home/dmdba/dmdbms /data/DAMENG
达梦主备集群备库故障导致主库状态挂起如何恢复使用
最新发布
adminyang1的博客
12-01 400
强制OPEN指定组的指定库。
达梦8数据守护集群备库故障恢复
qq_36192280的博客
03-19 294
总结：在主备集群中备库故障情况下、如果要重建备库，因为主库的模式已经是primary模式，主库可以在线备份拷贝至备库恢复，不需要像单机搭建主备的情况将库关闭搭建。存在监视器情况下，备库故障在守护进程、数据库进程异常情况下，故障后主库会短暂suspend后open，确认监视器优先级较高，建议部署确认监视器。因主库是primary模式，可以通过主库在线备份后，拷贝到备库还原，备库恢复完成，且启动守护进程后会自动加入集群当中，不影响主库服务。#三、观察监视器备库自动加入集群当中，恢复完成。##2.2、备库还原。
达梦MPP主备集群详细搭建过程
weixin_39053024的博客
10-09 885
前言 基于主备的MPP集群在运行过程中，主机对外提供服务，备机则保持主备之间的数据同步，当主机出现故障时，备机替换主机，继续对外提供服务，保证系统的不中断和可靠性。本文以DM7的主备MPP搭建为例，首先呈现MPP主备集群示意图如下： 配置了相同OGUID的两个或多个守护进程，构成一个守护进程组。为方便管理，对每个守护进程组进行命名，守护进程组中的所有守护进程和监视器，必须配置相同的组名。 软件版本：centos7 达梦MPP主备集群搭建 (V7.6.0.184-Build(2019.08.08-11076
达梦数据守护（主备）
qq_40135088的博客
10-19 1024
一、数据守护概念 1、基础 （1）就是基于redo日志的主备系统，由数据库服务、守护进程、监视器组成 2、守护进程 （1）用来监控实例进程 （2）本地守护 监控实例，可配置重启数据库实例 （3）全局守护 通过和远程守护进程的交互，增加了主备库切换、主备库故障检测、备库接管、数据库故障重加入等功能。 （4）故障自动切换 需要确认监视器确认实例状态，才会自动切换 （5）故障手动切换 需要人为介入处理 （6）当检测到实例进程 ID 已经不存在或者超过一段时间没有收到实例消息（INST_E
达梦数据库学习之实时主备集群
weixin_42356462的博客
09-27 644
达梦数据库的主备集群建档讲解
达梦数据库安装之-实时主备集群
02-19 608
数据准备 配置数据守护 V4.0 之前，必须先通过备份还原方式同步各数据库的数据，确保各数据的数据保持完全一致。主库可以是新初始化的数据库，也可以是正在生产、使用中的数据库。不能使用分别初始化库或者直接拷贝数据文件的方法，原因如下： 1． 每个库都有一个永久魔数（permenant_magic），一经生成，永远不会改变，主库传送日志时会判断这个值是否一样，确保是来自同一个数据守护环境中的库，否则传送不了日志。 2． 由于 dminit 初始化数据库时，会生成随机...
达梦数据库主备集群备库异常
notyeah的博客
04-20 1299
主备集群备库状态异常 登录备库首先发现数据目录的磁盘空间已经用完，需要清理出空间。 查看日志的相关报错信息，主库发送归档日志到备库回复失败 登录dmonitor 查看集群状态。，备库状态为invalid。日志号相差甚大，只能用异构回复备库。 解决办法登录主库，执行一下备份命令；backup database full backupset ‘/opt/bak/fullbak’; 由于该盘是主备集群的共享盘，不需要另外拷贝到备库，备库也行查到该备份数据。 如果需要远程拷贝数据的话可.
达梦备库同步异常恢复
weixin_44971915的博客
07-04 171
达梦备库同步异常恢复
dg 主库丢失归档 解决方案
12-02 135
DG 主库丢失归档 主要原因就是备库没有APP呢，主库就误把归档删除了。常见的这种情况都是主库RMAN做备份的时候把归档删除了。 丢失归档解决方法：用...
达梦备份恢复dmrman
你学废了么的博客
04-22 757
脱机工具 DMRMAN 启动 RMAN 备份数据库，保证数据库处于正常退出的脱机状态。 RMAN>BACKUP DATABASE ‘/opt/dmdbms/data/DAMENG/dm.ini’ BACKUPSET ‘/home/dm_bak/db_full_bak_for_recover_dbmagic’; 准备目标库，可以使用备份库，也可以重新生成库或者直接指定目录还原。重新生 成库操作如下： dminit path=/opt/dmdbms/data db_name=DAMENG_FOR
达梦数据库自杀问题，达梦数据库异常宕机，达梦数据自动关闭
Rockandrollman的博客
12-14 2777
虽然有一些 halt 可以通过简单处理后（比如授权过期）立即恢复服务，但有一些也是我们需要非常留意的，特别是内存校验失败、数据文件校验失败相关的信息，这种一般也是一些语句在操作时出现内存泄露或者写溢出等导致，我们需要结合数据库异常时生成的 core 文件进行分析，才能最终确认问题的症结。这种情况下导致的进程中止，**我们需要检查数据库运行日志，搜索 halt 相关的内容 **，在 halt 内容附近会记录 halt 的详细原因，比如授权过期、文件不完整、内存被污染等。最常见的是 OOM KILL，
达梦数据库 主备
qq_33930506的博客
03-26 1321
实时主备由一个主库以及一个或者多个配置了实时（Realtime）归档的备库组成，其主要目的是保障数据库可用性，提高数据安全性。实时主备系统中，主库提供完整的数据库功能，备库提供只读服务。主库修改数据产生的Redo日志，通过实时归档机制，在写入联机Redo日志文件之前发送到备库，实时备库通过重演Redo日志与主库保持数据同步。当主库出现故障时，备库在将所有Redo日志重演结束后，就可以切换为主库对外...
达梦数据库的模式和状态
qq_41592403的博客
08-31 2338
1数据库模式 DM 支持 3 种数据库模式：Normal 模式、Primary 模式和 Standby 模式。 （1）Normal 模式 提供正常的数据库服务，操作没有限制。正常生成本地归档，但不发送实时归档(Realtime）、即时归档（Timely）和异步归档（Async）。 （2）Primary 模式 提供正常的数据库服务，操作有极少限制。该模式下部分功能受限，包括：不支持修改 表空间文件名、不支持修改 arch_ini 参数。正常生成本地归档，支持实时归档 （Realtime）、即时归档（Timel
达梦数据库主备集群备份恢复--LINUX操作系统
weixin_37737228的博客
04-12 996
数据库备份恢复的配置前提 确认达梦数据库的配置文件dmarch.ini已经创建并配置 示例内容如下： [ARCHIVE_LOCAL] ARCH_TYPE = LOCAL #本地归档类型 ARCH_DEST = /data/dmdbms/DAMENG/arch/ #本地归档存放路径 ARCH_FILE_SIZE = 1024 #单个归档大小，单位MB ARCH_SPACE_LIMIT ...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值