IBM DB2 两地三中心方案与配置

最新推荐文章于 2025-05-06 21:05:51 发布
最新推荐文章于 2025-05-06 21:05:51 发布
阅读量675 收藏 25
点赞数 8
文章标签： 数据库 DB2
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/openeis/article/details/147691080
版权

方案 - 使用相同站点故障转移自动化部署两站点多备用集群

此场景描述了具有多个备用数据库的 Pacemaker HADR 集群的规划，配置和部署以及从其中一个辅助备用数据库进行接管的详细信息。 此设置具有三个备用数据库：一个主备用数据库和两个辅助备用数据库。

重要信息: 在 Db2® 11.5.8 及更高版本中，当使用 Pacemaker 作为集成集群管理器时，支持相互故障转移高可用性。 在 Db2 11.5.6 及更高版本中，用于自动故障转移到 HADR 备用数据库的 Pacemaker 集群管理器随 Db2打包并安装。 在 Db2 11.5.5中，包含了 Pacemaker ，并且可用于生产环境。 在 Db2 11.5.4中， Pacemaker 仅作为技术预览包含在开发，测试和概念验证环境中。

重要提示： 要以根用户身份运行 db2cm 实用程序，请确保 DB2INSTANCE 环境变量设置为实例所有者。

环境

本主题说明使用同一站点故障转移自动化的两个站点部署具有多个备用数据库的 HADR。 下表显示了示例场景中使用的主机、实例、端口和预期角色集：

Hostname

实例名称

服务端口

预期的角色

Host_Adbinst110主
Host_Bdbinst220主体备用数据库
Host_Cdbinst330辅助备用数据库
Host_Ddbinst440辅助备用数据库

数据库 hadrdb 配置为具有概述的拓扑的多个备用数据库。 可以使用适合于特定部署的参数（例如，数据库名称）来更新所使用的所有命令。

使用归档日志记录配置数据库

只有配置了归档日志的数据库才支持 HADR。 如果数据库配置为循环日志记录 ，则必须首先更改 logarchmeth1 和 logarchmeth2 配置参数。 数据库更改为使用归档日志记录之前，需要对数据库进行脱机备份。

规划多备用设置

此方案引入了双站点多备用 Pacemaker HADR 设置。 此设置包括自动故障转移到在每个站点中启用的备用数据库，但不包括主 HADR 数据库和主备用数据库在主站点中相同域内的两个站点。 此外，两个辅助备用数据库位于灾难恢复 (DR) 站点的另一个域中。 此配置允许灾难恢复站点将主站点完全替换为在缺省情况下在任何辅助备用数据库上发出手动接管时启用的自动化。

下图图 1 描述了双站点三备用自动数据库设置。 主站点上的主虚拟 IP 可用于访问数据库，并且每个查询始终自动定向到主数据库。 每个站点中的两个主机之间支持 Pacemaker 自动化，这意味着当主站点或灾难恢复站点上的主机发生故障时， Pacemaker 会尝试恢复。

显示 Pacemaker 的双站点三备用双自动化数据库设置的图

在此拓扑中配置了多个备用数据库后， Pacemaker 将使用以下取决于方案的行为来自动执行恢复:

  • 主数据库故障
    • 主数据库在 Host_A 上失败，然后 Host_B 外接管上的主体备用数据库自动作为主数据库。 当旧主数据库重新联机时，它将重新集成为主备用数据库。
  • 主备用数据库故障
    • 主体备用数据库在 Host_B上失败，然后 Pacemaker 尝试将其恢复为主体备用数据库，而所有其他数据库仍处于同一角色。
  • 辅助备用数据库故障
    • 辅助备用数据库在 Host_C 或 Host_D 上失败。 Pacemaker 尝试将其恢复为辅助备用数据库。 其他数据库角色保持不变。
  • 在位于灾难恢复站点中的辅助数据库上强制接管
    • 如果在 Host_C 或 Host_D 上发出手动接管，那么 Host_A 和 Host_B 上的数据库都将成为辅助备用数据库，而 Host_C 和 Host_D 上的数据库将成为主数据库和主备用数据库。 角色切换后，前三个失败方案仍然适用。

配置多备用设置

使用以下命令来备份预期的主 HADR 数据库：

DB2 BACKUP DB hadrdb TO backup_dir

将备份映像复制到其他主机。 在每个期望的备用主机上，发出 DROP DB 以清除可能存在的任何旧数据库并复原备份映像:

DB2 DROP DB hadrdb

DB2 RESTORE DB hadrdb FROM backup_dir

在所有备用主机上复原数据库后，如在常规 HADR 设置中一样，必须明确设置以下数据库配置参数：

  • hadr_local_host
  • hadr_local_svc
  • hadr_remote_host
  • hadr_remote_inst
  • hadr_remote_svc

但是，在设置这些参数之前，用户需要确定 HADR 设置中的四个数据库的主机名，端口号和实例名称：

预期的角色

Hostname

端口号

实例名称

