mysql双活脑裂_从两地三中心到双活数据中心

从两地三中心到双活数据中心

两地三中心

两地三中心的有几种实现形式，下图是一种典型案例。

在这一案例中，正常情况下，业务运行在主机房的设备之上。主存储与辅存储存在单向同步关系，即主储存的所有数据变更都会实时同步复制①到次存储上，从而保证两个存储数据完全一致。同时，为防止极端灾害发生，主存储的数据变更也会通过异步复制②的方式同步到远程容灾机房的存储设备上。

当主中心因为各种原因中断服务时，可以通过手工命令或者软件自动切换的方式让业务切换到辅机房。

如果极端情况发生，辅机房也不能运行业务，那么远程容灾机房还有一份数据保存，可以用它恢复业务。

注意：上图只是一种两地三中心的实现方式，还有好几种其它方式，比如：⑴远程容灾中心也配置服务器，当灾害发生时容灾中心可以运行业务；⑵3个存储的拓扑方式不同。但是基本原理差别不大，在此就不做赘述。

①同步复制可以保证数据完全一致，但是对数据传输带宽和时延要求都很高，成本昂贵，适用用于近程。

②异步复制不保证数据完全一致，存在数据丢失的情况，但是对数据传输带宽和时延要求较低，适用于远程。

双活数据中心

两地三中心的优点是防范了各种危害磁盘阵列数据(不包括软件或者人工误操作)的风险，缺点是成本巨高，且设备使用效率低，特别是辅机房设备不能在业务正常运行时使用，浪费很大。

于是存储设备厂商又发展了双活数据中心技术来改进这个缺点。

下面我们以HP XP7磁盘阵列与ORACLE RAC配合为例，展示这个技术方案。

这个方案的核心在于:两个存储配合，虚拟出一个磁盘阵列(类似于主机集群软件的浮动软件包技术)，主机向虚拟磁盘阵列发出IO请求，主存储和辅存储合作，共同完成主机对虚拟磁盘阵列的IO请求。主辅存储数据双向同步，通过内部机制保证数据一致性。

这个方案的优点在于两个机房的主机都只看到一个虚拟磁盘阵列，两台存储的内部同步机制完全对主机透明，主机应用配置简单。

由于主辅存储有一定的物理距离，如果数据同步链路故障，就会出现“脑裂”的情况，这时候，仲裁磁盘起作用的时候到了。

仲裁盘是独立于主辅存储的第三个磁盘设备(不建议用容灾机房的存储)，通过FC链路与主辅存储连接。当主辅存储的数据链路出现异常时，主辅存储会通过仲裁盘决定哪一个存储继续提供服务，不提供服务额存储会进入锁定状态，一直等到数据链路恢复，两个阵列数据同步完成之后再恢复正常。

那么，如果仲裁盘失效时，会出现什么情况呢？很简单，两个存储都锁定，不提供服务。毕竟数据的完整性是最重要的。

图中的仲裁服务器又是做什么的呢？顾名思义，它是一台服务器或者虚拟机，上面运行专用程序为主辅存储提供基于IP协议的仲裁服务。

对于HP XP7或者HDS G系列阵列而言，是不需要仲裁服务器的。但是，有些设备厂商基于各方面考虑，不使用磁盘仲裁，而是仲裁服务器，比如EMC Vplex或者netapp。

此外，有些厂商的方案没有使用虚拟存储，把两台物理存储暴露给主机，然后在阵列上通过其它办法实现两个阵列的数据同步。这种办法我有一些疑问，希望以后能得到高人指点

还有，市场上不仅有基于存储实现的双活，还有基于主机软件实现的双活，如果做得好，都是可以满足需求的。但是有一点需要特别注意：就是“脑裂”状况的处理，我认为：没有第三方仲裁设备的双活方案都是不够强壮的，难以应付现实环境下的复杂状况。

关于“脑裂”，还有“仲裁竞争”问题：当主辅机房链路中断后，存储有仲裁机制，oracle RAC也有自己的仲裁机制，如果出现RAC锁机制判定主机房设备继续提供服务，存储却判定辅机房存储继续提供服务情况，就会导致“双活”变成“双死”。

这种情况确实是一个问题，可是如果仔细研究RAC的锁定机制，我们是可以通过恰当配置来避免这种情况的发生的，建议如下：

RAC的仲裁机制使用的是磁盘，我们只需把仲裁盘配置在虚拟的磁盘阵列上就可以避免“锁竞争“的情况发生。因为RAC仲裁盘在虚拟阵列上，主或辅存储任意一个被锁定，它对应机房的主机也就不可能访问得了虚拟阵列上的锁盘，自然不可能得到仲裁盘的认可，继续运行。