在DB2双机热备的场景中，哪些问题会影响切换成功率？

双机热备是最古老的高可用方案，一直延续至今使用率也是非常广泛的，当年没有pureScale和RAC的时候，双机热备几乎是数据库高可用的必备选项。数据库双机热备的原理其实很简单，就是磁盘挂在两台机器上，服务运行于一边，出现故障的时候服务切换到另外一边，同时浮动IP也会随着服务一起切换过去。
在现实场景中，经常会出现切换失败的情况，根据我们的经验，切换失败很大一部分原因都是由于文件系统umount失败导致的，常见的失败场景有：
1. 数据库进程没有停止干净，导致文件系统umount失败。在切换脚本中，一般都会在主节点上运行stop脚本，如果脚本里面只写一个db2stop force，那么很容易存在没有停掉的进程，尤其是在数据库故障的时候。只要有进程存在，实例目录umount就会失败。所以，双机脚本尤其是stop脚本一定要注意写的严谨一些。
2. db2fence用户home目录创建在了共享磁盘上。db2默认的三个用户，dasadm1,db2inst1,db2fenc1，只有db2inst1是需要放到共享磁盘上的，对于db2fenc1，他的进程不属于db2核心进程，因此db2stop的时候会残留很多db2fenc1用户的db2fmp进程，导致文件系统umount失败，进而导致双机切换失败。其实，db2fenc1用户完全可以创建在本地磁盘，这样即使存在进程也不会影响切换的。
3. 存在没有退出的用户shell。这也是非常常见的场景，用户通过ssh或者telnet工具登录到系统上，退出的时候直接关掉客户端工具（直接点x关掉窗口），你以为退出了，其实后台ssh进程都还在呢，通过ps命令可以看到，这时候如果发生双机切换，umount也会失败。对于这种情况，有些客户甚至制订了规章制度，严厉制止这种直接关掉远程工具的行为，防止用户不退出。
对于上面几个问题，解决的办法就是：
1. stop脚本里加上db2_kill和kill命令，虽然一般不建议用db2_kill，但是双机切换的时候属于特殊情况，尽量保证切换的成功率。
2. db2fenc1和dasusr1用户创建在本地磁盘
3. 用户退出的时候，一定要exit或者ctrl+d，不要直接关掉工具。或者在stop脚本里写上fuser命令强制清除残留进程。收起

好啊！！！！！！！！！！！收起