数据库管理-第二十八期 数据库设计-部署（20220728）

第二十八期 数据库设计-部署

其实本来因为HW，没啥精力也没啥时间写这一片文章，但是确实被坑惨了，当然写的时候我“勇敢”的在开头表示，其实很多内容是穿插了前面的各种内容的。当然也提前说一下本篇有些内容也不限于数据库本身，来点文不对题吧。

1 标准化部署

最近遇到了两个项目的的坑，一个项目是数据库相关的，另一个是基于k8s的。
先说第一个，在一堆业务系统里面所有数据库的部署方式几乎都不一样，这里的不一样还包含某些主从架构中主从的部署方式都不一样。这其中最主要的是软件部署方式不一样：RPM（包安装）、二进制、源码编译等等；路径不同：配置文件位置、日志位置、数据文件位置等等；启动方式不同：systemd托管、命令直接搞、脚本控制等等；等等等等！首先，先不说可不可以“根据自身喜好”来部署数据库，毕竟对于主机以外，数据库暴露的就是一个端口，跟咋个部署没啥关系，所以不管是使用还是主从啊分布式这些影响都不大。但是从运维管理的角度来说，这就是个大坑，先说几个麻烦的地方：在巡检过程中就很难做到标准化流程，因为每台主机上啥啥啥都不一样；如果有日志平台，上传或抓取日志的配置有多麻烦先不说，日志平台的分析配置也会很麻烦；在故障处理的时候甚至无法快速定位日志（很多时候先要ps看下进程里面配置文件在哪，再去配置文件里面找日志在哪）进行分析…
另一个，则和数据库没多大关系了，是一个跑在k8s上的项目（虽然里面跑了PGSQL），这里坑的则是项目里面的各个组件，是不同的人开发的（抄的），里面的镜像和deploy文件就搞的很有“个性”，说白了就是原作者咋搞得几乎就这么cv过来，不考虑各组件之间的关系，也不考虑与k8s本身是否。。兼容。所以在最近的一次部署（我成功的变成了工具人之一），遇到了各种各样的问题。
所以在我看来标准化部署是非常重要的，对于运维者来说，可以省掉很多麻烦（当然对于开发者来说，没啥区别），无论是日常常规运维操作还是应急处理，都可以带来很便利的提升。

2 完整·官方文档

我认识的很多人，不管是开发岗还是运维岗，甚至是管理岗，在探索一个IT技术的时候，都很喜欢去求教度娘。首先不得不说，度娘确实是个好东西，能快速获取一个技术的相关信息（本来打的是知识，但是想了想还是改了）。但是度娘最大的局限是，里面文章都是别人写的：水平如何？是否正确？是否规范？这并不是每个人都能判断的，加上cv工程师的坏习惯就可能造成一系列问题。当然还有一个更深层次的原因，这个原因引用以前看到过的一句话：“百度文库和Google Library之间的差距远大于中美之间的学术差距”。
为啥很多人不喜欢去官方网站看官方文档，其实主要还是受限于英文水平（还有就是技术类文档网页翻译的可读性，例如SQL Server翻译为SQL服务器），确实大多数技术文档都是全英文，英文差了读起来确实是要命的。另外一点，就算翻官方文档，很多人的关注点也仅仅是在Installation Guide，能够有一个可以用的数据库（或者其他东西）即可，因此我个人在很多协助处理数据库故障或性能问题的时候，经常发现open files或open processes不够了（System requirement）、百兆网跑Oracle RAC private网络（Hardware requirement）、数据库内存配置一丢丢（128G服务器设个8G的SGA）（Administration）等等。
就跟之前说的那个redis集群4个master节点脑裂的问题一样，官方文档是非常重要的（虽然这件事情io和com之间有差异），包括上一节所说的标准化部署，其实主要还是依据官方文档提供的部署方式，当然通过官方文档能够获取更深入更全面的相关知识。

3 AHF

回归到一个专职Oracle DBA该讲的Oracle数据库来，AHF是啥，可能就连很多Oracle DBA都没听过，但肯定听过TFA（听过肯定是听过，主要都是去关闭这玩意），AHF其实就是TFA后来的名字，功能更强大了而已（这里就不分拆AHF和TFA这几个字母指代的啥了）。AHF主要作用就是生成和收集日志，便于用于分析，很多人关TFA的主要原因是觉得日志可以自己分析没必要收集，但是AHF收集日志是一方面，它本身也会生成一些日志，其中主要包含操作系统诸如进程、网络、IO等方面的日志，收集过程中也会收集操作系统本身的日志。（这里回到上一篇的DBA章节，很多DBA觉得操作系统有专人管，跟自己没关系，所以TFA关了！）。
我觉得吧，AHF还是很好用的东西，至少在SR叫上传的时候，第一个东西就是tfacrtl diagcollection，最重要的还是能够在需要分析、溯源的时候有更全面的材料。

4 总结

主要是疲累，写这么一篇文章缓缓脑子来骗骗阅读量，还是加上那句口头禅吧：不晓得写了些啥。