zp_ccc
作者zp_ccc2017-05-04 10:17
高级技术主管, 国内某金融科技公司

灾备难点攻克系列之数据库复制技术的痛点分析

字数 12055阅读 5631评论 1赞 4

  各行各业对灾备的意识越来越高,对业务连续性的关注度越来越高。

  灾备技术涉及的领域很多,有很多厂商提供了多种技术解决方案,当前比较常见的数据复制技术有几大类,例如基于传统存储的复制技术,技术数据库的复制技术,基于存储虚拟化网关的复制技术,基于主机卷管理的复制技术,基于备份的复制技术等等。

  在以往的讨论中,我们都是在谈某个厂商或者某个技术的优点,今天我们换个角度,我们来谈谈这些厂商产品的缺点。客观的讲每一个厂商的产品都不完美,都有他们的最佳实践应用场景,我们借分析产品的缺陷,展示产品的应用不当之处:一方面可以为广大用户提供警示作用,改进用户的使用方法或提前规避风险;另一方面可以刺激广大厂商能够不断改进产品,使得产品更加完善。

  由于灾备领域的技术和产品众多,我们分期来进行讨论。

  在前两期我们在讨论存储复制技术和连续数据保护技术。我们知道任何技术和产品都不完美,都是有其适应的场景,我们这一期的讨论主题是数据库复制技术的灾备解决方案的痛点。

  涉及的产品包括,IBM DB2 HADR,IBM InfoSphere Change Data Capture,Oracle Dataguard,Oracle golden Gate, DSG RealSync等等众多产品。

  下面我就对本期的主题“数据库复制术在灾备领域应用的痛点分析”相关的问题和观点加以梳理和总结,如有疏漏不妥之处,还请不吝赐教。

  首先先简单介绍一下什么是数据库复制技术,数据库复制技术是一种对企业数据库进行复制的技术。数据库复制技术一般满足如下特性:

1、数据必须实时:如果不是实时,那只能叫数据库迁移,属于数据仓库ETL的范畴
2、数据必须准确:对复制过去的数据必须经得起验证,保证数据准确无误
3、数据必须可在线查询:如何知道数据复制过去了,必须提供查询手段保证实时在线查询
4、数据复制独立性:数据库复制软件不能安装在主库,特别是不能在主库上进行编译,否则对主库的应用系统将产生不可估量的影响
5、数据复制配置简单:这里面的指标包含不停机初始化、数据库表过滤机制、数据库用户过滤机制,这些都需要简单配置可用
6、数据复制便于监控:必须提供数据复制的过程监控机制,保证数据复制监控实时性,保证对数据复制过程及更改数据的可审计方式

  数据库复制技术多数采用Change Data Capture技术,即可以通过数据库提供的API也可以通过分析数据库在线或归档日志,来进行变化数据的捕获,然后进行传输和装载完成数据库的实时复制。

  关于数据库复制技术的痛点,大家主要关心如下几个方面。

  1. 数据库复制技术遇见非数据库数据的痛点
  2. 数据库复制技术中数据验证方面的痛点。
  3. 数据库复制技术应用场景中遇见的痛点。
  4. 数据库复制技术数据恢复的痛点
  5. 多种灾备技术混合使用时兼容性的痛点
  6. 双活数据中心架构中数据库复制技术的痛点
  7. 两地三中心灾备架构中数据库复制技术的痛点

一、数据库复制技术遇见非数据库数据的痛点

【议题1】数据库复制技术遇见非数据库数据的痛点交流探讨

{问题描述}

  非数据库的数据不能通过数据库复制软件实现复制,那么非数据库的数据如何实现灾备保护?

  近年来数据种类越来越多,关系型数据库、非关系型数据库,文件系统…这些是否应当采用不同的数据复制方式?如何选择最好的技术方案?

{观点总结}

观点一:采用基于文件类的复制,如rsync。需注意数据关联时序性。

观点二:可以通过备份恢复的方式,或者使用同步软件进行同步,也可以利用存储基本的复制技术,重点应该是这些通过过去的文件和同步过去的数据库之前的匹配性问题。比如说一些非结构化的大对象数据,数据库中还有这些文件的索引,就需要做额外处理了

观点三:
不同类型的数据需采用不同的复制技术。文件系统类型的,可以使用底层存储级别的复制,关系数据库可以用数据库自身的复制特性进行复制。

