本文共 1509 字，大约阅读时间需要 5 分钟。
大概在2年前，我写过一篇文章，当时也算是随感。，年轻嘛，都是意气风发，想好好撸起袖子大干一场。
但是可能很多人都会碰到了这样一个问题，那就是在公司内造轮子的情况非常普遍，而且很多时候一个脚本，工具，系统只是适用于具体的业务，脱离了系统平台，部门之外，公司之外都无法适用。很多应用要联系具体场景，这个无可厚非，就如同一个表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上来一起做点东西出来。
转载地址：http://hnbsx.baihongyu.com/