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

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

2017/7/14    来源:AIX专家俱乐部    作者:佚名      
关键字:数据库  灾备  
各行各业对灾备的意识越来越高,对业务连续性的关注度越来越高。

    观点二:
 
    谈到数据一致性,总体来说,要看各厂商数据库复制软件在一致性保证措施。如果是强制同步模式,可以严格保证。
 
    观点三:
 
    谈到基于数据库复制技术的应用场景下,是否会对生产有影响,如果是使用基于数据库的灾备复制技术,对生产库性能是有影响的。
 
    以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工具实现,数据库复制技术在这种情况下作为数据迁移的工具。历史归档同时还要关注两点,一就是归档后,源数据库的数据如何清理,二是,数据归档到历史库后,未来如何进行历史库管理。
 

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