观点四:
首先是备份分级,管理员得明确那些数据是最重要的一定要百分之百保护的,那些是可以忍受数据丢失的部分。这样可以有针对性,既省钱又效率高。如果预算够上硬件级别的复制产品速度快质量有保证。成熟的产品有EMC timefinder,EMC SRDF等等,软件层面可以使用LUN mirror技术。

观点综述:

  数据库复制技术,只能针对数据库的数据进行操作,非数据库的数据只能通过其他灾备技术进行灾备保护。大部分客户的核心业务都是数据库数据,那么基本通过数据库复制技术能够满足灾备需求。其他类型的数据可以通过存储,备份等相关技术进行灾备保护。对于不频繁变更的数据,可以采用定期备份的方式进行灾备保护。

  另外需要留意的,生产中心的数据变更,灾备中心同时需要及时进行变更,在管理制度上需要加强。比较成熟的数据库产品,都有对应的灾备解决方案,提到非关系型数据库,举个例子,例如mongoDB 就有副本集的概念,实现主从复制,灾备,故障自动转移。

二、数据库复制技术中数据验证方面的痛点

【核心议题2】数据库复制技术中数据验证方面的痛点交流探讨

{问题描述}

关于这个话题有一些相关子问题,如下所示。

问题一:数据库复制技术如何保障源端和目标端的数据一致性,通过什么工具和技术能够进行数据验证?

问题二:全库比对的数据验证方式,耗时长,实际环境中如何解决?

问题三:一般通过什么测试手段或机制,保证数据复制的安全和准确的?

问题四:数据库复制过程中一般有哪些因素影响数据的准确性和实时效率?

问题五:基于数据库层面的复制技术,在灾备端进行有效验证和演练的方式有哪些?

问题六:数据库复制技术的“复制数据”覆盖面:通常数据库复制技术是基于数据库日志的方式,从事务层,保证了数据复制的一致性,但有些事务根本不记日志,或者数据本身就是非结构化数据,无法记日志。这种有没有办法从事务层保证的灾备数据一致性?还是只能从存储块或者文件页的层次来保证一致性?

{观点总结}

观点一:
  
  这部分工作应该分两个方面吧:

  第一个是技术角度,单纯的数据验证,如果已实施的灾备方案中,使用的产品自带校验当然是最好的了,比如说Oracle goldengate的veridata。

  第二个应该是日常管理方面,需要有严格的管理制度,定期进行灾备演练。

观点二:实际应用场景中,验证数据的准确性的同时可以想想有什么方法可以把灾备库用起来,给数据仓库抽数是一个比较理想的手段,既不占用生产库资源,又可以有效利用灾备系统资源,同时也可以起到验证数据有效性的作用。

观点三:数据复制模式的不同,对生产性能的影响也不同。数据复制过程中影响生产性能主要是复制的同步模式,同步复制对性能影响较大,但是保证数据不丢失,异步复制对性能影响小,但可能丢失一定数据。

观点四:定期的灾备演练是验证数据,检验灾备系统可用性的主要手段。可以通过定期的计划性切换演练,将数据库切换至灾备端运行,确认工作正常,然后切回生产端,拉起目标端库进行业务测试验证,测试后需回写或重新同步。也可以通过一系列模拟演练,采用快照、闪回或在测试环境恢复数据进行验证。

观点五:提到如何保证灾备数据的一致性,主要通过验证或数据库检查工具进行检验。

观点综述:

  准确性,有几个方面,一个是数据从源端抽取是否准确,一个是数据在网络中传输是否准确,还有一个是数据在目标端装载是否按照正确的事务逻辑,装载正确的数据。

  灾备解决方案中,数据的一致性和完整性一直是重中之重。那么如何确保灾备中心的数据和生产中心一致,并且在灾难的时候可用呢。这给灾备系统运维提出了较高的要求。在灾备系统运维过程中要经常的进行数据验证,并且要定期进行灾难恢复演练。数据验证可以通过相关的比对工具对源库和目标库的数据进行验证。

  最可靠的方式是做全库比对,当然所需的时间以及所消耗的资源开销也是巨大的。通常采用进行主要数据的比对,例如通过对特定表的数据验证,对特定表的数据统计等等操作。

  实际应用场景中,不管是数据库复制技术还是存储复制技术,灾备端数据的定期验证都是有必要的。如果采用的某个数据库复制技术产品,在目标端数据库处于打开状态,可以随时进行查询,比对验证。如果某些产品,平时在目标端数据库无法读写,只有在灾难发生时,通过故障转移后,才可以访问数据库,那就只能通过演练的方式进行定期验证。

  关于实时效率的影响主要看复制的模式以及数据量和网络带宽。的确数据库复制技术不管是通过数据库管理软件自带的API还是通过分析日志,多数采用的技术都是CDC技术,即对日志进行分析和处理,那么对于一些不记录在日志中的信息,例如包括事务级和会话级的临时表( Temporary Table)数据不能同步;任何没有记入归档日志的DML语句无法同步;例如选择了no logging的table,或者no logging的SQL语句。那么遇到这种情况,是需要对应用程序进行修改,避免这种情况的发生的。

  同时任何一种产品都不能完全覆盖所有应用场景,也都有一些应用场景的限制,例如一些应用中有一些特殊数据库对象类型的定义,很多复制产品也无法实现。

