HADR最佳实践_new详解.doc

DB2 HADR最佳实践 DB2 High Availability Disaster Recovery (HADR) 是一个简单易用的数据复制特性，该特性为局部和全面站点故障提供一个高可用性（HA）解决方案。本文就设置和维护您的 HADR 环境提供了一些推荐方法，以帮助您在 HADR 提供的保护与性能和成本之间找到平衡点。 摘要 DB2 High Availability Disaster Recovery (HADR) 是一个简单易用的数据复制特性，该特性为局部和全面站点故障提供一个高可用性（HA）解决方案。 但是，由于用户的需求千差万别，因此不存在绝对理想的 HADR 配置。您的 HADR 环境设置、调优和维护决策通常是权衡利弊的结果。比如，您可能需要在数据库可用性要求和防止数据丢失之间进行权衡。好消息是，进行权衡并不一定意味着需要以牺牲某项需求为代价。 本文就设置和维护您的 HADR 环境提供了一些推荐方法，以帮助您在 HADR 提供的保护与性能和成本之间找到平衡点。本文重点关注以下领域： 为快速故障转移设置系统 调优参数以改进网络性能 调优参数以最小化 HADR 相关日志记录对性能的影响 在 HADR 环境中选择适当的表重组方法和负载操作 HADR 简介 HADR 从一个源数据库（称为主数据库）向一个目标数据库（称为备用数据库）复制数据更改。由于这是一个无共享架构，每个数据库都使用自己的存储器。HADR 在主数据库失败时提供快速故障转移。您还可以在实施更新和实施维护等场景中便捷地转换主数据库和备用数据库的角色，从而将停机时间减至最小。HADR 用途广泛，并被完全集成到 DB2 数据库，不需要任何特殊硬件和软件，使用标准 TCP 接口连接主数据库和备用数据库，其设置只需几个数据库配置参数。 HADR 的一个核心原则是：数据库的性能和可用性不能被某些挑战所影响，比如工作负载的突然波动（这影响备用数据库上的日志重放活动量）和服务器或网络失败（这将导致故障转移）。 为实现最优性能而调优您的 HADR 解决方案应该遵循一些基本原则，以避免一段时间后出现的潜在问题。另外，您需要了解几个涉及您的数据库维护行为的 HADR 设置项目。这个最佳实践文档将解决这些问题。本文着眼于为您设计 HADR 基础设施和配置数据库提供指南和推荐方法，从而改进 HADR 相关性能，特别是日志记录和故障转移速度。 设置您的系统 执行基础设施分析 在开始您的 HADR 实现之前，首先需要分析将要使用的系统的状况，这个步骤很关键。基础设施中的每个组件（比如服务器、存储器、网络和软件）都需要进行检查，以便发现潜在的故障点。如果可能，推荐构建备用组件（例如两个网络适配器、备用服务器电源）。分析行为的步骤之一是构建一个类似于表 1 所示的 HADR 示例分析图表，描述主地址和备用地址（如果适用）上的每个组件故障和在发生故障时的预期行为的细节。 表 1. HADR 分析图表示例 主地址 失败地址 失败描述 预期结果 停用影响 Site A Site A 例如，AIX Tivoli Systems 所有正在运行的 服务器失败 Automation 在 5 秒内探测到 Site A 的失败并引发 Site B 上的 HADR 强制接管 事务将回滚，备用服务器接管并在 30 秒内对事务开放 在完成 HADR 设置的实现后，使用 HADR 分析图表创建一个测试计划以验证该实现和时间预期，从而确保高可用性和数据恢复业务要求能够得到满足（或有效预期能够得以设置）。 设置 HADR 的要求 设置 HADR 有下面几个要求： 主数据库和备用数据库上的操作系统与 DB2 版本和级别必须相同。惟一的例外发生在执行滚动更新时。 用于主数据库和备用数据库的 DB2 软件的位大小必须相同。 一个 TCP/IP 接口必须在 HADR 主数据库和备用数据库之间可用。 主数据库和备用数据库必须拥有相同的数据库名。 主数据库和备用数据库的表空间必须相同。 除这些要求之外，还有几个推荐方法可用于设置您的 HADR 系统。 为数据库日志使用高性能专用磁盘或文件系统 由于数据库更改由 EE（HADR 在 EEE 上不可用）中的单个日志流记录，这个流可能成为系统瓶颈。在日志文件系统上拥有 I/O 保障能力很重要。不要在日志文件系统和表空间文件系统之间共享设备。 使主数据库和备用数据库都能访问归档日志 使主数据库和备用数据库都能访问归档日志有以下几个好处： 主数据库是归档日志的惟一数据库，但是备用数据库接管后，新的主数据库（原来的备用数据库）开始归档日志。因此，最简单的办法是使所有日志归档到相同的位置。如果归档设备不共享，经过几次角色替换后，有些文件将位于一个设备