主Host_A10db2inst1
主体备用数据库Host_B20db2inst2
辅助备用数据库Host_C30db2inst3
辅助备用数据库Host_D40db2inst4

在主数据库上，hadr_remote_host、hadr_remote_inst 和 hadr_remote_svc 配置参数的设置对应主备用数据库的主机名、实例名和端口号。 在备用数据库上，这些配置参数的值对应主数据库的主机名、端口号和实例名。

此外，主机名和端口号用于在所有数据库上设置 hadr_target_list 配置参数。 在以下示例中，对于每个主机，将按如下所示配置 hadr_target_list：

Hostname

预期的角色

hadr_target_list

Host_A主Host_B:20|Host_C:30|Host_D:40
Host_B主体备用数据库Host_A:10|Host_C:30|Host_D:40
Host_C辅助备用数据库Host_D:40|Host_A:10|Host_B:20
Host_D辅助备用数据库Host_C:30|Host_A:10|Host_B:20

除了 hadr_target_list 配置设置之外，用户还始终希望主数据库与主备用数据库之间的同步尽可能最接近。 由于在每个站点内都配置了自动故障转移，因此在发出接管命令时，灾难恢复站点中的数据库可以成为主数据库和主备用数据库。 因此，所有数据库都可以将 hadr_syncmode 参数设置为 SYNC。 对于辅助备用数据库，还可以将 hadr_syncmode 参数设置为 SYNC，因为在 hadr_syncmode 中设置的同步方式只能在数据库成为主数据库或主备用数据库时有效，否则辅助数据库始终具有有效的 SUPERASYNC 同步方式。

可以发出以下命令来更新每个数据库上的配置参数：

  • 在 Host_A（主数据库）上： 
    DB2 "UPDATE DB CFG FOR hadrdb USING
HADR_TARGET_LIST  Host_B:20|Host_C:30|Host_D:40
HADR_REMOTE_HOST  Host_B
HADR_REMOTE_SVC   20
HADR_LOCAL_HOST   Host_A
HADR_LOCAL_SVC    10
HADR_SYNCMODE     sync
HADR_REMOTE_INST  db2inst2"

  • 在 Host_B（主备用数据库）上： 
    DB2 "UPDATE DB CFG FOR hadrdb USING
HADR_TARGET_LIST  Host_A:10|Host_C:30|Host_D:40
HADR_REMOTE_HOST  Host_A
HADR_REMOTE_SVC   10
HADR_LOCAL_HOST   Host_B
HADR_LOCAL_SVC    20
HADR_SYNCMODE     sync
HADR_REMOTE_INST  db2inst1"

  • 在 Host_C（辅助备用数据库）上： 
    DB2 "UPDATE DB CFG FOR hadrdb USING
HADR_TARGET_LIST  Host_D:40|Host_A:10|Host_B:20
HADR_REMOTE_HOST  Host_A
HADR_REMOTE_SVC   10
HADR_LOCAL_HOST   Host_C
HADR_LOCAL_SVC    30
HADR_SYNCMODE     sync
HADR_REMOTE_INST  db2inst1"

  • 在 Host_D（辅助备用数据库）上： 
    DB2 "UPDATE DB CFG FOR hadrdb USING
HADR_TARGET_LIST  Host_C:30|Host_A:10|Host_B:20
HADR_REMOTE_HOST  Host_A
HADR_REMOTE_SVC   10
HADR_LOCAL_HOST   Host_D
HADR_LOCAL_SVC    40
HADR_SYNCMODE     sync
HADR_REMOTE_INST  db2inst1"

配置每个数据库后，将显示每个数据库：

配置参数

Host_A

Host_B

Host_C

Host_D

hadr_target_listHost_B:20|Host_C:30|Host_D:40Host_A:10|Host_C:30|Host_D:40Host_D:40|Host_A:10|Host_B:20Host_C:30|Host_A:10|Host_B:20
hadr_remote_hostHost_BHost_AHost_AHost_A
hadr_remote_svc20101010
hadr_remote_instdb2inst2db2inst1db2inst1db2inst1
hadr_local_hostHost_AHost_BHost_CHost_D
hadr_local_svc10203040
已配置 hadr_syncmodeSYNCSYNCSYNCSYNC
有效 hadr_syncmode不适用SYNCSUPERASYNCSUPERASYNC

注: 可以通过在每个主机上运行 db2pd -db hadrdb -hadr 命令来查看有效 hadr_syncmode 参数。

启动 HADR 数据库

通过在 Host_B、Host_C 和 Host_D 上发出以下命令，先在在备用数据库上启动 HADR：

DB2 START HADR ON DB hadrdb AS STANDBY

然后，在主数据库（在本示例中为 Host_A）上启动 HADR：

DB2 START HADR ON DB hadrdb AS PRIMARY

要验证 HADR 是否已启动并正在运行，请通过运行 db2pd -db hadrdb -hadr 命令从 Host_A 上的主数据库查询数据库的状态，该命令将返回有关所有备用数据库的信息。 例如：

db2pd -db hadrdb -hadr

