灾备中心要承载业务运行，这已经是一个共识。因此灾备中心的概念也在弱化，取而代之的是IDC数据中心概念。首先数据需要在多数据中心复制，保证数据不丢失。其次业务多数据中心部署，同时提供服务。这一点在互联网行业做得最好。这也是因为互联网行业本身的业务特点促成的。然而对于传统行业，不能完全照搬互联网行业的分布式技术。更多的系统是需要在现有架构的基础上进行改造。这也是为什么要做双活的数据中心。
每个系统在多数据中心部署的目标是不同的，可以是分布式业务，也可以是读写分离，也有完全对等双活的业务部署。在这些部署方案里面，数据库双活技术也成为重点关注的对象。然而在使用这些技术的时候存在很多误区，并非所有的场景都适合，所以企业需要一定的取舍，真正用好这些技术才能达到业务多数据中心建设的目的。
社区最近组织了交流活动，以帮助大家更好的明确理解数据中心建设，我们将活动内容总结为设计原则、技术选型和五大难点攻克，分别推送给大家。
交流分享者——本次活动专家：
孔再华 民生银行 数据库架构师
具有丰富的数据库环境问题诊断和性能调优的经验，擅长Db2 pureScale 集群产品的项目咨询和实施，目前负责推广数据库同城双活架构建设，曾经负责Db2数据库双活项目的设计和管理工作，有着丰富的实践经验。目前在社区top100关注榜中位列第6。
冯帅 点融网 高级DBA
精通Oracle、 MySQL。 擅长异构数据库数据同步及迁移、数据库的设计和调优。参与过oracle、MySQL数据库的双活项目，有丰富的经验。
韩成亮 某金融单位 数据库架构师
擅长数据库的设计、性能诊断、SQL调优，熟悉异构数据库之间的数据同步和迁移，目前从事MySQL相关的运维和架构工作。曾经设计过MySQL数据库的双活项目方案，有丰富实践经验。在社区MySQL领域声望榜中排行第三。
还有以下会员热心分享：
岳彩波 中能源 数据库运维工程师
libai21 海通证券 软件架构设计师
kernelry 赛姆科技 数据库架构师
为什么要做数据库双活？数据库双活的目的及意义是什么？
在两地三中心建设过程中，我们发现采用传统的容灾技术后，会碰到3个问题：
1. 切换时间太长，在今年同城灾备演练中，即使通过自动化实现，主切备和备切主都需要花费40分钟时间。
2. 操作风险太大，比如核心系统切换涉及到20步以上的操作步骤和上百条命令，每条命令都有出错的可能。
3. 建设成本太高，同城机房按照1比2甚至1比1 的比例进行建设，服务器平时完全闲置，除了一次性投入，每年还要耗费大量的维护费用。
因此相对于传统容灾方式，我们希望建设一个双活平台，解决降低RTO时间、降低成本和降低切换风险等需求。（孔再华）
※※※
核心目的是为了业务的连续性。
在传统数据中心中，业务系统的数据往往都是存放在一个数据库中，这种模式的数据中心存在着一定的业务连续性风险——即如果数据库出现故障宕机，所有与这台数据库有连接的业务系统就会停顿，甚至会丢失数据。
数据库双活互为备份或者镜像，当一个发生故障、业务自动切换到另一个，业务均会继续运行，不受影响，且数据在故障过程中无丢失，解决了传统单点故障问题。
其实还有其他的优点，比如容灾，备份，负载等其他的RTO、RPO需求。（韩成亮）
※※※
单点故障问题的解决方法就是双活，因为你数据库或者操作系统或者存储任何一方是单点的情况下，任何一方出现问题将影响整个业务的运行，所以就需要双活来避免单点故障这个问题发生而影响业务。（kernelry）
跨数据中心数据库双活方案设计时应该遵循哪些原则？
如果将数据库双活平台作为未来的常规建设，应用越来越多的系统，那么在建设初期，我们就要设定好平台的目标：
1、通用性：基于LUW开放平台，支持部署在任何厂商的存储、服务器和操作系统上。不能选择一体机，大型机等不通用的设备。
2、无差别性： 双中心交易对等，同城之间同时处理业务请求，无主次之分。只有这样的系统才能面对失去单数据中心的风险。
3、高可用性：最下化降低同城切换时间，同城站点出问题不会影响全局业务。业务切换需要在最短时间内完成。
4、可维护性：基础设置重大变更不停机，可以通过滚动升级的方式完成维护操作。
5、可迁移性：平台对业务系统透明，开发无需改动代码，即可快速部署到该平台。同样该平台部署的系统也可平滑迁移出来。
6、安全稳定运行，该平台可以实现5个9的运行目标。（孔再华）
※※※
网络传输的高效性
网络传输的高可用性
网络传输的高安全性
服务器的高效性
服务器的高可用性
服务器的高安全性
数据库的高效性
数据库的高可用性
数据库的高安全性
配置的最优化
资源利用最大化
最后是良好的管理性，总之一切为了高效性，高可用，高安全性，满足业务的需求，当然还有结合你的成本考虑。（韩成亮）
做数据库双活方案设计有哪些工作需要考虑？
做数据库双活方案的设计需要考虑很多方面：
业务选型：数据库双活在实现双中心对等并重的同时，也对业务系统有着苛刻的要求。因为几十公里的延时会导致通信和存储变慢，从而产生蝴蝶效应。所以首先要做的是明确什么样的业务适合上双活。业务选型的要素：业务类型简单，应用读写比高，作为新技术的验证，最好首先从独立性高的业务开始，不要影响其他业务。
技术选型：选好适合的业务系统后，下面考虑的是采用什么数据库技术。是Oracle的RAC还是DB2的pureScae集群。上线后的数据访问时什么样的，是无差别的读写，还是需要做读写分离。这些都是在选择双活技术的考虑因素。选择好上层数据库产品后，还需要考虑共享文件系统的选型。在民生有DB的GDPC双活，也有Oracle的RAC双活。但是这两个环境的底层共享文件系统都是选择了GPFS。因为这里不仅仅考虑了技术的优缺点，成熟度，还要考虑公司的运维能力。
硬件选型基础建设：硬件选型在这个方案里面尤其重要，是一切实现的基础。主机采用什么设备，X86还是P系列，网络是采用RDMA还是TCPIP，如果是RDMA，那么是选择RoCE还是Infiniband。存储采用哪个厂商的信号，是否考虑SCSI-3PR的技术。双中心建设大二层网络需要采购什么什么设备，和当前网络设备是否能集成公用等等。最后硬件换进过的拓扑架构是什么样的，怎么做好冗余高可用等。
运维建设：最后能上还得能玩双活才行。运维建设很重要，完善的文档，有经验的运维人员，厂商支持力度才是双活环境保驾护航的重点。（孔再华）
数据库双活技术该如何选型?
主流数据库双活技术的详细对比
1 技术方案性能相关的对比
2 技术方案的自有特性
3 技术方案差异性
4 技术方案的优缺点
5 技术方案成本考虑
6 技术方案管理性
其实最主要的的你需要了解你的业务核心需求是什么，一切的一切都是以业务为前提的。（冯帅）
※※※
这个技术选型要考虑很多方面： 首先是定义目标。为什么要做双活，覆盖到什么程度，将会有哪些候选应用。这些应用的特点是什么，只需要做读写分离还是需要无差别双活访问。有了这个目标之后才是选型。如果是读写分离，数据库基于日志的同步技术或者是第三方工具来做数据复制都是没问题的。这种模式实现也简单，能够快速部署上线。但是如果目标比较高，需要RPO=0，RTO分钟级，那么就需要选择无差别的双活模式，需要考虑DB2的pureScale或者是Oracle的RAC这样的集群产品。定义好数据复制的技术后，下一步是这种方案下的基础环境选型，采用什么服务器，存储，网络，如何搭建网络，怎么实现冗余，各个环节的高可用配置该怎么做。最后这个双活的方案基本就确定了。在这个过程中还需要考虑后期的运维，人员的能力，对业务的侵入性等因素。（孔再华）
※※※
我觉得应该从业务需求入手，看看业务对双活的真正需求是什么，然后选择对应的方案。
目前的技术没有明显的优劣，都有各自的优势和缺点，所以一定要选择合适的。
多数据中心数据有哪些同步方式，该如何选择？（libai21）
※※※
多数据中心数据同步大致分为两种方式，一种是存储复制，一种是数据复制。
存储复制通过存储复制技术，将磁盘同步或者异步复制到不同数据中心。一般同城数据中心距离较近，会采用同步的模式。同步模式会对写操作有延迟，进而影响一部分性能。异地数据中心因为距离较远，采用异步模式，对本地数据访问没有影响。
存储复制还分为硬件技术复制和软件技术复制。硬件技术复制是存储厂商提供的技术，优点是方案成熟，配置简单，对于应用适应性强。缺点是成本高，单活，对网络传输压力大。所以建议高级别的业务系统采用这种方式。软件复制技术是使用例如LVmirror，GPFS等软件技术来复制不同数据中心的磁盘。优点是成本低，灵活性高，缺点是配置复杂，适用性差，需要对应用当前环境停机改造，后期维护起来复杂。所以这种方式用的很少。
数据复制时通过数据库技术或者第三方软件实现数据中心间的数据同步。同样数据复制也分为同步和异步两种模式，分别适用于短距离数据中心和长距离数据中心。数据复制可选择性比较多，
数据库本身提供了数据复制的技术，例如DB2的HADR，oracle的dataguard，mysql的主从同步。这些技术都属于ActiveStandby模式，Standby可以开启只读，做上读写分离。这种方式在数据中心同步中使用非常广泛，也是主要推荐的一种方式。出现灾难切换的时候，数据库能很快切换到其他数据中心，相对于存储复制的冷备方式，热备能够大大加快切换速度，也减少了切换的未知风险。
数据库还未第三方工具提供了日志解析的接口，所以有很多复制工具也被用来实现数据中心的数据同步。但是这种方式通常不会用于整库复制。而且这种第三方工具也没有同步模式。通常是作为实时性要求不高的业务数据同步。这种工具还有个很好的优点是支持异构，可以在不同种类的数据库间实现数据同步。
数据库物理复制技术和工具逻辑复制技术都可以满足不同数据中心之间数据复制。
但是各项技术各有千秋，使用场景也不一样。
最后说说数据库双活的运用场景。数据库双活要求在两个数据中心都能看到相同的数据，所以数据一定是同步复制的，并且都可读写。因此可选的复制技术并不多。存储技术有存储虚拟化，双中心访问的是最终虚拟的盘，实际底层由存储进行复制。这种其实运用的不多，因为存储复制也要防止脑裂的问题需要加仲裁。在脑裂的时候有可能选择任意一边存活。而上层数据库集群也有脑裂问题，可能选择另一边存活，这就会导致底层存储和上层数据库选择可能不一致，结果服务不可用。而且次方案成本也非常高。另外一种就是数据库自带的软件复制技术。现在只有Oracle的RAC和DB2的pureScale集群能提供这种跨数据中心的双活方案。Oracle有ASM，DB2有GPFS，都可以做存储实时同步。因为这些文件系统软件和数据库的紧密结合，成为数据库双活方案的不二之选。（孔再华）
※※※
多数据中心同步数据要看方式，看用的什么数据库，什么方案，Oracle的话可以用ogg等同步数据，如果是做灾备数据中心的话可以用dataguard。（岳彩波）
