赵海
作者赵海2017-09-28 09:40
技术经理, 大连

数据库容灾复制技术在银行核心系统中的实施探讨

字数 10524阅读 4407评论 1赞 17

对于容灾技术来讲,可能从数据库和存储层面会有很多中架构和技术类型。
每一种架构和技术可能都会有其利弊,同时随着数据库容灾技术的不断发展和优化,一些新的功能也会逐渐诞生。
作为企业的IT规划者、设计者以及实施者来讲,如何能规划好整体的数据库容灾架构以及在实施过程中把握好每一个实践点是非常重要的事情。
一些不注意的坑可能会导致我们今后的重大故障隐患,
一些不注意的细节可能会导致我们日后大量的补救变更,
一些不起眼的设计细节可能会导致我们的整体架构失去充分的灵活性等等。

通过本篇文章,大家对数据库复制技术在容灾场合中的应用和实践有很多新的观点和认识。
一些关键性的问题得到进一步清晰和明了,为大家在容灾工作中的策略选择和配置以及运维过程中的关注角度提供了详细参考。

一、关于容灾架构的建设方案和建设步骤,很多人对实现Oracle Extended Rac 以及 Oracle ADG 的具体建设方案和步骤很感兴趣,希望得到相关的参考。

【探讨及解答】

Oracle Extended Rac 的搭建,本次目前所知的两种方法:

  1. 底层存储经过虚拟化之后形成的虚拟卷提供给ASM使用。这种方式一般是经过了存储的整合,例如VPLEX是将不同数据中心的物理存储卷经过Metro集群之后形成了一个虚拟分布式共享卷。SVC和NETAPP的MCC都属于将双中心的物理存储卷进行HA整合之后形成一个虚拟的共享卷。如果是这种方式的存储来支撑ASM,那么Oracle这边对于存储似乎没有太多可以规划的地方,只需要把虚拟共享卷看成了普通的本地共享卷就可以。
  1. 底层存储没有经过任何整合。完全是靠ASM本身的冗余机制来实现跨中心的ASM存储卷高可用。这种方式的ASM磁盘会有两个镜像分别落在两个数据中心的物理存储上,镜像之间的切换,故障恢复等完全依靠ASM固有机制。

相比而言,第一种方式实现的代价相对要高一些,对存储的兼容性以及硬件标准等要求等比较高。整体架构的复杂性会更高。第二种方式实现的代价相对较低,整体架构复杂度也较低,但是对数据库层面的参数优化以及架构规划的要求会是非常高。但是无论哪种方案,最重要的是双中心之间的链路稳定性和延时指标。

至于具体的方案文档,可以参考网站中文档:

http://www.talkwithtrend.com/Question/404863

Oracle ADG 的搭建,经过对详细方案的摘取和精简,形成步骤文档:

http://www.talkwithtrend.com/Question/405019

二、关于容灾架构,对于Oracle Extended Rac 和 Oracle ADG两种方案的优劣点,多数会员希望通过此讨论来辅助其具体决策。

【探讨及解答】

  1. Extended RAC,是基于跨远距离实现高可用的一种技术方案。这种方案本身是基于RAC衍生出来的一种技术方案。除了在ASM规划的时候要设计特殊的镜像模式,还需要有第三点仲裁磁盘的存在。其故障转移的自动化程度无疑是其优点。但是由于关系数据库本身的一致性要求,节点间的竞争导致的热点问题也随着节点距离的拉远凸显出极大的问题所在,这种极大的问题隐患在特殊的负载模式下可能带来的风险是巨大的。所以Oracle官方其实已经不再推崇这种技术方案。
  1. Oracle DG,是在容灾观点触发之下,基于日志的复制技术基础之上诞生的一种容灾技术方案。它所强调的是在对主数据中心影响最小的情况下实现的一种保障RPO和RTO的技术方案。它的优点就在于其安全性上,另外一点就是与其他的双活技术方案比起来的简单性。其劣势就在于故障切换的复杂性,一个是时间的复杂度一个是切换本身的复杂度。