三、数据库复制技术应用场景中遇见的痛点

【核心议题3】数据库复制技术应用场景中遇见的痛点交流探讨

{问题描述}

问题一:哪些应用场景不适合数据库复制技术?

问题二:如果生产的数据结构不断的变更,数据库复制软件是否能保证灾备中心也能随之变化?比如:数据库中有频繁变动DDL的场景下。

问题三:数据库复制技术中的实时性如何保证?对性能要求比较敏感的环境下,数据库复制过程中,无论从网络、CPU、内存、磁盘数据读写等方面对数据库源服务器性能影响有多大?

问题四:基于Oracle Dataguard的数据库灾备复制技术,据厂商宣传,可以解决在传统存储灾备复制场景下,由于生产端数据库页面受损导致灾备端失效的问题。除该优势外,基于Oracle Dataguard的数据库灾备复制技术,与传统基于存储的灾备复制技术相比,优缺点还有哪些?

问题五:主站点宕机后,备站点起数据库如Oracle需注意(如是DB2的数据库要注意什么)?

问题六:数据库复制大家都使用了什么技术?通过什么软件实现的?欢迎大家都能分享一下,分析一下优缺点。

问题七:数据库复制技术如何应对归档数据的需求?先介绍一下场景:经过多年积累,业务数据量已经巨大,对应用性能造成了一定影响,因此公司计划将10年前的冷数据归档到专用历史库,性能提升的同时还可以降低成本。那么问题来了,使用数据库的复制技术是否适用于这样的场景?应该如何安排归档方案,才能够在不影响生产、不占用过多资源的情况下完成历史数据归档呢?

{观点总结}

观点一:

  业务逻辑要求产生大量临时中间表的场景,不适合很多数据库复制技术。数据库计算过程非常频繁,会产生大量临时中间表,运算结束后又自动删除,这种场景不适合数据库复制技术。但是也有一些产品例如sql server的always on和db2的hadr可以支持DDL操作的,或者例如oracle golden gate当捕获到DDL操作通过触发器等方式在目标端执行。

观点二:

  谈到数据一致性,总体来说,要看各厂商数据库复制软件在一致性保证措施。如果是强制同步模式,可以严格保证。

观点三:

  谈到基于数据库复制技术的应用场景下,是否会对生产有影响,如果是使用基于数据库的灾备复制技术,对生产库性能是有影响的。

以Oracle DG为例:

  DataGuard允许定义3钟数据保护模式,分别是最大保护(Maximum Protection),最大可用(Maximum Availability)和最大性能(Maximum Performance)。

  1.最大保护(Maximum Protection)这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的,它要求所有的事务在提交前其REDO不仅被写入到本地的OnlineRedologs,还要同时写入到Standby数据库的StandbyRedologs,并确认REDO数据至少在一个Standby数据库中可用(如果有多个的话),然后才会在Primary数据库上提交。如果出现了什么故障导致Standby数据库不可用的话(比如网络中断),Primary数据库会被Shutdown,以防止数据丢失。使用这种方式要求StandbyDatabase必须配置StandbyRedoLog,而PrimaryDatabase必须使用LGWR,SYNC,AFFIRM方式归档到StandbyDatabase。

  2.最高可用性(Maximumavailability)这种模式在不影响Primary数据库可用前提下,提供最高级别的数据保护策略。其实现方式与最大保护模式类似,也是要求本地事务在提交前必须至少写入一台Standby数据库的StandbyRedologs中,不过与最大保护模式不同的是,如果出现故障导致Standby数据库无法访问,Primary数据库并不会被Shutdown,而是自动转为最高性能模式,等Standby数据库恢复正常之后,Primary数据库又会自动转换成最高可用性模式。这种方式虽然会尽量避免数据丢失,但不能绝对保证数据完全一致。这种方式要求StandbyDatabase必须配置StandbyRedoLog,而PrimaryDatabase必须使用LGWR,SYNC,AFFIRM方式归档到StandbyDatabase。

  3.最高性能(Maximumperformance)缺省模式。这种模式在不影响Primary数据库性能前提下,提供最高级别的数据保护策略。事务可以随时提交,当前Primary数据库的REDO数据至少需要写入一个Standby数据库,不过这种写入可以是不同步的。如果网络条件理想的话,这种模式能够提供类似最高可用性的数据保护,而仅对Primary数据库的性能有轻微影响。这也是创建Standby数据库时,系统的默认保护模式。

