DB2-HADR搭建

在新乡等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供成都做网站、成都网站制作 网站设计制作按需求定制开发,公司网站建设,企业网站建设,品牌网站建设,营销型网站建设,成都外贸网站制作,新乡网站建设费用合理。

1、系统环境搭建

系统版本：CentOS-6.7-x86_64-bin-DVD1  

1、选择 minimal

2、安装完成配置IP、主机名 （/etc/hosts  /etc/sysconfig/network  改为相同主机名）

数据库版本：v9.7fp7_linuxx64_server.tar

3、在centos-6.7系统下安装好主库 erpdb、和从库实例  

4、同步时间  ntpdate asia.pool.ntp.org  （可不做，看具体时间而定）

5、安装scp   yum install -y openssh-clients （可不做，为了传备份集而做）

以下实验以数据库devdb47为主库，devdb49为备库： 

1、备份主库

db2 backup db devdb47

2、将备份集传于从库

scp xxx(备份集) 172.16.0.49：/home/db2inst1 

3、从库还原备份集

db2 restore db devdb47

4、配置通讯端口

主从都修改

vi  /etc/service

添加 db2h_erpinst1 70000/tcp

5、主从参数配置   参数具体含义看最下解释

主库：

db2 update db cfg for devdb47 using hadr_local_host PrimaryNode-1

db2 update db cfg for devdb47 using hadr_local_svc db2h_erpinst1

db2 update db cfg for devdb47 using hadr_remote_host PrimaryNode-2

db2 update db cfg for devdb47 using hadr_remote_svc db2h_erpinst1

db2 update db cfg for devdb47 using hadr_remote_inst db2inst1

db2 update db cfg for devdb47 using logindexbuild on

db2 update db cfg for devdb47 using indexrec restart

db2 update db cfg for devdb47 using hadr_syncmode SUPERASYNC

从库：

db2 update db cfg for devdb47 using hadr_local_host PrimaryNode-2

db2 update db cfg fordevdb47 using hadr_local_svc db2h_erpinst1

db2 update db cfg for devdb47 using hadr_remote_host PrimaryNode-1

db2 update db cfg for devdb47 using hadr_remote_svc db2h_erpinst1

db2 update db cfg for devdb47 using hadr_remote_inst db2inst1

db2 update db cfg for devdb47 using logindexbuild on

db2 update db cfg for devdb47 using indexrec restart

db2 update db cfg for devdb47 using hadr_syncmode SUPERASYNC

6、注册变量配置：

主库：

db2set db2_HADR_ROS=ON 

db2set db2_STANDBY_ISO=UR

#开启备库只读

从库：

db2set db2_HADR_ROS=ON

db2set db2_STANDBY_ISO=UR

7、启动主从数据库（第一次启动，切记以后启动不在使用）：

从库：

db2start

db2 start HADR on db devdb47 as standby

主库：

db2start

db2 start HADR on db devdb47 as primary

查看hadr：

db2 get db cfg  for devdb47| grep HADR

10、最后主查看表空间，在用工具查看数据

db2 list tablespaces show detail

第一次启动以后的启动：（附关闭过程）

主（关闭过程）：

取消激活主数据库以及停止数据库devdb47  

db2 list applications all    #断开所有连接

db2 terminate 

db2 deactivate db erpdb

db2stop force

备（关闭过程）：

取消激活备用数据库及停止数据库devdb47  

db2 list applications all   #断开所有连接

db2 terminate 

db2 deactivate db erpdb

db2stop force

以上关闭完成

开始启动过程（第一次启动后的启动）：

备：

1、db2start

2、db2 activate db devdb47  # 激活数据库

3、在主服务器上，运行以下命令以验证此服务器的 HADR 角色

      db2 get snapshot for db on devdb47| grep Role

4、在各服务器上，运行以下命令以验证数据库是否已同步

      db2 get snapshot for database on devdb47| grep State

5、查看HADR状态  （此时查看的数据不同步，插入数据后查看数据同步）

      db2pd -db erpdb   -hadr 

 主：

1、db2start

2、db2 activate db devdb47

3、在主服务器上，运行以下命令以验证此服务器的 HADR 角色

      db2 get snapshot for db on devdb47| grep Role

4、在各服务器上，运行以下命令以验证数据库是否已同步

      db2 get snapshot for database on devdb47| grep State

5、查看HADR状态  （此时查看的数据不同步，插入数据后查看数据同步）

      db2pd -db erpdb   -hadr  

HADR搭建完成后需要导入表结构及其数据

1、导入导出表结构（两种方法）

目标表中导出表结构：

db2look -d devdb47 -e -a -x -i db2inst1 -w db21234 -o devdb47.sql 

导入到使用表：