两种方案虽然都可以利用在城域范围内的容灾场合,但是各有优劣。从运维角度来讲,Extended Rac虽然少了故障切换场合下的复杂性,但是由于其相对复杂的环境需求(网络二层打通,存储访问存在着Local和Metro的差异等),给运维带来的相对工作量和复杂性也不会少。Oracle ADG虽然不需要复杂的网络环境和存储环境,但是故障切换和日常监控的复杂性也会相对较高,对人员的素质、容灾体系和标准建设要求较高。

决定适用那种容灾技术,最主要的看需要的灾备等级,是应用级,还是就是一个灾备,其次要看数据量,根据数据量大小决定那种方式,再其次要看现有的,或者公司能承担的网络硬件设备配置,根绝这三个因素最后决定用那种方式,是实时数据,一部数据,同城还是异地。总之,现在的互联网高速发展,不要被某种方案限定思维,也可以多种方案联合使用。

对于容灾来讲,RPO&RTO的要求在不同的行业可能会有不同的要求。金融行业要求相对苛刻一些,但是也没有要求RPO=0,RTO=0。这个是一个绝对的理论值,显示场景不可能绝对达到。假设在容灾指标容许的范围之内,对主库安全的模式还是最大性能模式,次之为最大可用,再次最大保护。对于一个业务类型,如果最大性能模式和最大可用模式之间对性能的损耗程度差异不是很大的情况下,那么选择最大可用。如果性能差异很大,那么建议选择最大性能。对于一个业务类型,如果它的负载很小,对性能要求不敏感,对业务中断也是可以一定程度上容忍,但是对数据的安全性保障非常高,那么可以选择最大保护。但是也得结合具体的网络环境的稳定性和带宽等条件去考虑这个问题。

三、基于数据库复制技术实现的容灾架构,如何把握其中的关键点,如何才能解决其中的一些难点。这也是大家普遍比较关注的一系列问题。

【探讨及解答】

3.1 关于Oracle ADG 的三种复制策略选择?

就ORACLE而言,DG有三种保护模式,根据配置可以达到你的要求的复制模式(绝对同步、近似同步、异步等)。至于需要哪一种,首先考虑是对主库的影响,这个很关键,三种模式对主库的压力是不同的,可配置的选择组合比较多,然后是业务的需求,架构结构的规划也很关键,很多情况会存在一对多,级联的情况,这部分需要考虑同步延迟的情况,当然这部分网络资源,系统资源影响也比较大。你说的业务压力测试,也不是不可以,不过从容灾的角度而言,首先是容灾切换后数据同步的的情况,然后是切换后是否可以不影响业务,这部分的业务一部分是性能,一部分是数据的正确性,这部分的测试,压测是很难压出来的,至于选择,只能说,要看你达到什么样的RPO/RTO要求,这部分的会占比较大的成本。

对于容灾来讲,RPO&RTO的要求在不同的行业可能会有不同的要求。金融行业要求相对苛刻一些,但是也没有要求RPO=0,RTO=0。这个是一个绝对的理论值,显示场景不可能绝对达到。假设在容灾指标容许的范围之内,对主库安全的模式还是最大性能模式,次之为最大可用,再次最大保护。对于一个业务类型,如果最大性能模式和最大可用模式之间对性能的损耗程度差异不是很大的情况下,那么选择最大可用。如果性能差异很大,那么建议选择最大性能。对于一个业务类型,如果它的负载很小,对性能要求不敏感,对业务中断也是可以一定程度上容忍,但是对数据的安全性保障非常高,那么可以选择最大保护。但是也得结合具体的网络环境的稳定性和带宽等条件去考虑这个问题。

3.2 关于Oracle ADG 的参数优化?

关键参数及策略:
1 保护模式,ORACLE有上保护模式,分别是最大保护,最大可用,和最大性能。一般情况下选择最大可用模式。
2 在具体传送参数中,一般选择LGWR进程直接写日志,而不是等待日志写满,发生了归档的时候传。
3 LGWR 一般会选择异步参数,这样的话,不会影响主库LGWR写的性能。

其他参数:

*.log_archive_dest_state_1=enable

//控制相关归档路径是否生效;

*.log_archive_dest_state_2=enable

//控制相关归档路径是否生效;

*.log_archive_max_processes=10

//归档进程数量;

db_file_name_convert='/u01/app/oracle/oradata/orcl','/u01/app/oracle/oradata/orcldg'
*.log_file_name_convert='/u01/app/oracle/oradata/orcl','/u01/app/oracle/oradata/orcldg'