观点四:

  数据库复制只能对数据库进行保护,其他如应用程序等非数据库内容需要通过其他方式来保障生产和灾备的一致性。而且如果有多套数据库,每套数据库都需要单独建立复制关系,在没有更好的自动化工具的条件下,管理维护便利性稍差。存储复制可以统一对存储上需要同步数据的卷建立复制关系,易于管理。但是对两端存储的类型和型号有要求,一般都是同厂商同系列,而且有些存储的复制可能还需要单独的license或者额外的FCIP等光电转换设备实现存储互联,建设成本比数据库复制高。

  还有一点很重要,存储复制是物理层面的复制,数据库复制是逻辑层面的复制,保护的维度不一样。条件允许可以两者结合起来。比如:在生产端,误操作将数据库的控制文件或者底层表空间文件物理删除了,这时候如果单独使用存储复制,也会将这个操作同步到灾备端,使得灾备端的数据库也不可用。而数据库逻辑复制则可以防止这种场景的发生。

观点五:

1:ORACLE DG仅仅只能复制Oracle数据库,而存储复制涵盖的区域则大很多。

2:ORACLE DG是一个完整的ORACLE数据库解决方案,而存储复制通常只是一个方案中的一个解决方式,搭配其他套件使用。

3:ORACLE DG针对ORACLE环境中应用广泛,实施快速且简单。而存储复制及对于的方案相对复杂,实施周期长
正常情况下 ORACLE DG的对比产品应该是OGG、AlwaysON、SP、DSG等数据库或者数据库第三方软件。 存储复制应该对比各大友商和对于的解决方案。。。两个东西确切的说不是一类玩意。。

观点六:

DG:带宽占用低
存储:相比DG,带宽需求量大。

观点七:

  如果是db2 hadr的话,要看同步模式是同步还是异步,如果是同步,那么不会丢失事务,如果是异步,那么会丢失事务。如果主站点宕机不可用,那么备站点需要强制拉起才可以。

观点八:

  针对数据归档的问题,可以直接通过数据泵等手段抽取冷数据,不是必须采用数据复制。数据库复制一般用在生产数据库上,历史数据保护级别不需要太高。

观点综述:

  选择灾备解决方案是要关注功能,性能,成本,运维便捷与否等等多种因素。数据库的复制技术层出不穷,也有很多成熟的产品可供选择。如果是基于硬件级别的复制技术,基于底层卷的复制无需关注上层逻辑,同时缺点是无法知道是否逻辑上发生了错误。如果是基于软件级别的复制技术,例如oracle dg或者ogg,好处是可以验证逻辑错误但速度以及性能与基于硬件的工具相比是差好多截的。

  不仅如此,管理员还要面对万一用户或者开发误删除数据这样的情况。这个情况下,所谓的连续保护措施CDP就十分有用了。但如果不想买这样的产品使用原有工具也是可以的。以下举个例子。sqlserver的always on的slave有两种情况,一种是实时同步还有一种是延时同步。如果安装数据复制分级管理的思想。管理员应该创建两个slave,第一个slave是实时同步用于数据库fail over还有一个延时同步例如延时一天同步。这样就可以满足不同需求啦。当然市面成熟产品已经有很多,选择适合的才能最大限度的保证数据。

  各种数据库对应的数据库复制产品,有不同的特点,每一种产品又有很多种运行模式,又有很多特点。例如大家讨论比较多的oracle和IBM的产品。DB2 HADR,通过追物理日志,平时备库只读,一般为了防范性能上有问题,备库读都不做。主备切换的时候,确实需要多加关注。备库的归档空间需要做好预留。主库的归档空间也要保留好,定期清理日志时,需要确保日志应用到备库。Oracle Dataguard提供了三种数据保护模式:

