企业级规范架构下的数据库搭建【续】

在上一篇文章（企业级规范架构下的数据库搭建（MySQL篇）有提到怎么搭建一套适合企业级的MySQL数据库架构。简单的说，就是一切资源配置、文件名、目录、版本、参数等都保持一定的标准化和规范化。而且通过制定规范搭建方式，杜绝了不同人员采用不同方法进行数据库搭建，保证了架构一致性和可维护性。

虽然里面只写了ORACLE、MySQL的搭建方法，但是无论主从的搭建、还是多套MySQL共存于同一服务器，都能通过这个步骤进行搭建。今天接着上篇文章写，不过不再重复介绍数据库的搭建，而是以开拓性的思维来分析这套搭建方案。

何谓开拓性的思维看待呢？简单点说，多套MySQL共存于同一服务器，就是最基本的思想。不过此时你是否会想，既然MySQL可以这样，那ORACLE、PG、MongoDB、Redis等其他数据库，是否都可以用这样的方式？一是规范化，二是资源的高利用，且多套共存却又毫不影响他们之间的切换和隔离性，然后再通过各种其他周边技术，比如：Cgroup、ORACLE Resource manager、RAC、RAC one node、VCS、pacemaker、RHCS等实现资源的高可用管理，然后根据生产/容灾/测试环境以及业务线的重要程度，分配不同数量、不同业务类型的数据库实例到服务器上。多种方案的配合，自然就造就了一套可复用的高可用架构。

架构规范有了，但是每次都得手动这么搭建会很麻烦，那么是不是可以想一些办法来优化搭建呢？“自动化” 应该是最先被想到的方法，毕竟所有搭建步骤都是标准的，那么就可以轻松集成到自动化中。那么还能更轻松吗？毕竟写自动化代码的过程还是有优化空间的。我给出的方案中有一点很重要：那就是 “数据库初始化” ，为何要初始化？主要是保证数据库的某些参数和配置能达到一个普通标准，能做到一些异常的提前预防，避免事后由于参数不规范导致频繁操作生产库。我还依稀记得之前那家公司领导说过：“我们公司数据库的每一条规范，都是一部血泪史。都是为了弥补过去踩过的坑、出过的故障而设定的。”

知道了为什么要做初始化，那么是否可以专门弄一套已经各方面初始化标准化好的库作为种子库呢？后续搭建就直接用种子库搭建，最后改路径、文件名、库名就可以了。这样是不是又减少了一些工作量？同时这也能避免一些遗漏操作的问题。之前就出现过这种操作遗漏的情况：我一个经验极其丰富的同事在搭建一套客户方非标环境的时候，由于环境非标，没法完全按照规范手册进行搭建，且属于临时派下的紧急项目，就没有准备手册。而这种简单的环境已经搭建过无数遍了，了然于胸。就自信的根据自己的经验进行处理。事后其实也没什么问题，却在上线后的不久接到了连接数高级，一看才发现是之前搭建的时候漏调整了processes参数。只得各方沟通维护窗口，发版本重启调整。其中付出的代价大了很多倍。从这个事情来看，规范手册的重要性和操作的简单性是非常重要的。无论是多么简单的变更都不能掉以轻心，变更前的操作手册是必须准备的，毕竟操作前有大量的时间进行思考和补充以及组内复核集思广益，减少风险。而真正变更的时候再临时设计方案，是很容易遗漏一些步骤的。而这些遗漏，可能无关紧要，但也可能让你付出极大的代价进行修复，甚至会导致很严重的故障。

上面说到了环境搭建、规范化和自动化。其实是属于一个的事前和事中的思路。我对大部分的工作都建议使用一个闭环的思路来看待，简单来说就是：
事前做什么：规范化建设、应急预案、自愈、监控告警等。
事中做什么：健全的制度、手册、知识库、人员储备、开发/运维平台。
事后做什么：回溯、整理分析、从根本上分析进行优化，并且进行横向扩展，即对其他事情与系统也进行同样的分析检查和优化。
最后反推到事前：是否可以优化规范，优化应急预案，优化监控告警，自愈工具等等，做到一个事情的提前准备，主动预防。

下面分享的同样只是思路，而非详细的技术。我将其定义为事后，毕竟已经做了事前（指定规范、手册、平台）和事中（正式搭建，复核），那么事后的日常运维也是非常重要的。这种架构下的主机安装了十几套甚至几十套数据库。如果我想做一些简单的检查，那我岂不是得每个库都得登录一次，做很多遍重复操作？既然如此，是不是可以开发一个小工具来一次性打印部分简单却又很实用的信息出来呢？同时由于域名也标准化的存在，可以把整个主从集群的信息都打印好，对于分片库那就更加有效了。

废话不多说，其实很简单，就上个简单的图，部分细节请不要在意，这里主要是分享思路。

这里仅仅只举例ORACLE和MySQL。其实如果使用了这套搭建方案，dbs这个套路可以用到所有类型的数据库上。同时，你可以根据个人喜好以及公司需求来打印所需要的信息，然后再做一些判断来对特殊信息进行高亮提示，比如我MySQL那图里有做Down库、同步异常的判断。

这都只是思路，我这里也只是初版。后面会加上TPS/QPS、锁、内存命中率、CPU占比，以及主从集群实例等信息，然后对active连接，高TPS/QPS、锁、CPU占比等进行高亮提示。一次性打印出自己需要的信息，是否感觉还不错呢？

工作工欲善其事必先利其器。那是个“器”是什么？我个人的理解而言。不是多牛逼的脚本，不是多漂亮的工具。而是你对这些东西有多么的熟练，对这些原理有多深的研究，以及你利用这些东西，能多发散自己的思维。有了这些，你才能做到想实现什么功能就可以实现。而非到处找工具找脚本，一旦有一天换了个环境离开了这些东西，就无所适从了。