传统的存储同城复制和异步复制，各存储厂商保证切换的数据一致性方面，已经做的相当成熟，通过一致性组等技术手段实现。

为了保证数据安全，建议加入业务级的验证机制，例如登记切换前流水表行数，按时间顺序排序查询最后一笔交易，查询某些实时变动的文件的md5值，切换后应用启动前查询这些值是否与切换前一致，核对无误再启动应用...

华为存储的接口与EMC差不多，切换命令都是一套标准的切换命令。

Oracle DG和EMC SRDF/SWAP都可以实现灾备功能，但是还是有各自特色的：1. Oracle DG是在数据库层实现灾备功能，只需要执行角色转换命令即可完成切换，切换速度更快。Oracle DG的备库可以实现只读，作为查询库对外提供服务，分担主库的负载。Oracle DG一定程度上可以修复数据库...

前面提到了一些观点，简单总结一下还是建议传统架构的灾备保留传统灾备方案，云原生应用，基于云原生的技术实现业务连续性，有上云需求的应用，要考虑是否适合云环境，适合云环境的可以基于云计算技术实现灾备，例如PaaS层的一些灾备解决方案，不具备上云的还是采用传统方式。切换主要是...

分几个场景，rac数据库灾备的备库启动，数据如何返回主库rac数据库如何和已经启动的备库同步 回切先确定数据量问题，目前市场上有通过数据库archlog进行恢复的技术 或者把灾备的数据库做主库然后生产做备库完全同步后找个变更时间完成数据库业务回切在做rac技术数据库保护...

多演练

基于编排管理软件Kubernetes或DockerEE等软件在LinuxONE上都是完全支持。

灾难发生，需要进行灾备中心接管，这是一个复杂的过程，需要经过灾难预警，灾难评估，灾难的宣告，切换重续，等等步骤，目前的技术不能完全替代人的判断，所以自动化智能是在某些环节实现的，并不是切换整个过程。大部分的操作还是需要人的干预。当然在切换过程中，也需要把一些操作尽量做到程...

瘦核心只是应用架构上的剥离，并不是由集中式一下子过渡到了存粹的分布式基础架构。如果核心系统应用原来支持负载均衡，那么剥离之后继续支持负载均衡，只不过原来是一个系统两种类型业务，现在变为两个系统了。如果核心系统原来的数据库是关系型数据库，不管是RAC还是DB2，剥离之后...