关于数据库双活的真正实施场景（有关于仲裁资源的存放）

有些集群软件是支持手工仲裁的，比如rsct，脑裂后可以将仲裁方式修改为人工，然后将某个子集群拉起来。但是有些集群比如gpfs是不支持这种人工仲裁的，它好像就majority一种仲裁方式，不过这也不要紧，依稀记得好像只要子集群里有配置节点，在配置节点里把不要的节点删了，还是可以把集群拉起来。综上，我觉得不一定要有三个机房。ps:交行双活就只有两个机房，然后通过上述方式实现一个中心gg后强行切换到另一个中心的，相比有第三个站点的方式有一个很明显的缺点就是要人工介入而且有几分钟的切换时间，这段时间集群是被挂起的，无法对外提供服务。

为什么需要设置第三方仲裁站点？思维进入误区了，在设计架构时应该尽量避免出现这种情况，因为不可靠

一般说来，只有在创建跨中心的集群的场景时，才会考虑设置第三方仲裁站点，不管是应用层，还是数据库层，或者是所谓的存储双活层。但是想想看，这样设置的益处有多少？带来的风险点增加了多少？(带来的故障场景在8-9种，也太复杂)，根本是得不偿失呀。

厂商推荐的标准做法肯定是配置第三仲裁点，但实际中这种方式不太多见，我觉得主要不是技术上的原因，还是一些成本，安全方面的考虑

仲裁站点是非常必要的。否则你的数据库双活是不安全的，出现网络异常时，最容易出现脑裂的情况。这时候仲裁站点就起作用了。仲裁站点环境要求并不严格，只要在出现脑裂的时候不掉链子就行，你甚至可以对仲裁站点的服务器进行重启和维护都不会有影响的。