e-works数字化企业网  »  文章频道  »  基础信息化  »  存储

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

2017/7/14    来源:AIX专家俱乐部    作者:佚名      
关键字:数据库  灾备  
各行各业对灾备的意识越来越高,对业务连续性的关注度越来越高。
    各行各业对灾备的意识越来越高,对业务连续性的关注度越来越高。
 
    灾备技术涉及的领域很多,有很多厂商提供了多种技术解决方案,当前比较常见的数据复制技术有几大类,例如基于传统存储的复制技术,技术数据库的复制技术,基于存储虚拟化网关的复制技术,基于主机卷管理的复制技术,基于备份的复制技术等等。
 
    在以往的讨论中,我们都是在谈某个厂商或者某个技术的优点,今天我们换个角度,我们来谈谈这些厂商产品的缺点。客观的讲每一个厂商的产品都不完美,都有他们的最佳实践应用场景,我们借分析产品的缺陷,展示产品的应用不当之处:一方面可以为广大用户提供警示作用,改进用户的使用方法或提前规避风险;另一方面可以刺激广大厂商能够不断改进产品,使得产品更加完善。
 
    由于灾备领域的技术和产品众多,我们分期来进行讨论。
 
    在前两期我们在讨论存储复制技术和连续数据保护技术。我们知道任何技术和产品都不完美,都是有其适应的场景,我们这一期的讨论主题是数据库复制技术的灾备解决方案的痛点。
 
    涉及的产品包括,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】数据库复制技术遇见非数据库数据的痛点交流探讨
 
    {问题描述}
 
    非数据库的数据不能通过数据库复制软件实现复制,那么非数据库的数据如何实现灾备保护?
 
    近年来数据种类越来越多,关系型数据库、非关系型数据库,文件系统…这些是否应当采用不同的数据复制方式?如何选择最好的技术方案?
 
    {观点总结}
 
    观点一:采用基于文件类的复制,如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操作通过触发器等方式在目标端执行。
 

责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