数据复制技术能否杜绝逻辑错误传递问题

数据复制技术能否杜绝逻辑错误传递问题

来自twt社区同行交流，欢迎更多同行参与交流数据复制技术是否能杜绝逻辑错误传递问题？存储复制有同步异步复制技术，数据库复制中也有同步和异步技术之分。拿存储同步举例，如果生产中心的存储和同城灾备中心的存储采用同步复制技术，那么一旦生产中心的数据损坏，是不是同城灾备中心的数据也同样损坏？那么同城灾备中心可以抵御灾难风险吗？同步复制技术是不是应对灾难的场景有太多的局限性？如果同步复制技术只能保护因存储硬件损坏而带来的灾难，那么花费巨资购投入是否值得？问题来自社区会员@张鹏，下文来自twt社区众多同行实践经验分享，欢迎大家参与交流，各抒己见。*“争议”栏目内容来自同行分享的一手体验和观察，仅代表个人观点@赵海技术经理：这个要回到数据复制的原理上来看。1.基于镜像技术实现的数据复制技术（无论是基于系统层还是存储层）以及基于存储本身BlockCopy的技术实现的数据复制技术，都存在逻辑Block错误传导的问题。也就是说一旦发生存储Block错误，那么它一定会传导到备数据中心。本质上是因为这种传输机制跟IO应用没关系，识别不到IO应用层的数据，所以有些数据虽然在应用层看已经是坏掉的数据了，但是存储层完全识别不到，所以正常复制。但是，这种问题在整个数据中心容灾可防范的灾难列表里面占据的比例非常小。2.基于数据库重做日志实现的数据复制技术，不存在这种问题。因为它是应用层的复制，它复制的是数据库层做过的事务，是过程复制，不是结果复制。只要过程没错，那么结果就不会有问题。即使主中心的存储Block发生了错误，但是在灾备中心经过日志回放实现的数据结果不会受到任何影响。所以从这一点上，这种技术相对安全。3.如果是人为失误造成的数据损坏，那就是备份技术解决的问题了，不是容灾方案能解决的了（比如DBA的误操作删除了一些数据，无论哪种数据复制技术都会传导到灾备中心，容灾方案没有义务也没有能力来区分DBA的操作到底是不是失误）。@潘延晟