Database Member 0 -- Database hadrdb -- Active -- Up 0 days 00:00:13 -- Date 2020-07-14-08.52.30.018629

                            HADR_ROLE = PRIMARY
                          REPLAY_TYPE = PHYSICAL
                        HADR_SYNCMODE = SYNC
                          STANDBY_ID = 1
                        LOG_STREAM_ID = 0
                          HADR_STATE = PEER
                          HADR_FLAGS = TCP_PROTOCOL
                  PRIMARY_MEMBER_HOST = Host_A
                    PRIMARY_INSTANCE = db2inst1
                      PRIMARY_MEMBER = 0
                  STANDBY_MEMBER_HOST = Host_B
                    STANDBY_INSTANCE = db2inst2
                      STANDBY_MEMBER = 0
                  HADR_CONNECT_STATUS = CONNECTED
            HADR_CONNECT_STATUS_TIME = 2020-07-14 08.52.19.818272 (1594741939)
          HEARTBEAT_INTERVAL(seconds) = 30
                    HEARTBEAT_MISSED = 0
                  HEARTBEAT_EXPECTED = 0
                HADR_TIMEOUT(seconds) = 120
        TIME_SINCE_LAST_RECV(seconds) = 8
            PEER_WAIT_LIMIT(seconds) = 0
          LOG_HADR_WAIT_CUR(seconds) = 0.000
    LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.007153
  LOG_HADR_WAIT_ACCUMULATED(seconds) = 0.021
                  LOG_HADR_WAIT_COUNT = 3
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 87040
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 369280
            PRIMARY_LOG_FILE,PAGE,POS = S0000000.LOG, 14, 44893780
            STANDBY_LOG_FILE,PAGE,POS = S0000000.LOG, 0, 44836001
                  HADR_LOG_GAP(bytes) = 0
    STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000000.LOG, 0, 44836001
      STANDBY_RECV_REPLAY_GAP(bytes) = 0
                    PRIMARY_LOG_TIME = 2020-07-14 08.52.21.000000 (1594741941)
                    STANDBY_LOG_TIME = 2020-07-14 08.49.57.000000 (1594741797)
              STANDBY_REPLAY_LOG_TIME = 2020-07-14 08.49.57.000000 (1594741797)
        STANDBY_RECV_BUF_SIZE(pages) = 512
            STANDBY_RECV_BUF_PERCENT = 0
          STANDBY_SPOOL_LIMIT(pages) = 13000
                STANDBY_SPOOL_PERCENT = 0
                  STANDBY_ERROR_TIME = NULL
                PEER_WINDOW(seconds) = 120
                      PEER_WINDOW_END = 2020-07-14 08.54.20.000000 (1594742060)
            READS_ON_STANDBY_ENABLED = N
              HADR_LAST_TAKEOVER_TIME = NULL

                            HADR_ROLE = PRIMARY
                          REPLAY_TYPE = PHYSICAL
                        HADR_SYNCMODE = SUPERASYNC
                          STANDBY_ID = 2
                        LOG_STREAM_ID = 0
                          HADR_STATE = REMOTE_CATCHUP
                          HADR_FLAGS = TCP_PROTOCOL
                  PRIMARY_MEMBER_HOST = Host_A
                    PRIMARY_INSTANCE = db2inst1
                      PRIMARY_MEMBER = 0
                  STANDBY_MEMBER_HOST = Host_C
                    STANDBY_INSTANCE = db2inst3
                      STANDBY_MEMBER = 0
                  HADR_CONNECT_STATUS = CONNECTED
            HADR_CONNECT_STATUS_TIME = 2020-07-14 08.52.20.189945 (1594741940)
          HEARTBEAT_INTERVAL(seconds) = 30
                    HEARTBEAT_MISSED = 0
                  HEARTBEAT_EXPECTED = 0
                HADR_TIMEOUT(seconds) = 120
        TIME_SINCE_LAST_RECV(seconds) = 10
            PEER_WAIT_LIMIT(seconds) = 0
          LOG_HADR_WAIT_CUR(seconds) = 0.000
    LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.007153
  LOG_HADR_WAIT_ACCUMULATED(seconds) = 0.021
                  LOG_HADR_WAIT_COUNT = 3
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 87040
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 369280
            PRIMARY_LOG_FILE,PAGE,POS = S0000000.LOG, 14, 44893780
            STANDBY_LOG_FILE,PAGE,POS = S0000000.LOG, 0, 44836001
                  HADR_LOG_GAP(bytes) = 0
    STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000000.LOG, 0, 44836001
      STANDBY_RECV_REPLAY_GAP(bytes) = 0
                    PRIMARY_LOG_TIME = 2020-07-14 08.52.21.000000 (1594741941)
                    STANDBY_LOG_TIME = 2020-07-14 08.49.57.000000 (1594741797)
              STANDBY_REPLAY_LOG_TIME = 2020-07-14 08.49.57.000000 (1594741797)
        STANDBY_RECV_BUF_SIZE(pages) = 512
            STANDBY_RECV_BUF_PERCENT = 0
          STANDBY_SPOOL_LIMIT(pages) = 13000
                STANDBY_SPOOL_PERCENT = 0
                  STANDBY_ERROR_TIME = NULL
                PEER_WINDOW(seconds) = 0
            READS_ON_STANDBY_ENABLED = N
              HADR_LAST_TAKEOVER_TIME = NULL

                            HADR_ROLE = PRIMARY
                          REPLAY_TYPE = PHYSICAL
                        HADR_SYNCMODE = SUPERASYNC
                          STANDBY_ID = 3
                        LOG_STREAM_ID = 0
                          HADR_STATE = REMOTE_CATCHUP
                          HADR_FLAGS = TCP_PROTOCOL
                  PRIMARY_MEMBER_HOST = Host_A
                    PRIMARY_INSTANCE = db2inst1
                      PRIMARY_MEMBER = 0
                  STANDBY_MEMBER_HOST = Host_D
                    STANDBY_INSTANCE = db2inst4
                      STANDBY_MEMBER = 0
                  HADR_CONNECT_STATUS = CONNECTED
            HADR_CONNECT_STATUS_TIME = 2020-07-14 08.52.19.403210 (1594741939)
          HEARTBEAT_INTERVAL(seconds) = 30
                    HEARTBEAT_MISSED = 0
                  HEARTBEAT_EXPECTED = 0
                HADR_TIMEOUT(seconds) = 120
        TIME_SINCE_LAST_RECV(seconds) = 11
            PEER_WAIT_LIMIT(seconds) = 0
          LOG_HADR_WAIT_CUR(seconds) = 0.000
    LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.007153
  LOG_HADR_WAIT_ACCUMULATED(seconds) = 0.021
                  LOG_HADR_WAIT_COUNT = 3
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 87040
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 369280
            PRIMARY_LOG_FILE,PAGE,POS = S0000000.LOG, 14, 44893780
            STANDBY_LOG_FILE,PAGE,POS = S0000000.LOG, 0, 44836001
                  HADR_LOG_GAP(bytes) = 0
    STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000000.LOG, 0, 44836001
      STANDBY_RECV_REPLAY_GAP(bytes) = 0
                    PRIMARY_LOG_TIME = 2020-07-14 08.52.21.000000 (1594741941)
                    STANDBY_LOG_TIME = 2020-07-14 08.49.57.000000 (1594741797)
              STANDBY_REPLAY_LOG_TIME = 2020-07-14 08.49.57.000000 (1594741797)
        STANDBY_RECV_BUF_SIZE(pages) = 512
            STANDBY_RECV_BUF_PERCENT = 0
          STANDBY_SPOOL_LIMIT(pages) = 13000
                STANDBY_SPOOL_PERCENT = 0
                  STANDBY_ERROR_TIME = NULL
                PEER_WINDOW(seconds) = 0
            READS_ON_STANDBY_ENABLED = N
              HADR_LAST_TAKEOVER_TIME = NULL

