现象描述：
项目开发通知我说数据库主备集群在服务器重启后无法正常通过应用连接，让我帮忙启动下服务。于是先登录主库服务器，想要检查数据库服务是否正常运行，发现主库服务器170无法正常登陆，联系运维处理，说是在迁移云平台服务器，原先的云平台到期了，无法正常维护，迁移完成后就好了。第二天，开发通知我说170服务器可以登录了，但是他们服务还是无法正常连接，于是登录170服务器，通过监视器发现集群发生了主备切换，原主库170成了备库处于MOUNT状态，原备库238成了主库处于SUSPEND状态。而且集群发生了脑裂。

处理流程：
一开始想观察一下集群是否能够正常恢复，于是一直通过tip/show命令观察集群状态，但是状态很奇怪一直在变，通过disql登录，发现状态也不正常，集群状态无法自行恢复。只能重新搭建集群做集群恢复。于是通过原主库，想要将原主库状态变成普通状态，做dmrman备份恢复，但是发现在进入disql命令行敲命令时，总是掉线，一连几次都是这样。
这时联系运维同事问他是不是迁移服务器有什么问题，服务器敲几个命令就掉线了，运维同事检查是否有磁盘没有成功迁移，发现所有磁盘都正常迁移了，没有问题。
于是想着连接238通过原备库做备份恢复。我又登录原备库服务器发现，原先的dmdba账号无法正常登录，一直报错密码错误，使用其他账号登录，通过cat /etc/passwd发现dmdba用户不见了，且原先挂载的数据库磁盘/dm也不见了，将以上信息全部反馈给运维后，运维再次检查迁移服务器中是否有没有迁移成功的磁盘，磁盘的确迁移成功了，但是迁移完后，原先云平台上虚拟机没有关机，导致IP冲突，也就是说当前有两台完全一样的虚拟机在跑，难怪我输几个命令，SHELL窗口就被自动关了，运维将旧平台上虚拟机关机后，这时发现，238上磁盘和用户都能看到了。
再次登录监视器，等待主备库LSN追赶的差不多时，进行主备切换，将170再次变成主库，集群恢复。
总结：
这还是第一次在项目中遇到集群分裂，也是没想到会是这样也会导致集群分裂。由于运维同事在迁移云平台服务器后，没有将原来旧平台上的虚拟机关机，导致IP冲突。在将原云平台虚拟机关机后，很快集群状态就正常。作为一次项目经验分享。
我的dmarch.ini以及dmwatcher.ini文件配置如下：


通过与领导沟通，建议我将ARCH_WAIT_APLY=1改成ARCH_WAIT_APLY=0，以后应该就不会出现这种情况了。