系统工程师：说说个人的一些理解吧。数据同步。容灾，备份都是为了保障业务安全和数据安全的。只不过是侧重点不同。按我的排序我会先重点做数据备份。。然后数据同步，同时实现异地备份。在此基础上在做异地的业务容灾。如您所说。数据复制的确不能完全避免全部情况的数据问题。而且的确投入不菲。但在我看来。在数据保护上的投入是否值得的衡量标准应该是你是否能接受数据损坏所带来的损失。因为吃过很多数据问题的亏。特别是当下社会。数据已经成为了一种新的社会资源。往往数据的丢失和损坏带来的不仅仅是业务的中断。甚至有可能会造成更严重的问题。所以如果是我。我会尽可能的去在数据保护上投入。至于是否要采用数据复制。则要看业务情况和实际的网络情况决定。而不应该由资金作为主导。@baizhaoxian万国数据服务有限公司容灾备份管理工程师：数据同步技术是容灾备份技术之一，参考的必要的条件。数据库同步技术是应用系统处理核心，不但应用系统需要向数据库进行增/删改/查操作，同样数据仓库也需要从众多的数据库中获取不同交易数据来完善自身的数据集。技术需求：越来越多实时数据查询应用使得数据库不能直接为客户带来直接查询结果，因为数据库负荷越来越重，更多的系统无法享受直接查询的结果，这样数据库同步技术就应运而生。技术指标：1--重要数据必须可以实时查询，至少到秒级别2--必须能够限制查询人员的条件3--查询系统主机和业务系统主机必须处于内外网，保证系统安全4--必须能够对需要同步的OWNER、TABLE、FIELDS进行配置和过滤，保证查询数据的安全技术路线：（具体可参考：《大数据之路》数据技术之数据同步）@cpc1989某保险公司存储工程师：首先可以明确的是，存储的数据同步复制技术确实存在着局限性，是不能防止逻辑层的故障的，包括数据库或文件系统坏块，人为误操作甚至存储自身的一些BUG导致的灾难场景，但我们也需要认识到，任何一种容灾方案都有其局限性。其次，我们要理解容灾方案的场景性，同一个容灾技术方案也会对应着不同的容灾场景。以存储同步复制技术来说，如果我们考虑的是数据冗余的场景，那么源端出现逻辑层故障，冗余端也会失去作用，这肯定是其在数据冗余方面的弱点；如果考虑的是高可用场景或者说是业务连续性场景，以存储双活为代表的数据同步复制技术是有其优势的，不管是本地还是同城双活，既避免单点风险，也简化了高可用切换过程。最后是容灾方案的投入是否值得或者说如何选择容灾方案的问题。同一种容灾方案都有其局限性和特定的适用场景，那么一个完整的容灾方案必然是多种方案的叠加。容灾技术的本质都是资源冗余，多种容灾技术叠加就意味着需要更多的资源。架构设计者都需要综合分析自身的情况下去权衡利弊，在理想方案的基础上做减法，抓大放小，优先补短板。@张鹏中国金融电子化公司-中小金融机构灾备服务中心高级技术主管：同步复制技术，不能杜绝逻辑错误传递问题，逻辑故障只能通过其他方式解决。考虑到双中心数据实时一致，为了抵御突发的数据中心灾难，同步复制还是有必要的。通过底层物理层面的复制技术，不管同步还是异步，都存在逻辑层面数据不可用的情况，建议配合逻辑层面的复制技术。@王巧雷sino-bridge系统工程师：1.如果是基于存储底层的块复制，主中心的错误会传递到备中心。由于基于存储的复制对应用来说是不透明的，这种错误可能会导致相应的应用故障。但大部分存储厂商都有自己多年的技术积累，类似io层面的写逻辑等错误，一般会在自己的存储层面解决。同步复制的逻辑错误传递，这种可能不能说没有，概率也不是很大。

如果是人为误操作的话，这种是没辙的，肯定会传递。2.数据库虽然大多都支持复制技术，但基本原理都类似。复制类型取决于带宽和数据丢失容忍度等因素。不同于存储复制，部分数据库在复制方面增加了延迟重放功能，可以在有限条件下解决误操作问题。3.复制技术需要其他技术配合才能做到万无一失，比如新型的备份技术cdp、cdm，传统的数据备份等。@王占国银行系统工程师：数据复制技术如基于底层存储复制技术，不管同步或异步一旦生产中心数据损坏，同城灾备中心的数据肯定也是不可用的。“如果同步复制技术只能保护因存储硬件损坏而带来的灾难，那么花费巨资购投入是否值得？”这个问题我觉着，存储同步复制技术解决了数据中心单点及高可用的问题，同时减少了主备中心存储故障切换时间，这个费用也算是“值得”。此外不管是存储同步复制还是基于数据库复制都不是万能的，最后救命的都是最传统的数据备份系统，建立可靠的数据保护体系，备份系统+同城+异地。@bryan金融研发软件架构设计师：楼主的分类是以应用架构分层角度看，还有一种分类方法是物理复制和逻辑复制（比如日志同步的CDC）。数据同步时，可以采用逻辑校验的模式，如果生产中心数据损坏，在读取块时可以检查逻辑错误，不会产生坏快。同步复制技术如果在同城复制，无法解决城市级故障，如果采用银行业的两地三中心灾备模式，在业务高峰期可能存在异地复制的延迟，这些都可以通过RTO和RPO的参数指标进行解决。是否值得取决于投入和产出比、对数据重要性的重视度。@张文正dcits系统工程师：简单说一下吧，同步和异步复制都是实现容灾的核心技术，可以实现数据的远程复制和灾难恢复。同步远程复制：数据实时同步，保证数据的一致性，最大限度的减少了灾难发生时数据的丢失量；异步远程复制：数据周期性同步，最大限度减少由于数据远程传输的时延而造成的业务性能下降。同步复制实际上是一个双写的过程，数据写入源lun和目标lun后才返回成功；异步是周