//当备库和主库文件不同,彼此切换主备的时候使用该参数转换;

*.fal_server=orcl
*.fal_client=orcldg

//用于管理归档中断,FAL(fetch archive log),响应传输归档的库;

*.standby_file_management=auto

//如果主库数据文件发生某些修改,是否自动同步到备库;

3.3 关于HADR的难点和关键点解析?

<一>
关键点主要有以下:
1、主备端资源和用户配置的一致性,如用户属组,密码策略,services,hosts,db2set等等环境参数。
2、备端恢复结束时应处于rollfoward状态。
3、配置hadr相关的参数,选择合适的同步方式。
4、启动顺序,先起备端为standby,再起主端primary。
5、没有网络均衡器的,需配置alternate server.

难点:
1、根据两地之间的距离,选择合适的同步方式。建议通过网络模拟器进行测试。
2、备端最大程度的不影响主端交易,因此相关的peer_wait_limit等一些参数,需要经过测试验证。找到合适的参数组合。

<二>
主要的关键点还是在于两个DB2 HADR节点配置的一致性和规范性,无论是操作系统的用户、密码、组、文件系统权限等还是数据库实例的配置参数和DB2SET参数都要求一致,至于数据库都是在搭建HADR过程中,通过主库备份恢复至备库的,问题不大,其他规范和单DB2节点还是类似的;另外对于两个节点的通讯的质量和DB2 HADR超时时间参数的设置、同步方式的选择也是关键点。如何根据自己的真实需求,转换为切合实际的配置是关键点。

难点的话,主要还是如何解决DB2 HADR中不记事物日志的同步复制,比如一些大的LOB或者XML字段,或者不记日志的操作,比如LOAD等,这些不记日志的操作,不会同步至HADR备端,如何协调应用开发部门解决该问题,制定专门的应用规范也是个难点。

3.4 关于Oracle ADG 的日常运维关键检查工具?

1.1 实例状态

SET LINESIZE 1000 PAGESIZE 1000
COLUMN INSTANCE_NAME FORMAT A20
COLUMN VERSION FORMAT A20
COLUMN STATUS FORMAT A20
COLUMN DATABASE_STATUS FORMAT A20

select instance_name,
       version ,
       status ,
       database_status 
  from v$instance;" 

1.2 主备库状态

SET LINESIZE 1000 PAGESIZE 1000
COLUMN NAME FORMAT A10
COLUMN OPEN_MODE FORMAT A20
select name,
       log_mode,
       open_mode 
  from v$database;"     

1.3 控制文件状态

SET LINESIZE 1000 PAGESIZE 1000
COLUMN STATUS FORMAT A10
COLUMN NAME FORMAT A55
select status,
       name 
  from v$controlfile;"

1.4 日志文件状态

SET LINESIZE 1000 PAGESIZE 1000
COLUMN MEMBER FORMAT A45
COLUMN STATUS FORMAT A10
COLUMN TYPE FORMAT A10
select group#,
       status,
       type,
       member 
  from v$logfile;"  

1.5 归档目的地状态

SET LINESIZE 1000 PAGESIZE 1000
COLUMN DEST_NAME FORMAT A20
COLUMN STATUS FORMAT A10
COLUMN DATABASE_MODE FORMAT A20
COLUMN DESTINATION FORMAT A20

select dest_name,status,
       database_mode,
       destination 
  from v$archive_dest_status 
 where dest_id in ('1','2');"   

1.6 当前会话数和历史最高

select sessions_current,
       sessions_highwater 
  from v$license;"  

1.7 主库同步情况(日志号&SCN)

