db2查看是否可以降水位 db2降高水位

转载

墨香四溢 2024-03-26 07:53:15

文章标签 db2查看是否可以降水位数据库网络大数据 java 文章分类 数据仓库大数据

db2高可用

勇往直前的新世界

随着软件即服务（SaaS）的出现，越来越多的企业开始依赖通过基于Web的应用程序访问其业务数据的能力。除了SaaS和云计算的兴起，我们的业务也在全球范围内不断发展。当您可以安排在周日晚上进行维护更新时，这现在会影响全球另一端的用户。

但是，如果计划外的停机时间是这些问题的十倍。这些中断更多

对用户和广大公众可见，并对收入，品牌形象和

顾客满意度。

在本文中，我们将研究针对DB2的应用程序可用性问题的各种解决方案

数据库以及它们如何满足我们不断变化的全球运营的需求。

DB2数据库的可用性解决方案

首先让我们看一下进入市场的最新高可用性解决方案– DB2 pureScale

DB2 pureScale是一项新的可选DB2功能，它使您可以在系统中拥有多个数据库服务器，这些服务器均共享一组公用磁盘，从而提供了可伸缩性和可用性。

这项新技术包括：

•自动工作负载平衡，以确保系统中没有节点过载。 DB2实际上会将事务或连接路由到使用最少的服务器。通过拥有DB2客户端，最终用户甚至应用程序都无法看到这种工作负载平衡

处理所有工作负载平衡。客户端实际上将定期检查工作负载级别，并将事务重新路由到其他服务器。工作负载平衡可以在事务级别或连接级别进行。增加了交易支持，因为许多客户和ERP系统使用连接池，并且没有交易级支持的工作量可能永远不会转移。

•DB2 pureScale基于可用的最可靠的UNIX系统-Power Systems。将来会有其他平台可用。DB2和Power Systems在DB2 pureScale上紧密合作，以确保针对内存，网络或存储等所有级别的AIX进行优化。

•用于全局共享锁和内存的技术基于z / OS的技术，该技术在作为最可靠和可扩展的体系结构方面有着良好的记录。

•Tivoli System Automation已深入集成到DB2 pureScale中。它是作为DB2安装过程的一部分进行安装和配置的，DBA和系统管理员甚至从不知道它的存在。 DB2修订包甚至将包括并应用任何Tivoli更新，因此DBA和系统管理员无需了解其他软件产品。

•网络基础架构利用了Infiniband，并且所有附加的集群软件都作为DB2 pureScale安装的一部分包含在内。这项技术使我们避免了其他供应商遇到的许多扩展问题。

•系统的核心是共享磁盘体系结构。

市场上已有许多高可用性和灾难恢复解决方案。

主动-被动群集是本地环境中良好的通用高可用性解决方案。

它通常提供热备份解决方案-即备份检测到主服务器发生故障，然后接管备份。这种方法的主要绊脚石是它不能在很长的距离上工作，因此实际上仅适用于单个位置的解决方案。

使用主动-被动群集解决方案时，组织通常具有主动或主服务器以及被动或备用服务器。在昂贵的硬件资源闲置在备用服务器上的情况下，此解决方案的TCO可能相对较高。除了热备份服务器外，某些组织还在单独的灾难恢复站点中设置了另一个备用数据库。

服务器之间的心跳检测主服务器何时关闭，并将服务移至故障转移服务器。通常，在主服务器发生故障的情况下会发生断电，而备用服务器会检测到这种状态变化。

但是，这是欧美许多组织（尤其是银行部门）使用的解决方案。

主动-被动实现的示例是AIX HACMP，以及用于Linux Unix和Windows HADR的DB2 UDB。

IBM的HADR或High Availability Disaster Recovery for DB2来自主服务器和备用服务器的工作方式相似。

