大概在2年前，我写过一篇文章，当时也算是随感。由Gavin King的故事所做的感悟 (r4笔记第24天)，年轻嘛，都是意气风发，想好好撸起袖子大干一场。
但是可能很多人都会碰到了这样一个问题，那就是在公司内造轮子的情况非常普遍，而且很多时候一个脚本，工具，系统只是适用于具体的业务，脱离了系统平台，部门之外，公司之外都无法适用。很多应用要联系具体场景，这个无可厚非，就如同一个表test,含有3个字段，里面可以存放100条应用数据，也可以存放200条，这个是根据具体业务具体对待的。很多时候都是由个别几个人牵头做成的，而有一个似乎不变的现象就是一旦负责人离开，要么就是重复造轮子，要么就是被废弃。
从公司的层面来说，其实一定程度上有耦合是件好事，因为很多东西不希望太通用，太容易被复制。这个原因可能会略微复杂一些，但是也没有错。
延伸到数据库方面，我想对于很多DBA来算，能够做到故障的自动切换是一件蛮不错的事情。这个从能力，技术上都是一种非常大的提升和考验。
我也有很多不错的想法，但是如果有时候没有切磋交流，就会发现其实有些想法不是太迫切，有些细节是需要引起注意的。
打个比方，一个普通的Data Guard故障切换场景可能看起来简单，其实涉及很多面，而这些方方面面如果都能够逐个攻破，那就回归了问题的本质，有个说法挺好，提高DBA的幸福度。
有些场景是一主一备的，可能实现的时候就是只考虑了这样的情况。
有些场景可能会有代理服务器，中控服务器等的角色，这个对原来已有的实现方式就有很大的改动。
有些场景可能是一主多备的架构，那么故障切换的时候就需要做很多的事情。如果再加上代理服务器，中控服务器，这个场景就更加复杂。
所以有时候要做加法，有时候要做减法。总之加加减减，可加可减。
目前设想的Data Guard故障切换的具体实现方式，主要是解决计划外的故障场景，比如服务器宕机，切换业务到备库，对调IP地址，重新配置主备关系，甚至实现自动化搭建备库的场景。这样一来我们就可以极大的从中受益。
这件事情，还是要做的，而且我觉得也是目前对我来说感觉相对自由，有一些自己的空间的一个原因。
要实现这个需求，说实话，有些地方简单，需要地方真心难。但是凡事都有循序渐进的过程，我简单梳理了一下，和团队也做了简单的交流，大体是这样的一个演进方式。
1. 梳理目前的资产信息，系统资产列表目前只有物理信息，但是对于主备关系的标识，机房位置，备库的切换优先级目前需要进一步补充。
2. 系统元数据备份
涉及主库的防火墙信息，/etc/hosts,内核参数配置等
备库的防火墙信息，主机配置，内核参数配置等
3. 数据库元数据备份，涉及数据库的listener.ora,tnsnams.ora,参数文件
4. 故障切换脚本化 故障切换有几个方面的检查工作。
1）. 检测主库是否可访问（系统，网络，数据库）
2）. 检测备库的数据同步情况
3）. 判断故障切换的优先顺序和服务可用性检测
4）. 数据库角色的切换（备切主）
5. 数据库IP对调
6. 自愈稽核
1）. 检查数据库连接数和应用连接情况
2）. 多备库的主备关系重新配置
3）. 元数据备份
4）. 操作日志归档和通知
7. 自动化搭建备库，如果是多备库环境，准备好备库环境，自动化配置
大体上上面的一个步骤，尤其是第7步，是本次故障自愈的一个亮点，那就是自动化搭建Data
Guard,思路就是使用一台备用服务器，根据需求搭建Data
Guard,比如我有10套环境，我们添加一个服务器作为备机，在故障发生的时候，能够根据故障情况搭建Data Guard.
我现在也在规划中，最近会打算在github上来一起做点东西出来。