1.最大保护模式

1)这种模式提供了最高级别的数据保护能力;
2)要求至少一个物理备库收到重做日志后,主库的事务才能够提交;
3)主库找不到合适的备库写入时,主库会自动关闭,防止未受保护的数据出现;
4)优点:该模式可以保证备库没有数据丢失;
5)缺点:主库的自动关闭会影响到主库的可用性,同时需要备库恢复后才能提交,对网络等客观条件要求非常的高,主库的性能会因此受到非常大的冲击。

2.最大可用性模式

1)该模式提供了仅次于“最大保护模式”的数据保护能力;
2)要求至少一个物理备库收到重做日志后,主库的事务才能够提交;
3)主库找不到合适的备库写入时,主库不会关闭,而是临时降低到“最大性能模式”模式,直到问题得到处理;
4)优点:该模式可以在没有问题出现的情况下,保证备库没有数据丢失,是一种折中的方法;
5)缺点:在正常运行的过程中缺点是主库的性能受到诸多因素的影响。

3.最大性能模式

1)该模式是默认模式,可以保证主数据库的最高可用性;
2)保证主库运行过程中不受备库的影响,主库事务正常提交,不因备库的任何问题影响到主库的运行;
4)优点:避免了备库对主数据库的性能和可用性影响;
5)缺点:如果与主库提交的事务相关的恢复数据没有发送到备库,这些事务数据将被丢失,不能保证数据无损失;

每一个产品和技术都有一些使用方面的限制。下面以oracle DG来举例,说一下oracle DG的一些限制,例如:

解决高可用性和故障切换的问题

– 备库不能提供查询, 不能用于报表和数据仓库
– 在主库正常状态下,总是处于恢复模式
– 如果要使用备库, 复制必须停止
– 不能实现零宕机迁移

代码规则限制

– 仅能设置30个目标
– 必须是同平台、同OS、同数据库版本

表必须在相同的Schema下面

– DBA不能有选择性的复制
Switchover 可能要求Primary Database 重启或重新mount
不必要的停机时间
Failover 可能要求备库重启
– 不必要的停机时间
– 与RAC数据库不完全兼容
占用比较高的资源
– 通过Oracle*Net传输redo data – 网络资源占用比较高
– Massive protocol
– 没有数据压缩
failover时间比较长
– 必须等待所有日志被应用– delayed startup

  • USING CURRENT LOGFILE
    Log corruption = disaster
    – 不能倒退事务
    – 不能过滤所选择的事务
    – 有限地基于时间的恢复
    Patches/upgrades 要求停机
    不能把事务拆分、不能把SQL合并
    没有转换能力

  最后谈谈历史归档应用场景下数据库复制技术的应用。数据库复制产品通常针对灾备应用场景,历史归档可以通过ETL工具实现,数据库复制技术在这种情况下作为数据迁移的工具。历史归档同时还要关注两点,一就是归档后,源数据库的数据如何清理,二是,数据归档到历史库后,未来如何进行历史库管理。

四、数据库复制技术数据恢复的痛点

【核心议题4】数据库复制技术中数据恢复的痛点交流探讨

{问题描述}

问题一:
  如何恢复历史时间点的数据?某些数据库复制技术,日常无法进行数据恢复测试,那么如何进行数据验证?

问题二:
  由于数据库复制软件大多是基于redo log的捕捉方式,在复制过程中多数是采用异步复制模式。主站点发生灾难时,备站点数据有少量的丢失。那么实际丢失的数据有哪些类型的数据呢,RPO大概是多少?

问题三:
  数据库复制对应用级灾备RTO的影响到底有多大?首先,声明一点,数据库复制是基础中的基础,前提是能同步尽量不异步,但实际建设中呢?网络带宽、机房距离、数据库大小、业务繁忙程度等等,对数据库复制技术都提出了更为严格的要求。更为要命的是,应用级灾备建设不光只有数据库一致性保证这一环节,还有应用层面的恢复、灾备的切换、业务逻辑的调整等等,个人认为,应用级灾备系统的RTO要考虑更多的因素、更加的全面,数据库复制反而成为最容易实现的一个技术问题。

