麒麟v10 上部署 TiDB v5.1.2 生产环境优化实践
573
2023-05-21
MySQL安装部署,从半成品状态的改进
有时候突然会把几件不搭边的事情联系起来,竟然能够找到一些共通的地方。我在琢磨最近的几件事情的时候,脑海里不由得浮现出几个字:“半成品”
我是蛮反感工作中的半成品的,说有吧,使用效果一般,说没有吧,也投入了一些时间,概括一下就是投入和产出严重不成正比。
另外一类情况更偏于主观,做任务的人感觉一切都妥当了,但是验收的时候,发现不是设计理念的问题就是任务的精细度上面比较粗糙,如果本着差不多就行的态度其实也能过去,但是显然以后的事情谁能说的了,真要用到的时候,代码逻辑都忘差不多了,重新调试改动,这个工作如果前期能稍微充分难一些,也不会有很多返工。
所以在这件事情上面,我发现以前对自己,对团队成员的要求有些松散,以至于稍微带点要求和质量标准,就会感到大家有些吃力,其实对于职业发展来说是有害的,从0到1的构建主要为了效率和快速迭代,可能在一些质量标准上面可以打折扣,过度要求会有些刻薄,但是守江山更难,技术维护也是,都希望时间的边际成本能够越来越低,在已有的基础上构建和改进,那得下真功夫。
我举一个最近和半成品对抗的小例子,也是鞭策自己能够继续按照既定的想法往前走。
这是数据库软件的安装部署的例子,按理说这是很简单的一件事情了,如果要抠命令,基本都是个位数的命令,但是有一些需要额外补充的地方。
1)不同版本的参数文件,比如环境有5.5,5.6,5.7,8.0等,如何更好的支持多个版本
2)初始化用户和权限,根据业务特点有些预置的用户需要创建,配置相应的权限,不同版本下的语法格式都有差异,还有密码插件相关影响。
3)安装部署通常是和监控报警,备份恢复相关的,这些工作是不是可以作为可选项
4)单机多实例和service部署模式还是有一定的差别,如何平滑适配
5) 新增数据库版本支持,已有的接口和部署方式如何适配
MySQL 8.0已经推出了几年,也在内部做了一些测试和总结,而且早期我们直接入主MySQL 5.7版本,也算是积累了3年多的经验,所以果断决定新业务都按照MySQL 8.0的基线来推广。
已有的脚本都好几年没动过了,经过一番需求分析,发现这是一个半成品,主要原因如下:
1)脚本目前直接使用的场景很少,去年团队下大功夫开发的一键部署,因为流程长而显得比较脆弱,已经和这个功能有了很大的差别
2)脚本执行不稳定,因为之前的脚本设计中采用了很多分散的脚本,也就意味着是脚本调脚本的思路,逻辑相对比较庞大,混杂
3)新增8.0的功能,脚本需要整体改动,涉及的面比较大
4)目前脚本里面也存在一些细小的问题,一直没有修复
对于这些问题,我做了如下的一些事情。
1)备份脚本内容后,我开始删除一些过时的逻辑检查代码,去掉一些没有使用场景的逻辑和相关脚本
2)将多个脚本整合为1个,重新组织了脚本关联依赖
3)将依赖的参数文件模板和脚本模板都上传到配置中心里面,在脚本里面会用命令方式提取
4)把原来文件夹的脚本结构重构为一个单一的脚本
5)修改前端的配置,去掉冗余无效的配置项,修改调用逻辑
6)团队内部做了简单演示,团队提了一些改进建议,修正后发布
这些工作经过了很多的测试和整理之后,在不同版本中也做了相关的测试和验证。也算是让原本半成品的状态变为可用,而且是最新版本,接下来要做几件更细致的事情。
1)安装部署的时间目前在30秒以内,涉及数据字典的初始化,目前使用了一刀切的逻辑,后台sleep 20秒,保证这个过程的初始化时间足够,其实可以更加动态友好一些,做动态监测
2)考虑使用基于自制yum的配置方式,把一些固化的参数,命令等方式重新打包构建,这样后续就可以使用yum的方式快速部署了。
3)把软件安装和部署整合起来,提供多版本的软件支持和安装,比如8.0.19,8.0.20
4)使用基于压缩镜像的模式,可以把一个数据库压缩到极小容量,需要时直接解压启动即可,经过之前的测试,一个可用的数据库镜像大概在2M左右,解压后在2G~3G左右(涉及ibdata,reod等文件的容量)
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。