在 HADR 运行后，需要为两个站点上的所有主机创建 Pacemaker 资源以进行集群管理。 由于只能在活动站点 (主站点) 上创建 Pacemaker 资源，因此用户必须首先以 root 用户身份在主站点上创建 Pacemaker 资源:

  1. 通过运行以下命令来创建集群和以太网资源： 
    db2cm -create -cluster -domain db2ha1 -host Host_A -publicEthernet eth1 -host Host_B -publicEthernet eth1

  2. 通过运行以下命令来创建实例资源： 
    db2cm -create -instance db2inst1 -host Host_A

    和 
    db2cm -create -instance db2inst2 -host Host_B

  3. 在 Host_A 上，通过运行以下命令来创建数据库资源： 
    db2cm -create -db hadrdb -instance db2inst1

  4. 在 主机 A 上，通过运行以下操作创建主虚拟 IP（IP 地址可以在与主机相同的子网中）： 
    db2cm -create -primaryVIP x.x.x.x -db hadrdb -instance db2inst1

  5. 在 Host_A 上，通过运行以下操作来创建备用虚拟 IP（IP 地址可以在与主机相同的子网中）： 
    db2cm -create -standbyVIP x.x.x.x -db hadrdb -instance db2inst1

成功完成上述步骤后，可以通过运行 crm status 命令来验证 Pacemaker 资源:

Online: [ Host_A Host_B ]

Full list of resources:
db2_Host_A_eth1       (ocf::heartbeat:db2ethmon):     Started Host_A
db2_Host_B_eth1      (ocf::heartbeat:db2ethmon):     Started Host_B
db2_Host_B_db2inst2_0        (ocf::heartbeat:db2inst):       Started Host_B
db2_Host_A_db2inst1_0 (ocf::heartbeat:db2inst):       Started Host_A
Clone Set: db2_db2inst1_db2inst2_hadrdb-clone [db2_db2inst1_db2inst2_hadrdb] (promotable)
Promoted: [ Host_A ]
Unpromoted: [ Host_B ]
db2_db2inst1_db2inst2_hadrdb-primary-VIP  (ocf::heartbeat:IPaddr2):    Started Host_A
db2_db2inst1_db2inst2_hadrdb-standby-VIP  (ocf::heartbeat:IPaddr2):  Started Host_B

