1.问题一：主库处于suspend状态

1.1.故障场景
确认监视器未启动，备库上数据库服务和守护进程因某种原因无法正常启动，主库会处于suspend状态，影响业务正常访问。
1.2.处理过程
备库实例故障，引发主库同步日志到备库失败挂起，确认监视器未启动导致主库的守护守护状态无法确认，始终处于CONFIRM状态，主库实例处于Suspend 状态。数据库在 Suspend 状态下，限制 Redo 日志刷盘，可以访问数据库对象，甚至可以修改数据，但是一旦执行 COMMIT 等操作触发 Redo日志写盘时，当前操作将被挂起。
为了尽快让数据库恢复服务，因首先恢复主库访问，再处理备库问题。
（1）重启主库的守护进程，主库守护进程状态会变为startup。

（2）登录监视器，手动OPEN主库实例，实例OPEN后主库正常提供访问，可以处理备库问题。

（3）备库问题处理后，启动备库守护进程，备库会自动加入守护集群。

2.问题二：备库LSN与主库LSN差距越来越大

2.1.故障场景
通过监视器发现备库LSN与主库LSN差距越来越大，且无法追平。
2.2.处理过程
总体处理思路，因为主备机网络延迟导致响应回主库的速度变慢，这种情况下会极大拖慢主库性能，影响主库正常处理对外的业务请求。此时需要暂停到备库的数据同步，避免拖慢主库性能。待网络延迟问题解决后，再恢复数据同步。
（1）通过监视器确认，发现主库与备库lsn差距越来越大。

（2）通过将异常备库的归档失效，暂停主库到备库的数据同步。首先需要备库的恢复间隔，时间间隔尽量设置大一点，避免设置归档无效后，主库的守护进程立马启动Recovery 流程，又重新将备库归档恢复到有效状态。
set instance GRP1.GRP1_DM2 recover time 86400 (取值：0~86400，单位为秒)
set instance GRP1.GRP1_DM2 arch invalid

（3）处理备机问题，造成该问题的原因比较多，比如主、备机网络故障、备机IO效率低下入库慢等
（4）备机问题解决后，将备库的恢复间隔设置到一个比较小的值（0~86400s），启动备库的恢复流程故障分析
set instance GRP1.GRP1_DM2 recover time 3

3.问题三：集群主库反复宕机和接管

3.1.故障场景
集群反复切机，主、备机频繁切换。
3.2.处理过程
1、通过确认监视器日志确认集群状态，明确故障现象；
2、查看数据库日志和堆栈信息（如果有），通过分析日志找到问题线索‌；
3、网络连通性检查，需检查监视器、数据库服务器01、数据库服务器02之间的网络连通性和端口；
4、检查数据一致性，因主、备库频繁切机，主备数据同步存在延时，数据量大的情况下，可能导致数据出现不一致的问题。
从故障现象分析，主、备库频繁切机，从侧面说明主、备库应该就可以正常启动，问题可能主要集中在两方面网络问题和应用访问导致的数据库宕机。
（1）网络问题，应该为监视器、数据库服务器01、数据库服务器02之间内部网络通信不稳定造成的，如果该问题无法立即修复可以考虑单节点运行，避免集群频繁切机或者更进一步造成脑裂，网络稳定后再将备库加入集群；
（2）应用访问导致的数据库宕机，一般可以通过堆栈信息进行定位，但是在问题定位前可能没有很好的绕过办法。