容灾半自动化的实现思路（一)(r7笔记第91天)

最近也在对容灾的切换做一些改进。 目前碰到的问题有 1.灾难切换后备库的内核参数设置不到位，导致切换后又潜在的性能问题 2.灾难切换后在同机房，网络相关的情况下，需要切换备库的IP为主库，但是跨机房，跨IDC可能不行，可以修改IP的情况下，对应用基本是透明，但是如果修改IP就需要应用修改配置。 3.灾难切换之后防火墙信息在主库无法得到的情况，在备库只能关闭防火墙，或者设置最大的访问权限 4.原来主库中的db link可能无法正常解析，如果解析不当或者依赖较多，会有数据库负载成百倍暴涨的可能性 5.原来主库启用的监听端口，切换之后备库可能无从知晓 6.主库中设置的域名解析，如果不同步或有缺失，切换之后会直接应用listener.ora,tnsnames.ora等等配置。 7.主库的参数配置可能和备库不同，切换之后无从判别这些参数的差别。 8.主备库的profile文件可能不同，这些关键的环境变量可能在切换之后会有差别或者不满足要求。 其实还有一些，容我再想想，继续补充，大体基于以上的一些情况和问题，其实最关键的是这些问题如果发生的时候，还是需要人工介入去修改和校正，灾难切换我希望不要发生，但是发生的概率还是较低，所以一旦发生就会有些措手不及，所以处理问题的时候会花费额外的一些时间。 之前也分析过，其实很多时候我们的备库在数据切换上是有oracle的技术兜底，但是在业务需求方面这些工作还是我们得自己完成，而且我建议为半自动切换，主要是因为failover,switchover 这个需要人工的判定，需要联系业务方来共同协作，而不是自动化的切换，这样很容易造成后续的补充工作跟不上节奏，步调不一致。 以上的这些问题，其实就涉及到一些切换中需要考虑的文件。 1.灾难切换后备库的内核参数设置不到位，导致切换后又潜在的性能问题 --/etc/sysctl.conf, /etc/security/limits.conf 2.灾难切换后在同机房，网络相关的情况下，需要切换备库的IP为主库，但是跨机房，跨IDC可能不行，可以修改IP的情况下，对应用基本是透明，但是如果修改IP就需要应用修改配置。--/etc/sysconfig/network-scripts/ifcfg-ethx, /etc/sysconfig/network 3.灾难切换之后防火墙信息在主库无法得到的情况，在备库只能关闭防火墙，或者设置最大的访问权限 --/etc/sysconfig/iptables 4.原来主库中的db link可能无法正常解析，如果解析不当或者依赖较多，会有数据库负载成百倍暴涨的可能性 -- tnsnames.ora 5.原来主库启用的监听端口，切换之后备库可能无从知晓 --listener.ora 6.主库中设置的域名解析，如果不同步或有缺失，切换之后会直接应用listener.ora,tnsnames.ora等等配置。 --/etc/hosts 7.主库的参数配置可能和备库不同，切换之后无从判别这些参数的差别。 -- initxxxx.ora 8.主备库的profile文件可能不同，这些关键的环境变量可能在切换之后会有差别或者不满足要求。 -- .bash_profile 目前自己设想的实现方式如下。首先需要有一台中控机器，能够访问到主库和备库环境。在中控存放主备库的配置信息。就如同右边的图所示。 然后主库会定期抓取这些配置信息，然后主库和备库建立单向的信任关系，可以直接把主库的配置信息通过crontab同步到备库。 而备库中也会定期抓取自己的配置信息，但是不会同步到主库造成干扰。一旦发生问题的时候可以从中控抓取备库的配置。

以上的配置就需要设定一些规范了。首先需要在主备库中都保持/home/conf这样一个目录结构。 主备库的网卡别名都保持一致，比如都是eth0，如果不同同步过去之后还是可能出现问题。 主备库的/etc/oratab的配置要准确，因为这个文件就是个配置信息，但是如果配置不够规范在后期做解析的时候会有一些麻烦。 主备库的网络配置都保持一样的风格，比如有的主库是使用ip的形式，有的是使用主机名的形式来匹配，这些都统一一下，在切换的时候会更加方便一些。 主备库的主机名都能规范一下，很多时候我看到的主库的主机名是备库的，备库看到的是另外一个主机名，出现问题的时候会比较纠结。 还有一些是需要后期去改进的地方，当然也是自己想一想看看怎么实现了。 怎么通过主库抓取到备库的信息情况，目前的情况如果建立了单向信任关系，其实实现思路还是比较清晰的。 怎么判别主库和备库是否在同机房 怎么判别切换后的ip是否可用 怎么判别ILO信息是否有效，怎么保证在切换IP之后始终保持操作的可持续性。