接下来，在灾难恢复站点上创建 Pacemaker 资源。

  1. 在 Host_C 上手动发出接管命令，以使站点 2 成为主站点，Host_C 现在托管主数据库。 
    DB2 TAKEOVER HADR ON DB hadrdb

  2. 在将主机名和实例名替换为 Host_C 和 Host_D 的名称时，重复 Host_C 上的先前步骤。 通过运行 crm status 来验证资源的状态。
  3. 在 Pacemaker 资源联机后，在 Host_A 上手动发出接管，以将所有数据库接管回原始主站点: 
    DB2 TAKEOVER HADR ON DB hadrdb

现在，灾难恢复站点的 crm status 输出可以如下所示：

Online: [ Host_C Host_D ]

Full list of resources:
db2_Host_C_eth1       (ocf::heartbeat:db2ethmon):     Started Host_C
db2_Host_D_eth1       (ocf::heartbeat:db2ethmon):     Started Host_D
db2_Host_D_db2inst4_0        (ocf::heartbeat:db2inst):       Started Host_D
db2_Host_C_db2inst3_0        (ocf::heartbeat:db2inst):       Started Host_C
Clone Set: db2_db2inst3_db2inst4_hadrdb-clone [db2_db2inst3_db2inst4_hadrdb] (promotable) (unmanaged)
db2_db2inst3_db2inst4_hadrdb (ocf::heartbeat:db2hadr):  Promoted Host_C (unmanaged)
db2_db2inst3_db2inst4_hadrdb (ocf::heartbeat:db2hadr):  Unpromoted Host_D (unmanaged)
db2_db2inst3_db2inst4_hadrdb-primary-VIP  (ocf::heartbeat:IPaddr2):    Started Host_C
db2_db2inst3_db2inst4_hadrdb-standby-VIP  (ocf::heartbeat:IPaddr2):  Started Host_D

主数据库与主备用数据库之间的故障转移

当 Host_A 上的主数据库发生故障时， Pacemaker 会自动将 Host_B 接管上的主备用数据库作为主数据库，然后尝试将旧主数据库恢复为主备用数据库，如下图所示:

在此情况下，配置参数 hadr_remote_host、hadr_remote_svc 和 hadr_remote_inst 在 Host_C 和 Host_D 上更改，并且更新为指向 Host_B 上的新主服务器。

配置参数

Host_A

Host_B

Host_C

Host_D

hadr_target_listHost_B:20|Host_C:30|Host_D:40Host_A:10|Host_C:30|Host_D:40Host_D:40|Host_A:10|Host_B:20Host_C:30|Host_A:10|Host_B:20
hadr_remote_hostHost_BHost_AHost_BHost_B
hadr_remote_svc20102020
hadr_remote_instdb2inst2db2inst1db2inst2db2inst2
hadr_local_hostHost_AHost_BHost_CHost_D
hadr_local_svc10203040
已配置 hadr_syncmodeSYNCSYNCSYNCSYNC
有效 hadr_syncmodeSYNC不适用SUPERASYNCSUPERASYNC

多备用 Pacemaker HADR 设置中的站点之间的接管

在整个主站点将进行维护或计划停运的情况下，通过发出手动接管命令，灾难恢复站点可以接管为主站点，以确保数据库始终保持可用。 在发出接管之前，用户需要通过运行以下命令来查询两个辅助备用数据库以确定哪个具有最多日志数据：

db2pd -hadr -db hadrdb | grep STANDBY_LOG_FILE,PAGE,POS

以下是从 Host_C 运行该命令的样本输出：

STANDBY_LOG_FILE,PAGE,POS = S0000001.LOG, 142, 72318245

以下是从 Host_D 运行该命令的样本输出：

STANDBY_LOG_FILE,PAGE,POS = S0000001.LOG, 134, 63254745

要检查备用数据库是否是最新的，请首先检查它的日志文件名中是否有最大的日志序列，然后检查它是否具有最大的页号，最后检查它是否具有最大的位置值。 如果所有三个值都相同，那么可以选取任何辅助备用数据库。

在此示例中，Host_C 上的数据库确定为最新的数据库，因此它可以通过在 Host_C 上运行接管命令成为主数据库：

DB2 TAKEOVER HADR ON DB hadrdb

接管成功完成后， Host_C 上的数据库现在将成为新的主数据库，而 Host_D 的数据库将成为新的主体备用数据库，因为它首先位于 Host_C上的数据库的 hadr_target_list 上。 现在可以使用新的主站点上的主 VIP 来访问数据库。

设置将类似于下图：

Host_C 上 hadr_remote_host， hadr_remote_svc和 hadr_remote_inst 的值将重新配置为指向 Host_D。 同时，Host_D 上的这些参数将重新配置为指向 Host_C。 不会更改 Host_A 和 Host_B 上的配置值，因为它们仍然处于脱机状态并且不可用。 将显示每个数据库的配置值：