db2 -tvf devdb47.sql  

由于导出的数据可能不会应用到相同的数据库，所以必须先修改devdb47.sql文件中数据库名称

vi /home/db2inst1/devdb47     将devdb47修改为目前的数据库名称

2、使用工具导出表结构 SqlDbx      后再目前数据库操作表结构

导出：

导入：

3、导出 导入表数据

导出（备份表内容）：

导出全部数据：（只导出表数据  未导出表结构）

db2move devdb47 EXPORT    

导出部分表：(含IP、dim、ods的所有表)

db2move devdb47 EXPORT -tn IP*,DIM*,ODS* -tc db2inst1 -l /home/db2inst1

导单表：

db2move devdb47 EXPORT -tn DIM_GAME_RESULT -tc db2inst1 -l /home/db2inst1/

导多表：

db2move devdb47 EXPORT -tn ODS_BAC_ROUND_RESULT_COMP,ODS_BAC_ROUND_RESULT_DETAIL -tc db2inst1 -l /home/db2inst1/game

导入（还原表内容）:

db2move devdb47  IMPORT      （较慢）

db2move devdb47 LOAD -lo INSERT -l /home/db2inst1/  （较快）

此时就将未指定generated always选项的identity列 的数据导入了数据库，但要所有数据相同还需导入指定了generated always选项的identity列。

3、恢复指定了generated always选项的identity列 需要结合identityoverride选项进行load导入

导出：db2move devdb47 EXPORT -tn ODS_ACCOUNT_BOOK_HISTORY -tc db2inst1 -l /home/db2inst1 

#可以单独在导出，也可以直接使用已经导出的数据

导入：db2 "LOAD FROM tab98.ixf OF ixf modified BY identityoverride INSERT INTO acct.ODS_ACCOUNT_BOOK_HISTORY"

# tab98.ixf 是导出的ixf备份文件

导入成功后需要手动更新目标表中的identity字段的值。以保障下次写入数据的连续性

"alter table acct.ODS_ACCOUNT_BOOK_HISTORY alter column history_id restart with 352120"

其中tab1.ixf 为备份导出的ixf格式文件    identityoverride（将数据导入到目标表中，指定使用输入文件中标识列的值） 如要生成新的标识列则何以使用identitygnore  如下：

db2 "LOAD FROM tab1.ixf OF ixf modified BYidentitygnore INSERT INTO acct.ODS_ACCOUNT_BOOK_HISTORY

4、在进行导入数据其中有序列的列需要修改序列初始值（每次导入数据之前必须查看）

db2 select prevval for SEQ.SEQ_IP_ID from sysibm.sysdummy1 

#查看序列的当前值

db2 alter sequence SEQ.SEQ_AGENT_ID restart with 5000649

#修改序列的起始值

db2 values next value for SEQ.SEQ_AGENT_ID

#序列的下一个值（执行就会到下一个值）

此时可以对主库进行操作，查看从库是否同步

SELECT max(OP_ID) FROM U_OPERATOR

查看最大值

select NEXT VALUE for MAMA.SEQ_U_OPERATOR_OP_ID from sysibm.sysdummy1 

查看下一个值

alter sequence MAMA.SEQ_U_OPERATOR_OP_ID restart with 126

修改现在起始值

=====================================================================================================

=====================================================================================================

(HADR) 复制的操作：

高可用性灾难恢复 (HADR) 使用数据库日志将数据从主数据库复制到备用数据库。在备用数据库上重放日志时，某些活动可能会导致备用数据库落后于主数据库。某些活动要进行大量记录，它们生成的大量日志文件可能会导致存储问题。虽然使用日志将数据复制到备用数据库是可用性策略的核心，但记录本身可能会对解决方案的可用性产生负面影响。合理设计维护策略，配置系统以尽可能降低日志记录的负面影响，并允许日志记录保护您的事务数据。

• 数据定义语言（DDL）  CREATE  ALTER  DROP TRUNCATE  COMMENT  RENAME   不需要commit

• 数据操作语言（DML） SELECT  INSERT  UPDATE  DELETE  MERGE  CALL  EXPLAIN PLAN LOCK TABLE  需要commit

• 缓冲池操作

• 表空间操作

• 联机重组  详细记录所有操作

• 脱机重组  通常按几百或几千个受影响的行来记录操作

• 存储过程和用户定义的函数（UDF）的元数据（但不是相关对象或库文件）

