最新消息: 10个前端开发需要学习的关键技能
您现在的位置是:群英 > 数据库 > MySQL数据库 >
半成品状态的MYSQL,应该如何改进?
admin发表于 2020-09-01 17:33 次浏览

半成品的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等文件的容量)

本文转载自微信公众号「杨建荣的学习笔记」,可以通过以下二维码关注。转载本文请联系杨建荣的学习笔记公众号。

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:mmqy2019@163.com进行举报,并提供相关证据,查实之后,将立刻删除涉嫌侵权内容。
相关信息推荐
2020-09-01 16:15:46 关键词:MySQL数据库应用教程
摘要:MySQL数据库应用教程..
2020-09-01 15:43:47 关键词:MySQL数据库应用教程
摘要:在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一,单机递增),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用..