配置参数

Host_A

Host_B

Host_C

Host_D

hadr_target_listHost_B:20|Host_C:30|Host_D:40Host_A:10|Host_C:30|Host_D:40Host_D:40|Host_A:10|Host_B:20Host_C:30|Host_A:10|Host_B:20
hadr_remote_hostHost_CHost_CHost_DHost_C
hadr_remote_svc30304030
hadr_remote_instdb2inst3db2inst3db2inst4db2inst3
hadr_local_hostHost_AHost_BHost_CHost_D
hadr_local_svc10203040
已配置 hadr_syncmodeSYNCSYNCSYNCSYNC
有效 hadr_syncmodeSUPERASYNCSUPERASYNC不适用SYNC

在多备用 Pacemaker HADR 设置中的站点之间进行故障转移

在整个主站点 Host_A 和 Host_B 都关闭的情况下，灾难恢复站点需要接管作为主站点并接受客户机流量。 在发出接管之前，用户需要通过运行以下命令来查询两个辅助备用数据库以确定哪个具有最多日志数据：

db2pd -hadr -db hadrdb | grep STANDBY_LOG_FILE,PAGE,POS

在此示例中，Host_C 被确定为最新的最新版本，因此可以使用以下命令将其作为新主项进行选取：

DB2 TAKEOVER HADR ON DB hadrdb BY FORCE

成功完成接管后， Host_C 上的数据库将成为新的主数据库，而 Host_D 上的数据库将成为新的主要备用数据库，因为它是 Host_C上数据库的 hadr_target_list 上的第一个数据库。 现在可以使用新的主站点上的主 VIP 来访问 Host_C 上的数据库。

Host_C 上 hadr_remote_host， hadr_remote_svc和 hadr_remote_inst 的值将重新配置为指向 Host_D。 同时，Host_D 上的这些参数将重新配置为指向 Host_C。 不会更改 Host_A 和 Host_B 上的配置值，因为它们仍然处于脱机状态并且不可用。 将显示每个数据库的配置值：

配置参数

Host_A（不可用）

Host_B（不可用）

Host_C

Host_D

hadr_target_listHost_B:20|Host_C:30|Host_D:40Host_A:10|Host_C:30|Host_D:40Host_D:40|Host_A:10|Host_B:20Host_C:30|Host_A:10|Host_B:20
hadr_remote_hostHost_BHost_AHost_DHost_C
hadr_remote_svc20104030
hadr_remote_instdb2inst2db2inst1db2inst4db2inst3
hadr_local_hostHost_AHost_BHost_CHost_D
hadr_local_svc10203040
已配置 hadr_syncmodeSYNCSYNCSYNCSYNC
有效 hadr_syncmode不适用不适用不适用SYNC

经过一定时间后，旧主站点将重新联机，这意味着 Host_A 和 Host_B 将再次可用。 原始主站点恢复后，Host_A 和 Host_B 变为可用，数据库无法启动，因为并非所有日志都传播到 Host_C。 必须使用以下步骤手动重新集成它们：

  1. 通过在 Host_A 和 Host_B 上发出以下命令来取消激活这两个主机上的数据库： 
    DB2 DEACTIVATE DB hadrdb

  2. 通过运行以下命令在 Host_A 和 Host_B 上停止 HADR，以禁用它们之间的自动化： 
    DB2 STOP HADR ON DB hadrdb

  3. 通过运行以下命令来删除 Host_A 和 Host_B 上的数据库： 
    DB2 DROP DB hadrdb

  4. 通过运行以下命令来联机备份 Host_C 上新的主数据库： 
    DB2 BACKUP DB hadrdb online

  5. 使用 scp 命令将备份映像复制到 Host_A 和 Host_B 。
  6. 通过运行以下命令，在 Host_A 和 Host_B 上使用备份映像来复原数据库： 
    DB2 RESTORE DB hadrdb

  7. 通过在每个主机上运行以下命令，重新配置 Host_A 和 Host_B 上已复原的数据库：在 Host_A 上： 
    DB2 "UPDATE DB CFG FOR hadrdb USING
HADR_TARGET_LIST  Host_B:20|Host_C:30|Host_D:40
HADR_REMOTE_HOST  Host_C
HADR_REMOTE_SVC   30
HADR_LOCAL_HOST   Host_A
HADR_LOCAL_SVC    10
HADR_SYNCMODE     sync
HADR_REMOTE_INST  db2inst3"

    在 Host_B 上： 
    DB2 "UPDATE DB CFG FOR hadrdb USING
HADR_TARGET_LIST  Host_A:10|Host_C:30|Host_D:40
HADR_REMOTE_HOST  Host_C
HADR_REMOTE_SVC   30
HADR_LOCAL_HOST   Host_B
HADR_LOCAL_SVC    20
HADR_SYNCMODE     sync
HADR_REMOTE_INST  db2inst3"

  8. 在 Host_A 和 Host_B 上启动 HADR，以通过运行以下操作将其重新融入辅助备用数据库： 
    DB2 START HADR ON DB hadrdb AS STANDBY