问题四:
  基于数据库层面的复制技术,如何有效规避主库逻辑错误导致将问题数据复制到灾备端?

问题五:
  数据库复制技术的“实时复制”后,数据的逻辑性保护:数据库数据复制后,数据是实时同步的,生产端的操作都会实时同步至灾备端,那么生产端误操作后,或者出现逻辑性问题后,灾备端也逻辑错误了,这样的话,目前是否有理想的数据库复制方案来保护数据?还是只能用数据库备份的方式?

{观点总结}

观点一:
  日常进行数据验证,数据查询,或者通过灾备数据进行业务处理,需要准备一个独立的环境,将数据恢复出来。

观点二:
  少量丢失主要是一部分数据库交易事务,例如增加、更改、删除的数据库行。RPO根据同步模式是同步还是异步来看,理论上同步模式RPO是0。

观点三:
  在Oracle 12c版本中增加了far sync的属性,保证主库的日志实时传输到far sync server,可极大的解决主库存储出现问题而导致数据丢失的问题,可做到主库数据的零丢失,同时又不影响主库的性能。是ADG的重大突破。在这之前的版本,现在可能也没有更好的解决办法,想看看大家有什么好的方法,可以分享出来。

观点综述:

  灾备的主要目的就是灾难发生时,可以用来恢复数据,重续业务。为了更加合理的利用资源,通过灾备系统的数据来做数据分析,或用于开发测试环境,也是很多客户现在的通常做法。回归到灾备系统的本质目的来,就是灾难发生时恢复数据,那么大家关心最多的就是灾难恢复指标RPO和RTO。工作模式的不同RPO也不同,例如同步模式下,可以实现RPO等于或约等于零,如果是异步模式下,RPO主要看复制的间隔策略,数据量,网络带宽的综合因素。

  从RTO角度上来看,很多数据库复制技术中,灾备端的数据库是处于open状态,那么在进行灾难恢复时,减少了磁盘加载,数据库打开的操作,是加快了业务恢复的时间的,相对其他一些灾备技术,RTO应该是少的。灾备数据库要能够保留多时间点副本数据,才能在发生逻辑故障的时候,例如误删除时通过多时间点的副本恢复数据。谈到历史追溯的恢复功能,当前多数数据库复制技术,灾备端都只保留一份数据,无法实现历史数据的追溯功能。可以结合其他手段来实现,例如通过数据库日志回滚技术,来实现历史数据的恢复,但是效率较低,使用起来较复杂。或者通过文件系统或存储卷的快照技术,记录历史时间点的数据。

  基于数据库备份技术的连续数据保护产品,也是一种选择。某些数据库复制技术中的灾备端数据库处于非open状态,灾备端日常不能进行数据库验证,只能通过演练,经过故障切换之后,数据库可访问,才能验证。

五、多种灾备技术混合使用时兼容性的痛点

【核心议题5】多种灾备技术混合使用时兼容性的痛点交流探讨

{问题描述}

问题一:
数据库复制技术是否支持两地三中心灾备架构?

问题二:
多种灾备技术混合环境下,数据库复制技术是否和其他技术产生冲突?

{观点总结}

观点一:
  很多产品都支持两地三中心甚至多地多中心的灾备体系架构,例如sql server always-on技术可支持两地三中心灾备架构,如果没记错的话,最多支持6个副本

观点二:
  数据库层的灾备与存储层灾备不冲突。可以一起实施。
  存储层的灾备不能替代数据库层的灾备,存储层灾备很难保证备份点的数据逻辑一致性。
  多种灾备技术互为补充,能有效提高灾难恢复能力。

观点综述:

  通常多种灾备技术的混合应用是确保灾备数据可用的有效保障。毕竟单独的灾备技术都有局限性。说道混合应用的兼容性,主要是要看产品的适用场景,例如基于存储的复制技术和基于数据库的复制技术,之间没有直接的关联,发生冲突的几率比较小。如果数据库复制技术和备份技术同时应用,就需要考虑日志的保留期限,例如备份后将要删除的日志,需要确保数据库复制技术已经对日志进行过处理,否则就会失效。

六、双活数据中心架构中数据库复制技术的痛点

【核心议题6】双活数据中心架构中数据库复制技术的痛点交流探讨

{问题描述}

