发表一下个人见解，数据库同步和存储同步虽然说都是双中心复制的可用方案，但是从技术稳定性来说，存储的同步复制以及存储双活相比数据库的复制更为成熟，只是存储的复制在切换时，切换操作要复杂的多，可能导致RTO时间变得很长。在核心这样的业务系统上面来看，双中心其实最为基础的需求还是要保存一份完整的数据，因此，存储的同步是保证双中心数据完全一致的最后底线。在far sync架构下，只有在主数据中心运行该套rac的服务器存储以及运行far sync的服务器存储同时宕机的情况下，才会可能发生主备数据中心间同步数据丢失的情况，通常意义这意味着主数据中心整体掉电或者发生主数据中心的整体灾难。在这种情况下，存储的复制是仍然会保证数据的一致性的。因此，对于核心这种关键系统，还是有必要同时采取两种模式的复制的。


@bbaimm88 银行 系统架构师：

对于核心级别数据库，强烈建议多种方式保护数据，核心一致性对于全行业务极其重要，但不要仅仅局限于一致性，核心其安全性与可用性也非常重要，比如在数据不丢失情况下，发生机房级别故障，恢复时间过长，可用性大大降低，肯定不可取，又比如有删库或者破坏力的DDL、DML造成数据不可逆，其安全性也大大降低，以上两种都是致命的。

因此，你要业务连续性来考量，不要过于集中技术层面定位。既要解决数据一致性，也要解决安全性，可用性。

1、从高可用层面解决数据库高可用，数据库集群。

2、容灾保护做好数据复制（数据库级别复制，存储级别复制；同步异步都可选，根据你们机房距离来定，存储双活解决方案多， 数据库双活目前仅Extend RAC【不讨论分布式】）

3、最后一道防线 备份系统要上，很多人把数据库复制当做最后一道防线是存在误区的， 一个DDL、DML 的drop delete 一下就洗白数据。备份频率一定要高1小时至少一次以上。备份在手，不跑删库跑路【分权管理，禁止一人管理】

数据同步有多重解决方案：1存储同机房双活，异步到灾备，2 直接跨机房双活一步到位，数据库亦如此。各有难易点，根据你行系统人员与DBA人员技术贮备来定。不要道听途说。哪个实力强就选哪个。


@cpc1989 某保险公司 存储工程师：

个人看法是，几种同城双活的方案各有利弊，采用哪种方式也更多地取决于同城双活建设的目标和成本：

1.目标是同城数据中心A-A双活的情况，比如oracle Extended RAC方案中，一般也很少单独采用数据库同步模式同步数据，更多地会采用基于VPLEX Metro的Extended RAC，即底层存储同步模式来保证数据的一致。这种方式逻辑较为简单，技术也比较成熟，但成本较高，需要从各方面去评估是否具备实施双活的条件。

2.如果不追求同城数据中心A-A双活，则可以单独采用数据库同步模式或者底层存储同步模式。数据库同步模式可以采用DG等方案，底层存储同步模式可以采用存储双活或存储复制方式。这些方式成本要求不一，各有优劣，但相比于A-A双活来说，易于实施和维护，但缺点是RTO较高，需要评估核心系统切换是否满足对应的业务连续性要求。


@张鹏 中国金融电子化公司 运行部副总经理：

如果将底层存储理解为物理层的数据块同步复制，将数据库理解为逻辑层的数据块同步复制。

个人认为两种方式可以互为补充，同时采用。

存储厂商一定会强调，通过底层物理数据块的同步复制是可以保证数据一致性的，但是实际的应用环境中，确实出现过物理数据块和逻辑数据块不一致的情况。这的确是一种小概率事件。如何规避这种问题呢，简单方式是采用定期验证的方式，在灾备环境中通过快照等技术验证灾备数据是否可用，以及数据的一致性和完整性。如发现这种情况，采用全量或者增量比对，追补等方式修正异常数据块。

存储技术其实最大的好处，就是屏蔽了逻辑层事务逻辑不一致的问题，用户获得的是某一个时间点的物理磁盘状态，不用关心上层逻辑。

而采用数据库层面的复制，虽然逻辑块的故障能够及时的发现，但是需要关注的是事务的一致性。


@李松青 浪潮商用机器企业云创新中心 软件架构设计师：

个人完全同意前面专家们的说法，同城双活核心系统有必要同时采取数据库同步和存储底层同步两种模式。也还要看数据中心所具备的条件和人员技术储备情况，来选择具体方案。

1. 如果具有同城几十公里内非常稳定且带宽足够的网络条件，那可以按照一步到位的真正A-A双活、同城数据中心同时读写(Extended RAC or PureScale GDPC) 各承担一部分业务来建设。这种情况下，可以优先考虑数据库同步模式的数据库双活方案。而底层存储同步模式作为更远距离的备份容灾方案，至于是做成同步还是异步的存储级备份容灾方案，同样取决于传输延迟和带宽条件（当然这里用DG或HA/DR等数据库方案取代底层存储复制也是可行的）。当然数据库上drop table, delete数据误操作之类的逻辑错误，首先得靠制度保障，其次得依赖数据库层面的闪回技术来做为一道保障。

2. 如果同城带宽和延迟 达不到生产数据库高峰时产生日志和变化数据量需求，那应该优先选择存储底层同步技术，主生产中心负责全部业务，同城中心作为备中心随时待命 准备接管可能发生故障的生产中心。此时数据库同步技术也可以做为辅助手段（DG 或 HA/DR），多做一个数据库同步或者准同步的日志备份，万一底层存储复制技术因为数据逻辑一致性问题（出现概率低，但理论上有潜在可能），可以用作第3个应急接管预案。


@邓毓 江西农信 系统工程师：

作为银行的核心系统，我觉得完全有必要同时采取两种模式：

1、底层存储同步是块数据的物理一致性保证，保证了数据级容灾需求。但同城端的这份数据不可读不可写，要利用起来需要再对该数据卷进行快照挂载使用。

2、数据库同步模式是通过事务日志的方式再写一份日志到同城端，保证了数据的逻辑 一致性，且在同城端是可读的，这也是数据读写分离的经典方式。

3、块数据的物理一致性无法保证数据的逻辑一致性，真正面向业务的数据必须是逻辑一致性的，所以为了最大限度的保障数据安全性，有必要再做一份数据库级的同步。

4、数据库级的复制覆盖面不全，只能涉及到事务级别的数据，其他文件系统中的文件数据覆盖不了，所以这部分数据就必然要用到底层的块数据同步。

5、数据库级的复制需要消耗一定的主机性能，而且实施起来麻烦，需要停机。而底层存储复制实施比较简单，可在线实施，不消耗主机性能。