SET LINESIZE 1000 PAGESIZE 1000
SELECT m.thread#, 
       m.sequence#, 
       first_change#, 
       next_change#
  FROM v$log_history m,
       (SELECT thread#, max(sequence#) as sequence#
          FROM v$log_history
         GROUP BY thread#) t
 WHERE m.thread# = t.thread#
   AND m.sequence# = t.sequence#;"

1.8 备库查询没有应用的日志

SET LINESIZE 1000 PAGESIZE 1000
select sequence#,
       applied 
  from v$archived_log 
 where applied='NO';"       

1.9 备库最近应用的十个日志

SET LINESIZE 1000 PAGESIZE 1000
select * 
  from (select sequence#,
               applied 
          from v$archived_log 
         order by sequence# desc) 
 where rownum<=10;"  

四、关于灾难场合下的切换,多数会员在探讨一种科学、高效、自动化的切换方式

【探讨及解答】

4.1 关于容灾切换的自动化

Data Guard Broker 是基于分布式的管理框架,可以用来集中创建,管理,配置和监控oracle data guard; Data Guard Broker的组件:
客户端:Oracle grid control和命令行工具DGMGRL
服务端:DMON进程和配置文件
数据库版本为:企业版10G R1以上,可以是单实例或者rac环境;在主库和备库上的COMPATIBLE参数必须设定为9.2.0或更高;
必须有oracle网络支持,必须配置LOCAL_LISTENER静态监听器注册(非1521端口必须);
GLOBAL_DBNAME属性必须设定为db_uniquename_DGMGRL.db_domain;
DG_BROKER_START参数要设置为TRUE;
主库必须运行在归档模式;
使用spfile来保证broker的配置文件和服务器初始化参数文件的一致;
所有的数据库必须在mount(物理备库)或者open(主库和逻辑备库)状态;
在rac环境下还需要配置DB_BROKER_CONFIG_FILEn参数,将该参数指定共享存储上;
rac环境下,需要在OCR中要设定start_options参数为mount;

多数还是自己写脚本。例如以下link中的工具,如果想真正用好还得花些力气去优化:
http://www.talkwithtrend.com/Question/228939

还有一种方式,就是利用oracle oem 可以实现切换过程自动化。
管理实现自动化,风险性比较高。涉及到容灾决策的事情是比较复杂的事情,不是单一技术层面能够决策的了。

4.2 关于ADG的切换场合及实施步骤总结

计划内切换

(1)检查主库
select switchover_status from v$database;
SWITCHOVER_STATUS
SESSIONS ACTIVE

if [ switchover_status = "SESSIONS ACTIVE" | switchover_status = "TO STANDBY" ];
then { go to next step }
else { cancel switchover and check database }

(2)主库切为备库
alter database commit to switchover to physical standby with session shutdown;
shutdown immediate;
startup mount;

(3)检查备库
select switchover_status from v$database;

SWITCHOVER_STATUS
TO PRIMARY

if [ switchover_status = "SESSIONS ACTIVE" | switchover_status = "TO PRIMARY" ];
then { go to next step }
else { cancel switchover and check database }

(4)备库切为主库
alter database commit to switchover to PRIMARY with session shutdown;

(5)原主库恢复日志应用
alter database recover managed standby database using current logfile disconnect from session;

计划外切换

一、主备库日志没有缺口的场景

(1)备库检查日志缺口
select thread#,low_sequence#,high_sequence# from v$archive_gap;
未选定行

(2)备库停止日志接受并完成已收日志应用
alter database recover managed standby database cancel;
alter database recover managed standby database finish;

(3)检查备库状态
select switchover_status from v$database;

SWITCHOVER_STATUS
TO PRIMARY

if [ switchover_status = "SESSIONS ACTIVE" | switchover_status = "TO PRIMARY" ];
then { go to next step }
else { cancel switchover and check database }

(4)备库切为主库
alter database commit to switchover to PRIMARY with session shutdown;
alter database open;

.

二、主库可以打开到 mount 状态

(1)将主库日志刷到备库
alter system flush redo to target_db_name;

(2)备库停止日志接受并完成已收日志应用
alter database recover managed standby database cancel;
alter database recover managed standby database finish;

(3)检查备库状态
select switchover_status from v$database;

SWITCHOVER_STATUS
TO PRIMARY

if [ switchover_status = "SESSIONS ACTIVE" | switchover_status = "TO PRIMARY" ];
then { go to next step }
else { cancel switchover and check database }

(4)备库切为主库
alter database commit to switchover to PRIMARY with session shutdown;
alter database open;

.

三、主备库间日志缺口无法纠正。

(1)强制激活备库
alter database activate physical standby database;
alter database open;

五、关于MySQL复制技术以及OGG复制技术在银行业中的应用场合也是多数大家关注的问题。

【探讨及解答】

5.1. 关于Mysql复制技术的应用场合?

银行业是否适合使用MySQL,从目前的趋势而言,大部分的银行业务都是可以用到的,前提是你需要花费大量的时间修改应用,同时,由于银行业务过度耦合情况,长事务较多,由于MySQL本身的局限性或者说缺陷,这就要求,如果你改用MySQL那就要做好必要的业务拆分,而且是大量的逻辑拆分,尽可能的减少数据关联性,同时还需要从开发伊始就需要做好性能优化。还有一个问题就是,由于MySQL的复制是一个逻辑复制,不可避免的存在数据不一致的情况,这就要求我们需要经常进行数据的对比,而且大家都知道,即使是业务低峰的数据比对也是一件很消耗资源的问题,最后说下安全性问题,这块非标准而且复杂,可靠性较差。
当然前面说的是一些不足,作为最流行的开源数据库,优点也是很不错的,从5.7+开始
1.性能和可扩展性:改进 InnoDB 的可扩展性和临时表的性能,从而实现更快的网络和大数据加载等操作。
2.JSON支持:使用 MySQL 的 JSON 功能,你可以结合 NoSQL 的灵活和关系数据库的强大。
3.改进复制 以提高可用性的性能。包括多源复制,多从线程增强,在线 GTIDs,和增强的半同步复制。
4.性能模式 提供更好的视角。我们增加了许多新的监控功能,以减少空间和过载,使用新的 SYS 模式显著提高易用性。
5.安全: 我们贯彻“安全第一”的要求,许多 MySQL 5.7 新功能帮助用户保证他们数据库的安全。
6.优化: 我们重写了大部分解析器,优化器和成本模型。这提高了可维护性,可扩展性和性能。
7.GIS: MySQL 5.7 全新的功能,包括 InnoDB 空间索引,使用 Boost.Geometry,同时提高完整性和标准符合性。

5.2 关于OGG的应用场合?

1、容灾/负载分流
数据库A需要一个容灾库数据库B,当A出现不可恢复故障时,需要B进行临时访问采用GoldenGate复制将数据库A的日志捕获后投递到数据库B,对在B数据库上按全库或某个用户进行复制.当A库出现问题时,B库可以提供访问。
2、历史库建设
数据库A由于业务增长压力很大,需要一个历史库B. 实现半年前历史表数据查询到数据库B查询,而A库定期清理掉半年前旧数据。
采用GoldenGate复制可以将A库历史表的数据复制到数据库B,再设定一个用户weihui的操作将不被复制,这样用weihu用户清理掉A库历史表上无用数据将不被同步到B库,实现目的。
3、不同系统数据共享
系统B需要定期到系统A的数据库捞取最新变更的数据到自身数据库,业务高峰期经常与A库的应用争抢资源.
采用GoldenGate复制,将共享数据的几张表复制到数据库B,系统B直接访问本地表,降低A库资源开销,并且提高系统B的访问性能(本地表效率远高于远程表)。
4、数据库迁移
系统A需要迁移到新库B使用,目的,尽量减少迁移停机的时间(停写入,迁移,测试),采用GoldenGate复制,将A库数据复制到B库,开启复制并且测试新库,正式切换时,A应用基本上可以立即切换到B库使用(复制延迟亚秒级别)。
5、增量数据捕捉
系统A定期需要捞取主表中新生成或修改的数据做处理,表数量大,更新频繁,效率不高.考虑数据复制技术提取变化数据,采用GoldenGate复制,可以定义一个复制表的变化表.表增删改时会生成对应新的记录.通过变化表我们可以获取变化记录的主键,变化类型,时间等信息。
6、双向复制
有时候需要在异地存放2套数据库,数据需要共享,没有主副区别.2套库同时都在运营业务.在保证业务上可以隔离同时修改同一个记录的情况下,可以使用GoldenGate双向复制, 注意应该避免死循环,对ogg复制用户应该进行排除复制。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

17

添加新评论1 条评论

#micklej产品总监, DELLEMC
2018-05-22 11:09
RAC/ADG的选择,对每个企业来说都是头疼
Ctrl+Enter 发表

本文隶属于专栏

活动总结
活动总结是社区交流活动内容的总结及延伸,为大家提供了社区专家们丰富且高水平的理论知识、实践经验以及常见问题的最佳解决方法,非常值得大家收藏学习。

关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
© 2020  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30