成功运行先前的命令后，Host_A 和 Host_B 可以成功成为辅助备用数据库。 下图说明了新设置：

可以将这两个数据库上的 hadr_remote_host， hadr_remote_svc和 hadr_remote_inst 的值重新配置为指向新的主数据库，并且这两个数据库的有效 hadr_syncmode 现在可以变为 SUPERASYNC。 将显示每个数据库的配置：

配置参数

Host_A

Host_B

Host_C

Host_D

hadr_target_listHost_B:20|Host_C:30|Host_D:40Host_A:10|Host_C:30|Host_D:40Host_D:40|Host_A:10|Host_B:20Host_C:30|Host_A:10|Host_B:20
hadr_remote_hostHost_CHost_CHost_DHost_C
hadr_remote_svc30304030
hadr_remote_instdb2inst3db2inst3db2inst4db2inst3
hadr_local_hostHost_AHost_BHost_CHost_D
hadr_local_svc10203040
已配置 hadr_syncmodeSYNCSYNCSYNCSYNC
有效 hadr_syncmodeSUPERASYNCSUPERASYNC不适用
“两地三中心”和“双活”简介--容灾技术方案
hungson9814067的博客
12-03 4921
当前 市场上常见的 容灾 模式可分为同城容灾、异地容灾、 双活 数据中心、 两地 三中心几种。 1、 同城 容灾 同城 容灾 是在同城或相近区域内 （ ≤ 200K M ）建立两个数据中心 : 一个为数据中心，负责日常生产运行 ; 另一个为灾难备份中心，负责在灾难发生后的应用系统运行。同城灾难备份的数据中心与灾难备份中心的距离比较近，通信线路质量较好，比较容易实现数据的同步 复制 ，保证高度的数据完整性和数据零丢失。同城灾难备份一般用于防范火灾、建筑物破坏、供电故障、计算机系统及人为破坏引起的灾难。 2、
oracle双活数据中心建设_两地三中心数据中心和同城双活数据中心的区别？
weixin_39988476的博客
12-20 961
谈到双活就必须要从IT业务连续性管理这个话题谈起。只有从根上我们知道这个需求以及技术方案是怎么生长出来的，我们才能够彻底搞清楚，用户在什么情况下适合什么样的解决方案，以及未来技术解决方案的走向。为了保证IT系统对业务支撑的连续性，在HA高可靠方案的基础上，生长出来了DR的概念。即如果由于某些不可抗力原因，如火灾、地震、公共卫生安全事件、或其他原因，导致单数据中心整个出现问题，如何能够保证IT能够继...
DB2-HADR(High Availability Disaster Recovery)简叙及安装使用
MyGaoRen的博客
10-29 4348
# DB2 HADR(High Availability Disaster Recovery)简叙及安装使用 HADR( 高可用性灾难恢复 ) 是 DB2 数据库的一个组件，是 DB2 提供给用户的一种高可用性和灾难恢复的解决方案，提供数据库级别的数据保护。使用场景包括数据库热备保护、业务数据的读写分离、站点间容灾保护。
DB2数据库(PureScale)双活方案设计要点
架构师技术联盟
09-07 4495
分享专家: 孔再华 数据库架构师文章来源: 转自talkwithtrend 公众号具有丰富的数据库环境问题诊断和性能调优的经验，擅长DB2 PureScale 集群产品的...
XX银行数据中心建设方案
热门推荐
移动互联技术----酒歌
12-03 1万+
引言 摘要：本文简单介绍EMC SRDF技术，重点阐述了银行如何利用该技术进行新旧数据中心搬迁、灾难备份的系统设计，详细介绍了如何按照系统设计要求逐步将旧数据中心安全地、迅速地搬迁到新的数据中心，并最终形成一套灾难备份系统。 关键字：SRDF、数据迁移、灾难备份 随着银行数据集中的深入开展，各种业务数据都进行集中处理。随着业务的不断拓展，我们可能需要对旧数据中心进行扩容，并进行新中心的建设。
基于DB2数据库PureScale双活设计要点梳理
架构师技术联盟
09-10 930
在两地三中心建设过程中，我们发现采用传统的容灾技术碰到3个问题。1. 切换时间太长，即使通过自动化实现，主切备和备切主都需要花费几十分钟时间。2. 操作风险太大，比如核心...
某银行客户Db2下移分布式数据库OceanBase案例
OceanBase分布式数据库的博客
09-14 1356
本文由阿里技术专家吉远撰写于2022年2月。
谈谈双活业务中心和异地容灾备份设计
民工哥的博客
05-21 1987
点击下方公众号「关注」和「星标」回复“1024”获取独家整理的学习资料！今天谈下多数据中心和异地容灾备份方面的内容。在前面一篇文章里面我详细谈到过一个软件业务系统的高可用性设计，其中既包括...
DB2-GPFS(General Parallel File System)并行文件系统简叙、安装使用及DB高可用
MyGaoRen的博客
10-31 1935
# DB2-Spectrum Scale(GPFS)并行文件系统简叙、安装使用及DB高可用 GPFS介绍，以及简单配置资源
行业分类-设备装置-一种基于安腾平台下实现DB2数据库两地三中心的方法.zip
09-03
6. **法规遵从性**：在金融等行业，必须符合严格的法规要求，如数据保护和隐私政策，因此在设计两地三中心方案时要考虑合规性。 7. **运维管理**：建立完善的运维流程和监控体系，及时发现并解决可能出现的问题，...
两地三中心容灾系统设计方案（5页）.pdf
02-21
【两地三中心容灾系统设计方案】是金融行业中为了确保数据安全和业务连续性的重要实践。这一方案旨在构建一个跨越三个不同地理位置的系统，以抵御自然灾害、人为错误或技术故障等风险。以下是方案的关键知识点： 1....
某大型银行两地三中心容灾项目.ppt
02-21
【某大型银行两地三中心容灾项目】是一个旨在构建高效、安全、可靠的数据容灾解决方案的项目，以满足金融行业严格的法规要求和高级别的业务连续性目标。该项目由IBM实施，利用了IBM先进的虚拟化存储技术和混合MGM...
基于ssm的校园外卖配送系统（源码+文档）
luoluoal的博客
04-30 2170
校园外卖配送系统的主要使用者分为：1、用户的功能及权限用户登录注册后，进入系统对个人中心，订单信息管理，订单取消管理，配送接单管理，取消配送管理，送达通知管理等功能进行操作管理。2、配送员的功能及权限用户登录注册后，进入系统对个人中心，订单信息管理，配送接单管理，取消配送管理，送达通知管理等功能进行操作管理。3、管理员的功能及权限用户信息的添加和管理，校园外卖配送详细信息添加和管理和文档信息添加和管理以及网站信息管理，这些都是管理员的功能💕💕作者：落落。
零改造实现MySQL加密：安当TDE透明加密与KSP密钥管理系统的创新实践
www.andang.cn
04-30 1223
安当TDE透明加密系统与KSP密钥管理系统的组合，为企业提供了"免改造、高性能、全合规"的数据库加密解决方案。通过创新的三层加密引擎、智能性能优化和企业级密钥管理，成功破解了传统加密方案的技术桎梏。在数字化转型加速的今天，这种"安全-性能-成本"的完美平衡，将成为企业构建新一代数据库安全底座的核心选择。未来，随着AI和隐私计算技术的融合，数据库加密将进入智能加密新时代，而安当技术已在这条赛道上构建起坚实的技术壁垒。
ruoyi-plus Spring Boot + MyBatis 中 BaseEntity 的设计与动态查询实践
字节叔叔
05-01 455
通过在BaseEntity中引入和params，我们实现了灵活的动态查询能力，在开发中极大简化了接口参数结构与查询逻辑。同时，也提升了系统的可维护性与扩展性，是开发大型后台系统中常用的技巧之一。如果你正在构建一个基于 Spring Boot + MyBatis 的后台管理系统，不妨考虑将这两个字段纳入你的BaseEntity设计中。
C# dataGridView分页
JQLvopkk的博客
04-30 423
/ MySQL连接字符串。// 每页加载的记录数量。LoadData();// 初始化加载数据。
生产级RAG系统一些经验总结
yanqianglifei的专栏
05-01 994
可能需要修剪或总结它们。一种常见方法是先检索，然后运行较小的语言模型或启发式算法，将每个检索到的文档总结为一段话，然后将这些摘要输入最终的语言模型。这有时被称为上下文压缩或自适应上下文。LlamaIndex等工具可以自动执行第二阶段，使用语言模型在最终答案之前将初始检索集压缩成更短的形式。仅在绝对需要时使用此方法，因为任何摘要都是额外的生成步骤，可能会引入自己的错误。随着2025年16k+标记模型的出现，如果适合，许多RAG系统尝试只提供原始文本，因为这保留了最大的细节。
​Spring + Shiro 整合的核心要点及详细实现说明
最新发布
zwh1zwh的博客
05-06 421
Autowired// 授权逻辑：获取用户权限信息@Override// 添加角色和权限（从数据库查询）// 认证逻辑：验证用户身份@Overridethrow new UnknownAccountException("用户不存在");ByteSource.Util.bytes(user.getSalt()), // 使用盐值加密getName()​优势​：Shiro 轻量易用，与 Spring 整合后可通过注解快速实现细粒度权限控制，适合中小型项目。​适用场景。
关于Python：7. Python数据库操作
Triste__chengxi的博客
05-03 1556
简化数据库操作：SQLAlchemy ORM 提供了高层次的接口来简化数据库的操作，我们可以通过 Python 类来表示数据库表，进行增删改查，避免了手写 SQL 语句。支持复杂查询：SQLAlchemy 支持排序、聚合、联接查询等复杂数据库操作，同时可以自动生成对应的 SQL 语句。跨数据库兼容性：通过 SQLAlchemy，你可以很容易地将项目从一个数据库迁移到另一个数据库（比如从 SQLite 到 MySQL、PostgreSQL）。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值