DB2 V10.1 HADR 快速部署手册

关于DB2 HADR就不做多的解释,和oracle的DataGuard类似
这里记录一下平时实验的一个快速部署手册

CentOS6.5 x64位

192.168.122.101 kvm110

192.168.122.102 kvm111

目录准备

mkdir -p /home/db2inst2/db2_backup
mkdir -p /home/db2inst2/db2_archive
mkdir -p /home/db2inst2/db2_log

chmod -R 775 /home/db2inst2/db2_backup
chmod -R 775 /home/db2inst2/db2_archive
chmod -R 775 /home/db2inst2/db2_log

chown -R db2inst2:db2iadm2 /home/db2inst2/db2_backup
chown -R db2inst2:db2iadm2 /home/db2inst2/db2_archive
chown -R db2inst2:db2iadm2 /home/db2inst2/db2_log

安装db2-略

创建测试库

db2 create db hadb01

下面新增一些数据,只在主库添加:

db2 connect to hadb01
db2 “create table t1(id int)”
db2 “insert into t1 values(1)”
db2 “insert into t1 values(2)”

db2 “create table t2(id int)”
db2 “insert into t2 values(1)”
db2 “insert into t2 values(2)”

开启归档模式

主库和备库都操作

先修改归档参数,做离线备份,重启数据库后,手工测试归档

点击(此处)折叠或打开

db2 update db cfg for hadb01 using logarchmeth1 disk:/home/db2inst2/db2_archive/
db2 update db cfg for hadb01 using NEWLOGPATH /home/db2inst2/db2_log

db2 force applications all
db2 backup db hadb01 to /home/db2inst2/db2_backup/
db2stop force;db2start
db2 archive log for db hadb01

备库:

db2 update db cfg for hadb01 using logarchmeth1 disk:/home/db2inst2/db2_archive/
db2 update db cfg for hadb01 using NEWLOGPATH /home/db2inst2/db2_log

db2 force applications all
db2 backup db hadb01 to /home/db2inst2/db2_backup/
db2stop force;db2start
db2 archive log for db hadb01

主库离线全备份

db2 backup database hadb01 to /home/db2inst2/db2_backup

scp /home/db2inst2/db2_backup/hadb01.0.db2inst2.NODE0000.CATN0000.20150522091531.001 db2inst2@192.168.122.102:/home/db2inst2/db2_backup/

备库还原数据

[db2inst2@kvm111 ~]$ db2 restore database hadb01 from “/home/db2inst2/db2_backup” taken at 20150522091531 replace history file
SQL2523W Warning! Restoring to an existing database that is different from
the database on the backup image, but have matching names. The target database
will be overwritten by the backup version. The Roll-forward recovery logs
associated with the target database will be deleted.
Do you want to continue ? (y/n) y
DB20000I The RESTORE DATABASE command completed successfully.

阅读更多

读懂GPFS:从基础知识到集群搭建、参数设置优化及故障诊断(五)

当需要IBM支持的时候,IBM经常会让我们收集snap信息,具体方式如下:The command to collect GPFS Snap is “gpfs,snap” , this is very generic but very helpful.

# gpfs.snap

Note: The purpose of above command is to collect the snap on one node in the cluster,preferably the problematic one.If the cluster is experiencing problems as a whole use -a flag

# gpfs.snap -a

Note1: -a flag only recommended for smaller clusters as it collects the logs for all of the nodes in the cluster.Note2: -d option can specify the Output Directory but the default is /tmp/gpfs.snapOut.==> Another recommendation is collect an mmfsadm dump waiters/usr/lpp/mmfs/bin/mmfsadm dump waiters > gpfs.waiters/usr/lpp/mmfs/bin/mmfsadm dump all > gpfs.dump.all/usr/lpp/mmfs/bin/mmfsadm dump kthreads > gpfs.dump.kthreads==> Another file you need to check is log file /var/adm/ras/mmfs.log.latestThis information will greatly assist development in reviewing performance or problematic issues in GPFS.

在这里我们列举一下,在GPFS的日常使用过程当中,经常或者遇到最多的问题,在此提供一些故障原因或解决参考建议。

1.GPFS软件安装配置问题参考:

选择支持操作系统版本

安装必须的操作系统组件

有的编译安装需要指定操作系统版本类型

2.GPFS软件版本升级

参考:

滚动升级群集了集群节点版本,不影响正常整体使用

条件允许的话可以关闭集群统一升级

3.如何动态添加磁盘到GPFS文件系统

参考:

使用支持盘符类型,盘符大小和以前最好保持一致

编写NSD文件,使用支持的书写格式,版本不一致支持的类型不同

4.GPFS 磁盘错误

参考:

没有配置failgroup,使用mmfsck和mmchdisk ,确实不行就需要考虑备份恢复

