本周要开启一次艰苦的差旅行程，一周之内在五个城市间穿梭，拜访数个客户。因此本周可能只能写一两篇了。

上周五OBDIAG周会上，我提了两个小工具的需求，其中一个是参数比对工具，希望OBDIAG提供一个能够对OB参数进行分析的工具。

分布式数据库的复杂度远远高于集中式数据库，其最关键的一点就是节点和组件众多，精细化管理众多的节点会带来很多问题，其中一个比较麻烦的问题就是参数管理。

对分布式数据库而言，集群有集群的参数，每个数据库节点，每个分布式数据库组件也都有参数，同类的组件数量也很多，这些相同功能的组件都有完全相同的参数集，有些可以不同，有些不能不同。虽然你可以在安装部署时尽可能使用相同的参数，但是在实际生产应用内中还是需要对参数进行调整，想要保持分布式数据库的参数设置基本合理，其难度是很大的。

随着数据库上线运行、不断扩容以及应对各种突发的问题，数据库参数的变更会变得多起来，这些组件之间的参数可能会比较难以管理。OCEANBASE上可能有些OBSERVER的参数与大多数OBSERVER不同，从而导致这几个OBSERVER的性能或者其他方面总是会出点小问题。GAUSSDB的某个CN节点的工作内存忘记调大了，跑在这个节点上的SQL就总是会慢一点，亦或是某个DN节点上的OS参数忘记调优了，这个节点的内存总是会换页。

大多数分布式数据库都有参数的白屏管理工具，不过这些工具都或多或少存在一些问题，需要人去利用工具一点点检查参数设置是否存在问题，与真正的运维工作有很大的差距。面对数十个甚至上百个节点或组件，有些组件甚至可能有成百上千的参数，目前的国产分布式数据库的白屏管理工具在这方面做得都不算太好。

分布式数据库的参数分析工具需要什么功能呢?首先能够找出所有的非默认的，被修改过的参数，详细列出其在每个分布式组件上的值。一般情况下参数设置错误导致的数据库问题都是人手工修改过的，因此我们需要对修改过的参数做重点分析。某些分布式数据库目前还不一定具备直接找出非默认参数的能力，那么就需要定期对参数做备份，每天自动比对了。每天比对还可以找出最近变更的情况，比仅仅找出非默认参数更有价值。

如果工具做得再好点，不仅仅要找出最近修改过的参数，还要标注出这些参数是否是高危参数。我曾经和一些数据库厂商的研发人员交流过这个问题，他们对“高位参数”或者参数的危险度分级问题也十分模糊。确实，高危参数不一定能在参数设置时搞清楚，有些高危参数是在运维实践中才被发现出来的。虽然如此，数据库原厂对自己的数据库还是最了解的，是能够标注出大量高危参数的。这项工作，OBDIAG团队和OCEANBASE研发的同学已经在对接了。

如果这件工作再进一步，那就不仅仅是标注出高危参数，还需要找出配置不合理的高危参数，如果可能，最好能够分析出建议配置。对于目前用户对国产分布式数据库的熟悉程度而言，这些工作依靠用户的DBA还是十分困难的，如果有自动化工具支撑会相当有价值。

其次是标注出多个相同类型组件中存在差异的参数，一般情况下，一个分布式数据库的不同服务组件中的同一个参数的设置都是类似的，当然也有些参数可能需要根据硬件环境等因素做不同的设置，存在不同的参数配置不一定就是不合理的。因此工具需要在表格中安排一列，告诉DBA这些参数的分布式环境设置策略，比如必须相同，建议相同，建议不同，必须不同等，这个标注也最好是数据库原厂出具建议。

第三方面是对参数做个分类，比如数据库缓存，数据库编译，数据库并发，并行查询，连接排序，RPC通讯等等。分类可以让DBA更加明确地了解参数的大体作用。虽然数据库厂商也在参考文档中对参数做了解释，但是这些解释过于泛泛，文字也大多干涩，让人看了摸不清头脑。而且数据库参数在数据库版本升级后变化很快，而文档不一定跟得上其节奏，因此在工具中列出参数分类与一些使用建议对运维的帮助就很大了 。

分布式数据库参数管理方面的问题，其实已经在很多用户现场被用户发现了，只是大家感觉到这个方面的问题似乎不是那么紧迫，因此也没有向数据库厂商提出，数据库厂商哪怕接到了用户这方面的需求，也没有当成比较急迫的需求来应对。实际上这方面的工作十分琐碎，在数据库原厂的配合下，由工具生态来完成也没有问题，OBDIAG已经把我的这个需求放到了2.2版的实现任务里了。