基于ADG的数据库横向扩展技术实践

行业背景：随着业务多样化和用户规模扩大化，金融业信息系统承接的交易量呈逐年增长趋势。

　　面对的问题：要求信息系统具备可扩展性，即通过增加基础设施来应对交易增长导致资源不足的问题。

　　应对措施：数据库作为信息系统数据承载者，其可扩展能力是非常重要的。数据库扩展分为纵向扩展和横向扩展。所谓纵向扩展，是增加现有数据库实例的CPU、内存等资源；所谓横向扩展，是增加数据库实例的个数。一般单实例数据库的CPU、内存等配置存在上限，因此横向扩展比纵向扩展在获取资源方面更具优势。

　　金融业重要信息系统，其数据库应具备横向扩展能力。首先，通过横向扩展，可以将交易分散到新的数据库上，从而缓解交易增长带来的资源压力，保证重要信息系统满足业务量需求。其次，通过横向扩展，可以实现数据的多份存储，从而保证在某个数据库故障的情况下，整个系统不会出现数据丢失，达到数据高可用的目的。

ADG的工作原理

　　ADG（Active Data guard）是Oracle11g数据库自带的数据同步功能，其基本原理是将重做数据从主库传输到备库，然后在备库上应用这些重做数据，使备库与主库数据保持一致。如图1所示，主库通过日志网络服务（LSN）进程从数据库重做缓冲区获取重做数据，并将其传给备库。备库的远程文件服务（RFS）进程接收重做数据，写入备库重做日志，再使用介质恢复协调器（MRP）实现重做数据的并行恢复。因此，ADG能够保证系统数据有多个备份，对数据进行了保护，实现了数据的高可用。

　
图1   ADG工作原理

　　另外，相对于Oracle 10g之前自带的DG（Data guard）功能，ADG的优点是备库可以提供查询服务，在实际应用中可以将查询交易迁移至备库，从而降低主库的资源压力。

　　可以看出，ADG适合对查询交易量大、数据可用性要求高的系统做数据库横向扩展。

基于ADG的数据库横向扩展实践

　　作为建设银行重要的信息系统之一，客户信息管理系统存储了全行的客户信息数据，为其他数十个重要业务系统提供了统一的客户信息维护与查询服务，数据可用性要求非常高。目前，建设银行客户信息管理系统将主要的查询交易和少量的维护交易由大型主机下移至开放平台。系统建设初期，开放平台部分仅部署了一套Oracle数据库，承接的日交易量超过两亿笔，数据库的资源开销比较大，随着交易量日渐增长，数据库已无法承接未来的交易量，且数据库的资源已达到顶配，需要对数据库进行横向扩展。

　　由于开放平台部分采用Oracle数据库，主要提供查询交易，并要求数据高可用，符合ADG扩展数据库的系统条件，故采用了ADG功能完成数据库的横向扩展，如图2所示。

　
图2   客户信息开放平台系统部署方案

　　数据库采用一个主库带一个备库的部署模式，主备库之间通过ADG实现数据同步。为了避免重做数据量过大产生网络拥塞，主备库之间采用万兆网卡传输重做数据。由于维护交易涉及数据库写操作，所以联机维护服务器集群需要连接主库。联机查询服务器集群依据负载情况连接主备库，尽量做到主备库负载相似。

　　在应用层面，应用程序部署在WebLogic中间件上，通过WebLogic的多数据源机制保证应用到数据库连接的高可用。多数据源采用故障转移（Failover）模式，该模式下每个应用程序都配置主备两个数据源，在所选框中排首位的是主数据源，排次位的是备数据源。正常情况应用连接主数据源，WebLogic会按照一定的频率对主数据源进行探测，当探测到主数据源失效时，自动将应用连接至备数据源。以连接客户信息主库的应用服务器为例，主库作为主数据源，备库作为备数据源，正常情况下应用访问主库，主库不可用时，应用访问备库。

对ADG数据同步的监控实现

　　在数据库自身故障或网络故障的情况下，重做数据同步可能产生延迟，导致主备库数据不一致，备库查询不到实时的客户信息数据，因此需要对数据同步情况进行监控，并且在数据同步延迟的情况下产生告警。目前ADG自身不支持数据同步监控，需要开发监控程序。