• 联机重组过程中，详细记录所有操作。结果，HADR 可以复制操作，而不会使备用数据库比它在进行更多典型数据库更新时更加远远地落在后面。但是，由于生成大量日志记录，所以此行为可能对系统产生较大影响。

  如果未如联机重组那样大量地记录脱机重组，通常按几百或几千个受影响的行来记录操作。这意味着备用数据库将落后，因为它等待每个日志记录，然后立刻重放许多更新。如果脱机重组是非集群的，那么在整个重组操作之后生成单一日志记录。此方式在最大程度上影响备用数据库与主数据库保持同步的功能。备用数据库从主数据库接收日志记录之后，将执行整个重组过程。

  HADR 不复制存储过程、UDF 对象和库文件。必须在主数据库和备用数据库中相同路径上创建文件。如果备用数据库无法找到引用的对象或库文件，那么备用数据库上的存储过程或 UDF 调用将失败

  (HADR) 不复制的操作：

  高可用性灾难恢复 (HADR) 使用数据库日志将数据从主数据库复制到备用数据库。主数据库允许不进行日志记录的操作，但不会将此类操作复制到备用数据库。如果要在备用数据库中反映未日志记录的操作（例如，对历史记录文件的更新），那么必须执行额外的步骤来实现此目的。

  以下是一些情况示例，在这些情况下，不会将主数据库上的操作复制到备用数据库：

  • 在指定了 NOT LOGGED INITIALLY 选项的情况下创建的表不会被复制。在 HADR 备用数据库接管主数据库后尝试访问这样的表将导致错误。

  • 将复制所有已进行日志记录的 LOB 列。将不会复制未进行日志记录的 LOB 列。但是，在备用数据库上将为它们分配空间，将二进制的零作为该列的值。

  • 不复制使用 UPDATE DATABASE CONFIGURATION（更新数据库配置） 和 UPDATE DATABASE MANAGER CONFIGURATION（更新数据库管理配置） 命令对数据库配置所作的更新。

  • 不复制数据库配置参数和数据库管理器配置参数。

  • 对于用户定义的函数（UDF）来说，不复制对数据库外部的对象（例如相关的对象和库文件）所作的更改。您需要通过其他方法在备用数据库上对它们进行设置。

  • 不会自动地将恢复历史记录文件（db2rhist.asc）以及对其所作的更改从主数据库复制到备用数据库。

    通过发出具有 REPLACE HISTORY FILE 选项的 RESTORE DATABASE 命令，可以将历史记录文件的原始副本（从主数据库的备份映像中获取）放到备用数据库上：

       RESTORE DB KELLY REPLACE HISTORY FILE

    初始化 HADR 并接着对主数据库执行备份活动后，备用数据库上的历史记录文件就已过期。但是，每个备份映像中都存储了历史记录文件的一个副本。通过使用以下命令从备份映像中抽取历史记录文件，可以更新备用数据库上的历史记录文件：

       RESTORE DB KELLY HISTORY FILE

    请不要使用正规操作系统命令将数据库目录中的历史记录文件从主数据库复制到备用数据库。进行复制时，如果主数据库正在更新历史记录文件，那些文件就会损坏。

    如果执行接管操作并且备用数据库有最新的历史记录文件，那么对新的主数据库执行的备份和复原操作将在历史记录文件中生成新记录，并且与原始主数据库上生成的记录完全混合。如果历史记录文件过期或者缺少条目，那么可能无法进行自动增量复原；而是，您将需要执行手动增量复原操作。

=========================================================================================================

=========================================================================================================

HADR的同步方式：

目前使用的是： SUPERASYNC （超级异步）

#db2 update db cfg for devdb47 using hadr_syncmode SUPERASYNC

1、SYNC（同步） #当日志写入到主数据库，且主收到备库应答，已经写入到备库，则成功，确保主 备同时存储

#此方式将最大可能地避免事务丢失，但使用此方式会导致事务响应时间最长，

2、NEARSYNC（接近同步）#当日志写入到主数据库，且主收到备库应答，已经写入到备库，则成功，确保主 备同时存储仅当两处同时发生故障，并且目标位置未将接收到的所有日志数据转移至非易失性存储器时，才会出现数据的丢失

此方式具有比同步方式更短的事务响应时间，但针对防止事务丢失的能力也相对较低

3、ASYNC（异步）#仅当日志记录已写入主数据库上的日志文件，而且已将这些记录传递给主系统主机的 TCP 层时，才认为日志写操作是成功的，不用等待备库的确认。

4、SUPERASYNC（超级异步）#HADR 对永远不会处于对等状态或断开连接的对等状态，一旦数据写入主 就认为是成功

具有最短的事务响应时间，但如果主系统发生故障，那么丢失事务的可能性也最大。如果您不希望事务因为网络中断或拥塞而导致阻塞或经历较长的响应时间，那么此方式很有用

HADR同步的几中状态：

当前标题：DB2-HADR搭建
标题路径：http://kswjz.com/article/pgihdp.html