有failgroup,如果NSD磁盘处于down状态,很多时候需要mmchdisk 或mmdelnsd 删除再从新添加修复

5.GPFS NSD Failure Group 异常

参考:

如果nsd 所在nsd filegroup 异常,需要使用mmchdisk fs_name change -d nsd_name …方法修改为正确的failgroup id

6.群集节点故障或从新安装处理

参考:

群集中节点GPFS不能修复,那么备份正常节点集群配置,修改角色信息,从集群中提出故障节点,重新安装软件,添加至群集,修改参数配置和角色。

7.GPFS网络异常以及网络调整

参考:

诊断是个别节点问题还是整体网络问题

查看OS网络和物理硬件状态

管理网络问题和数据网络问题

修改节点ip或者添加允许通讯网络

8.删除或添加GPFS群集节点

参考:

删除:协助该节点文件系统,关闭节点,集群中提出节点

添加:安装软件,配置信任,集群添加节点,授权license

9.GPFS文件系统使用异常

阅读更多

读懂GPFS:从基础知识到集群搭建、参数设置优化及故障诊断(四)

GPFS 可靠性分析与如何设计

基于上面阐述的 GPFS 可用性机制,我们可以看出 GPFS 是通过上述的三种 quorum 机制来检查资源是否超过半数状态正常来判断系统状态好坏。我们在设计 GPFS 文件系统集群的时候需要注意最好保证各种资源数都为 2N+1 个(N 是指数量),也即数量为奇数,来获得系统最大的可用性。

  • Filesystem Descriptor (FD)Quorum的设计。我们在一般的生产系统中都会使用两组不同的failure group 的磁盘来创建一个文件系统,以实现数据的冗余保护,但是丢失一个 failure group 的磁盘实际不影响数据的完整性,但是由于 FD quorum 2N+1 的机制,文件系统仍将会关闭,所以我们在创建一个 GPFS 文件系统时,可以通过增加一个很小的本地的磁盘作为第三个 failure group。以实现 2N+1 的冗余设计。本地的磁盘可以设置为只保存 GPFS 文件系统信息(FD),实际不参与数据读写。(同一个 failure group 的磁盘是指有可能同时坏掉的磁盘,比如来自同一个存储的磁盘或连在同一个适配器上的磁盘)
  • Node Quorum如果采用了 2N+1 个 Quorum Node,那么这个系统就能容忍 N 个主机节点的离线,所以如果主机节点小于 5 个采用此种方法都不是很经济,此时建议采用 Tiebreaker quorum 机制。
  • Tiebreaker quorum只能配置两个 quorum 主机,但是只要 tiebreaker 磁盘在线,只有一个 quorum 主机状态正常,系统也能正常工作,同时也意味着必须有一台 quorum 主机在线。如果是主机节点数较多的情况,采用此种机制其可靠性不如 Node quorum。

参考链接:https://www.ibm.com/developerworks/cn/aix/library/au-gpfsplan/

4.NSD设计

使用同等级别存储io或lun方面,避免短板,加宽条带化,增加并发读写能力。设置多个nsd server,设置nsd 顺序,均衡io

5.文件系统

根据以往的经验结合IBM官方建议,文件系统块大小设置可以参考以下内容:

在创建文件系统时,生产系统一般建议以下主要几个参数 -m2 -M2 -r2 -R2 ,当然根据具体需要增大某个值,其他参数并不是可以保持默认,根据情况再做适当调整。

总结:

以上这些参数的设置均不是绝对,而是结合以往历史经验参考设置,切记不可完全对号入座,根据实际情况进行适当调整。

六、故障诊断

故障诊断对于日常运维显得尤为重要,那么有一个清晰的问题处理流程,那么在问题出现时就不会过于慌乱,有条不紊进行GPFS 群集方面使用的问题。

GPFS 日常监控:

1.IBM TPC软件 支持GPFS4.1 及以后版本

  1. 使用Dstat集成GPFS的插件
  2. 基于snmp的如zabbix监控
  3. Mmpmon监控性能
  4. 使用IBM提过的监控自定义脚本诸如:getio_s.ksh,gpfs_perf.pl,netperf,collect_stats

GPFS常用的诊断工具大多还是基于本身自带的一些tools,常用的命令有:mmcluster,mmgetstate -aLs,mmlsconfig all,mmlnsd -aXv,mmchdisk ,mmlicense,mmdf,mmfsadm,mmdiag,mmrestripe,gpfs.snap 等等

下面我将结合着以往的实际经验,在问题诊断流程方面做一下梳理:

故障诊断流程:

1.网络是否正常

  1. 集群状态是否正常
  2. nsd磁盘状态是否正常
  3. 查看gpfs 日志
  4. 查看操作系统日志
  5. 具体日志报错参考手册和经验
  6. 收集故障信息给二线进行支持