　　监控程序实现原理如下：在主库中写入一条数据d，经过时间间隔t，至备库中查询该数据d’，如d与d’相同，则表明数据同步正常，反之则数据同步异常。当数据同步异常时，监控程序将异常信息输出到日志中，可通过告警工具对日志中异常信息捕获实现告警。

　　这里每次写入主库的内容d是不一样的，可以采用时间戳实现。t是需要满足业务层面对数据一致性要求的时间，如果业务要求数据实时或准实时同步，则建议t设置为一个较小值（如秒级）。

　　由于监控需要对数据库反复读写，为了降低其对数据库产生的资源消耗，建议监控每隔s时间实施一次。

　　在s与t之和较小时（如1分钟左右），监控可能在网络抖动的情况下产生告警，而一般网络抖动可以自动恢复。因此为弱化网络抖动对监控产生的影响，当d与d’不一致的情况连续出现n次后，再产生告警。

　　综上，发生一次监控告警的整体时间是T=n（s+t）。

应急机制

　　1.ADG数据同步延迟的应急机制。

　　在ADG数据同步延迟情况下，备库数据无法及时更新，为保证业务能够查询到最新数据，需要将备库交易切换至主库，这可以通过调整连接备库应用服务器的WebLogic多数据源顺序，将主库作为主数据源实现。调整完毕后，由于所有交易均访问主库，主库资源开销增大，需要对应用服务器进行流控以减少访问主库的交易量，避免出现主库资源耗尽的情况（如图3所示）。

　
图3   数据同步延迟的应急机制

　　2.主数据库不可用的应急机制。

　　当主数据库不可用的时候，由于配置了多数据源，连接主库的应用服务器自动将数据源故障转移至备库。此时原主库上查询交易依然可用，因为备库不能写入，所以维护交易失效。在主库长时间无法恢复的情况下，需将备库配置为ADG主库后维护交易才可成功。另外，需要通过流控限制访问备库的交易量，避免出现备库资源耗尽的情况（如图4所示）。

　
图4   主数据库不可用的应急机制

　　3.备数据库不可用的应急机制。

　　当备数据库不可用的时候，由于配置了多数据源，连接备库的应用服务器自动将数据源故障转移至主库。此时原备库上查询交易依然可用，需要通过流控限制访问主库的交易量，避免出现备库资源耗尽的情况（如图5所示）。

　
图5 备数据库不可用的应急机制

重做数据量与数据延迟的关系分析

　　对于实时或准实时系统，数据同步效率是非常重要的，在硬件环境（如CPU、内存、存储、网络）无瓶颈的情况下，我们分析了某典型交易日主备库数据延迟与重做数据量的关系，如图6所示。重做数据量依据重做归档日志量估算，主备库数据延迟由主备库SCN之差进行估算。可以看到，全天大多数时间内重做数据产生量较少，主备库数据时间延迟在5秒以内；在1:30~3:30时间段内，由于有批量数据维护操作，因此重做数据量较多，同时，主备库数据延迟在这段时间内较大，与重做数据量呈现相似的分布模式。从图6可以看出，在硬件环境无瓶颈的情况下，重做数据量的大小和数据延迟时间存在正相关性。

　
图6 数据延迟与重做数据量的关系

　　图7描述了在不同的重做数据量情况下，数据延迟时间的概率分布情况。可以看到，在重做数据量小于每分钟8GB的情况下，数据延迟小于5秒的概率大于90%，数据延迟相对较小，备库数据的实时性较好。当重做数据量大于每分钟8GB时，数据延迟增大，当重做数据量在每分钟10~12G时，数据延迟小于5秒的概率不到30%，数据延迟小于15秒的概率在60%附近。由图7可以看出，如果业务实时性要求比较高，建议每分钟产生的归档日志量在8GB以内，在设计批量维护交易时可着重考虑。

　
图7 不同重做数据量情况下数据延迟时间概率分布

（文章来源：金融电子化杂志）

扫码即可手机
阅读转发此文