数据库工具库版本升级平台

前言

这些年来,做数据库管理平台,DBA积攒了不少脚本和工具。由于公司维护的数据库组件较多,每个组件有自己的代码,因为不断的需求变更以及新功能开发,需要对线上的管理工具库进行升级。
虽然公司有专业的软件发布管理平台,但是由于我们管理的数据库机器多,数据库组件也比较多,在不断升级演进的过程中会碰到以下几个问题:

  • 每次批量下发大量的主机,工作量不小,而且每次发版都会存在部分主机因为各种原因发版不成功;
  • 多个数据库组件工具库同时开发灰度中,新发版本控制问题;
  • 新版本已发版,但是线上有机器没有及时更新新版本;

思路

为了方便版本管理和及时的升级,初步考虑了以下的思路来对数据库主机上的DBA工具库的版本进行管理。

管理机

考虑到每次向几千台数据库机器发版,不仅工作量大,而且容易出现漏发、错发的问题,所以规划出管理机,后续所有的发版操作都在管理机上进行。
在管理机器上进行以下的操作:

  • 所有发版都在管理机上进行,并且在管理机DBA工具库的有效的历史版本信息;
  • 管理机提供版本发现服务和版本下载服务,初步考虑提供http服务来实现;

版本规划

因为系统要不断进行功能升级,优化和BUG修复,所以系统中会同时存在正式版本和灰度版本两种。

正式版本

正式版本采用GNU风格三段式版本号,即Major. Minor. Patch。用数值表示版本号,数值之间用小圆点“.”分隔。

Major:表示大版本号,一般当工具库出现重大更新,重写或者不再向后兼容的情况时,版本号会在Major上加1;

Minor:表示次版本号,当工具库有功能更新或者小的功能迭代和调整时,版本号会在Minor上加1。同理当Minor增加1时,也会将后面的Patch清零。

Patch:表示修订号或补丁号,当工具库修复了一个bug或者少量局部优化调整时,版本号会在Patch上加1。

版本大小:通过上述原则,按照Major, Minor, Patch三者找那个前面越大,版本越大为原则,后续自动升级过程中,会根据版本大小判断,是否需要升级以及升级到哪个版本。

灰度版本

灰度版本可以在正式版本后面后缀:.gray.<数据库组件名>.,例如,1.0.1.gray.mysql.1。表示对应1.0.1版本的mysql灰度版本。

数据库主机

在每台数据库主机上安装DBA工具库初始版本,DBA工具库支持自升降级服务。

自升级服务

自升降级的逻辑如下:

  • 定时向管理机发起最新版本探测服务;
  • 新版本探测服务获取管理机上的最大正式版本;
  • 对比数据库主机上正式版本与管理机获取的最大版本号,如果不同就自动下载对应的版本;

通过上述逻辑,就能自动的实现DBA工具库的自动升降机功能。
例如:

  • 现状
    管理机现有:1.1.15, 1.1.12, 1.1.0 三个版本的DBA工具库。
    所有的数据库主机已经升级到最新版本1.1.15,
  • 目标:升级工具库到1.1.16
    DBA向管理机发布最新版本1.1.16,于是管理机上有1.1.16, 1.1.15, 1.1.12, 1.1.0四个版本;
  • 自动升级
    所有数据库主机的DBA工具库定时发现管理机上的最新版本为1.1.16,与数据库主机的版本1.1.15不一致,于是自动向管理机发起下载1.1.16版本。
    下载完成后,做必要的服务重启等工作,数据库主机就完成了升级。

灰度升级服务

同时考虑到灰度需求,考虑会给各种不同数据库组件的几台主机打上灰度标签。
打了灰度标签的主机,除了正式的版本升降级外,还需要进行灰度版的升级功能。

灰度升级服务的逻辑稍微有点不同,大致流程为:

  • 定时向管理机发起最新灰度版本探测服务;
  • 新版本探测服务获取管理机上的最大灰度版本;
  • 对比数据库主机上现有版本与管理机获取的最大灰度版本;
    • 如果数据库主机现存的是正式版本,则灰度版本号大于现存正式版本,则下载灰度版本,否则不处理;
    • 如果数据库主机现存的已经是灰度版本,则对比管理机上的灰度版本与现存灰度版本号,如果比管理机上的版本号小就下载对应的灰度版本,否则不处理;

例子:

  • 现状
    数据库主机现存1.1.15
  • 准备灰度1.1.16.gray.mysql.1
    往管理机发布DBA工具库版本1.1.16.gray.mysql.1
  • 打标签的数据库主机
    获取到管理机最新灰度版本为1.1.16.gray.mysql.1,因为1.1.16比现存的1.1.15大,所以下载改灰度版本

当发现1.1.16.gray.mysql.1有bug时,我们有两个措施:

  • 向管理机发新的1.1.16.gray.mysql.2,因为1.1.16.gray.mysql.2比1.1.16.gray.mysql.1大,所以会下载1.1.16.gray.mysql.2的工具库;
  • 删除1.1.16.gray.mysql.1的灰度版本,在正式版本自升降流程中,会完成该数据库主机从管理机下载1.1.15正式版本,从而覆盖有bug的1.1.16.gray.mysql.1版本。

总结

以上是一个实现思路,笔者也打算按照这个思路去构建DBA工具库的分发,简化我们现在的版本管理流程。
如果读者有更好的方法,欢迎一起探讨和交流。

你可能感兴趣的:(数据库工具库版本升级平台)