此处的区别在于，主服务器处理事务并将日志发送到备用服务器。然后备用数据库存储这些数据，并从主数据库应用日志缓冲区。虽然这会产生数据库的两个副本，但这会将客户与磁盘子系统故障隔离开来。故障转移时，备用数据库将成为新的主数据库。 HADR是一个很好的系统，已经在许多客户站点中进行了部署。但是，它仍然依赖于主动-被动数据库设置，这意味着昂贵的资源将保持空闲状态。 HACMP在操作系统级别运行，并发出心跳信号以确保服务仍然可用。

心跳信号可以通过网络，串行连接甚至共享磁盘来实现。如果被动服务器未从主动服务器接收常规心跳，它将接管服务。

服务是通过虚拟IP地址（VIPA）提供给联网请求者的，在接管处理过程中，将转移此服务。

请注意，HACMP解决方案通常使用共享的SAN解决方案，因此数据库是最新的。当心跳丢失时，主动服务器必须假定它已失去连接并开始关闭其服务，以确保可以在被动服务器上成功重新启动它们。

同样，被动服务器必须等待预定的时间，以确保主动服务器已完成关机处理。

这样，由于主服务器上的服务丢失以及辅助服务器上的服务恢复，总延迟可能是几分钟。

另请注意，接管不会在第一个丢失的心跳上发生，而通常不会发生在第三个心跳上。这是为了确保网络或服务器工作负载不会引起“错误”接管。

HADR与HACMP类似，但在数据库服务器而非操作系统中实现。

放弃了对共享SAN的依赖，主动数据库将日志缓冲区发送到被动副本以进行应用。然后，将这些缓冲区应用于被动副本，以确保其与主副本几乎保持同步。

请注意，HADR依靠自动化来影响从主服务器到从服务器的切换。

点对点群集 或2向复制允许两个或更多活动数据库服务器提供对应用程序数据的读/写访问。

数据更新通过复制解决方案以异步方式传递到复制群集的其他成员–即，事务性能不受影响，但是源服务器和目标服务器上出现的更新之间存在有限的时间。

由于没有共享锁定策略，因此该解决方案的缺点是可以在两个复制群集成员上同时更新相同的数据，从而导致数据冲突。例如，一个房间预订系统由两个人（CEO和清洁工）更新。两者都在同一时间预订房间，伦敦办公室的清洁工和爱丁堡办公室的首席执行官。 CEO的预订在爱丁堡服务器上提交，并复制到伦敦办公室，而清洁工的预订从伦敦办公室提交并复制到爱丁堡。最终应用哪个预订将取决于复制工具如何解决冲突。通常，这是最后的更新，尽管在我们的示例中这可能会导致一些危险，但是这些问题带有更多标记，例如，金融服务系统。

为了解决此问题，客户通常会在逻辑上对数据进行分区，以便在区域范围内应用更新，从而消除发生冲突的风险。在提供针对当前问题的解决方案的同时，对于具有不同服务要求的不同业务部门，此解决方案的管理可能很笨拙，并且可能难以实施区域职责的更改。

支持这种解决方案的复制工具的示例是DPROP和Informatica。

DB2 for z / OS数据共享是一个基于zSeries Parallel Sysplex技术的全活动共享内存集群解决方案。

并行sysplex耦合工具用于缓存锁定信息和缓冲的数据，从而使这些信息可用于群集的所有成员。

这是DB2高可用性解决方案的巅峰之作，另外还支持无缝容量升级以及99.999％的正常运行时间，平均故障时间为60年。

大型机技术已经将注意力集中在高可用性和零中断解决方案上已有一段时间了，并且并行综合系统，DB2数据共享和DASD镜像技术的结合已经提供了一个强大的解决方案平台。

未来的可用性

展望未来，可以肯定的是，我们对可用性的需求只会增长。停机和停电将越来越被用户接受。在这次并购中，世界各地的公司都需要结合其IT系统并与不同地点的用户一起工作。所有这些都表明对可用性解决方案的需求不断增长，这些解决方案可以覆盖不同的地区并保持应用程序对全球24/7用户的可用性。