datagrip如何设置夜间模式（Guard故障自动切换的想法）

延伸到数据库方面，我想对于很多DBA来算，能够做到故障的自动切换是一件蛮不错的事情。打个比方，一个普通的DataGuard故障切换场景可能看起来简单，其实涉及很多面，而这些方方面面如果都能够逐个攻破，那就回归了问题的本质，有个说法挺好，提高DBA的幸福度。

大概在2年前，我写过一篇文章，当时也算是随感。由Gavin King的故事所做的感悟 (r4笔记第24天) ，年轻嘛，都是意气风发，想好好撸起袖子大干一场。

但是可能很多人都会碰到了这样一个问题，那就是在公司内造轮子的情况非常普遍，而且很多时候一个脚本，工具，系统只是适用于具体的业务，脱离了系统平台，部门之外，公司之外都无法适用。很多应用要联系具体场景，这个无可厚非，就如同一个表test,含有3个字段，里面可以存放100条应用数据，也可以存放200条，这个是根据具体业务具体对待的。很多时候都是由个别几个人牵头做成的，而有一个似乎不变的现象就是一旦负责人离开，要么就是重复造轮子，要么就是被废弃。

从公司的层面来说，其实一定程度上有耦合是件好事，因为很多东西不希望太通用，太容易被复制。这个原因可能会略微复杂一些，但是也没有错。

延伸到数据库方面，我想对于很多DBA来算，能够做到故障的自动切换是一件蛮不错的事情。这个从能力，技术上都是一种非常大的提升和考验。

我也有很多不错的想法，但是如果有时候没有切磋交流，就会发现其实有些想法不是太迫切，有些细节是需要引起注意的。

打个比方，一个普通的Data Guard故障切换场景可能看起来简单，其实涉及很多面，而这些方方面面如果都能够逐个攻破，那就回归了问题的本质，有个说法挺好，提高DBA的幸福度。

有些场景是一主一备的，可能实现的时候就是只考虑了这样的情况。

有些场景可能会有代理服务器，中控服务器等的角色，这个对原来已有的实现方式就有很大的改动。

有些场景可能是一主多备的架构，那么故障切换的时候就需要做很多的事情。如果再加上代理服务器，中控服务器，这个场景就更加复杂。

所以有时候要做加法，有时候要做减法。总之加加减减，可加可减。

目前设想的Data Guard故障切换的具体实现方式，主要是解决计划外的故障场景，比如服务器宕机，切换业务到备库，对调IP地址，重新配置主备关系，甚至实现自动化搭建备库的场景。这样一来我们就可以极大的从中受益。

这件事情，还是要做的，而且我觉得也是目前对我来说感觉相对自由，有一些自己的空间的一个原因。

要实现这个需求，说实话，有些地方简单，需要地方真心难。但是凡事都有循序渐进的过程，我简单梳理了一下，和团队也做了简单的交流，大体是这样的一个演进方式。

1. 梳理目前的资产信息，系统资产列表目前只有物理信息，但是对于主备关系的标识，机房位置，备库的切换优先级目前需要进一步补充。