问题一:
  如何通过数据库复制技术实现双活数据中心灾备?

问题二:
  通过数据库复制技术能够实现对称工作负载的双活数据中心——即数据库双中心均参与事务处理吗?

问题三:
  多中心如何避免和处理出现脑裂的情况?

问题四:
  在数据库复制解决方案场景中,如Oracle OGG,DSG realsync等,将主站点的数据库复制到灾备站点。一般情况下,主是可读写的,而备站点仅能作为查询库,实现非对称的业务双活---即主做读写,备仅承担查询业务。那么,在数据库复制软件的情况下,如何实现真的意义的双活数据中心,以实现双中心可读可写,同时承载业务?

{观点总结}

观点一:
  应用双活(纯双活),需在应用层、网络层、数据层、存储层方面都需做到双活,最难实现的也就是数据层双活了。数据层双活到目前没有太多实践案例。相对成熟技术有:Oracle extend rac; DB2 Purescale 【DB2 GDPS (大机) DB2 GDPC(开放平台)】

观点二:
  集群环境下避免脑裂通常做法是要建立仲裁机制。

观点三:
  如果真的要实现双中心读写,在数据库层面好像就只能通过oracle extended RAC,DB2 purescale了。

观点综述:
  如果是对称工作负载的双活数据中心,目前数据库复制的解决方案中,暂时没有比较好的解决方案。单纯数据库复制技术,必然有复制的源和复制的目标,那么两个数据中心的数据库都参与数据处理的这种设想,通过数据复制技术难以实现。即使是同步复制模式,业务数据也无法实现同时任意站点的数据写入。

  如果是非对称工作负载的双活数据中心,比较容易实现,双中心跑不同的业务,并且互为灾备。实际的业务还是在一个中心,实现的不是业务在双数据中心的双活,而是只提高了数据中心的利用率。双活数据中心避免脑裂,通常采用仲裁机制来实现,采用share everthing集群架构都引入仲裁技术来防止脑裂。

七、两地三中心灾备架构中数据库复制技术的痛点

【核心议题7】两地三中心灾备架构中数据库复制技术的痛点交流探讨

{问题描述}

问题一:
  两地三中心灾备架构中,生产到同城采用数据库复制技术,是否可以实现同步复制?

问题二:
  两地三中心灾备架构中,采用数据库复制技术,数据复制路径是生产到同城再到异地,还是生产到同城,生产到异地这种数据复制路径?例如两地三中心,正常应当是以主数据中心为源向同城中心和异地中心做复制,主数据中心出现故障,同城数据中心接管所有业务,并做为源向异地中心复制,那么当主数据中心和同城数据中心之间失去联系的时候,如何控制和判断才能保证业务正常?

{观点总结}

观点一:
  两地三中心灾备架构中,我们使用的数据库复制技术是采用一主多备的模式,生产到同城的数据库同步模式采用的是完全同步模式,即主备库同时写,而到异地由于链路质量问题,我们使用异步模式,即主库事物提交成功后,再提交至备库。同时,在同城备份中心的备库,也配置了备机可读机制。

观点二:
  两地三中心架构中,实现本地、同城数据同步复制产品有很多,基于存储复制的灾备解决方案通用的数据复制路径,都是生产到同城,同城再到异地。

观点三:
  文中提到的灾难接管,大部分灾难发生后,灾备中心接管业务,是要有人员参与的,启动化的切换,只在特定场景下实现。

观点综述:

  很多数据库复制技术的产品,都支持一对多的架构和级联架构,可以比较灵活的支持生产到同城再到异地,以及生产到同城和生产到异地等等多种架构。通常从建设标准,资源配比,人员能力等综合角度考虑,生产到同城再到异地这种两地三中心架构比较符合真实灾难发生的切换接管流程。

  数据库复制技术中有产品支持同步复制和异步复制两种复制技术,例如oracle DG。如果本地灾备,同步复制的居多,如果异地灾备,采用异步复制的居多。当然如果带宽和数据量的实际情况,也有其他情况。同步方式,需要留意,一旦复制出现问题,是否会对生产业务产生影响。通常异步方式,对生产业务影响比较小

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

4

添加新评论1 条评论

gongweizhigongweizhi系统工程师, icfcc
2017-05-04 10:37
学习一下~~
Ctrl+Enter 发表

本文隶属于专栏

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

作者其他文章

相关文章

相关问题

相关资料

X社区推广