四、数据库复制技术数据恢复的痛点
【核心议题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。如果本地灾备,同步复制的居多,如果异地灾备,采用异步复制的居多。当然如果带宽和数据量的实际情况,也有其他情况。同步方式,需要留意,一旦复制出现问题,是否会对生产业务产生影响。通常异步方式,对生产业务影响比较小。
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。