这是学习笔记的第 1916 篇文章
有的同学会觉得安装部署应该是很容易的一件事情,其实应该是这样的,但是在实际工作中会发现有很多的因素导致安装部署成为了一种耗时的工作。主要的原因在于数据库本身的安装部署是技术可控的,在这些因素之外,其实还有很多流程的贯通,这些是需要花费不少的时间的,从性价比来说,一次构建,持续改进,效果还是很不错的。
1)安装部署的步骤梳理
针对MySQL方向的部署,我们要改进,首先需要明确一些潜在的问题和不规范的因素。
从流程上来说,部署MySQL服务相关的流程大体有下面的一些方面:
步骤 | 任务 | 任务介绍 |
---|---|---|
1 | 内核参数配置 | 根据预置配置统一规范系统配置 |
2 | 数据目录配置 | 对于多版本,多实例部署,需要规范数据目录 |
3 | MySQL软件部署 | 选择哪个版本,哪个分支 |
4 | MySQL初始化 | 数据字典的初始化,最耗时的过程 |
5 | 安装MySQL插件 | 比如半同步插件,审计插件等,可选项 |
6 | 监控配置 | 使用第三方监控工具提取 |
7 | 报警配置 | 使用第三方报警工具配置 |
8 | 备份配置 | 配置不同IDC的网络配置,可选项 |
9 | 初始化账号配置 | 预置一批初始应用账号 |
10 | 系统权限配置 | 开通部分系统或者服务的访问权限 |
11 | 主从配置 | 配置一主一从或者一主多从的环境 |
12 | 高可用配置 | 配置高可用策略,高可用环境构建 |
所以林林总总下来,我们其实要做的事情还是蛮多的,也蛮复杂的。
从目前行业里的落地情况来看,大部分都实现了脚本化的部署,但是对于流程化的部署和管理还是存在较大的改进空间。
2)安装步骤中常见的问题
部署中常见的问题和不规范的现象主要有:
总体来说,部署的工作繁琐而复杂,因为不够标准化和统一,导致运维效率和交付质量难以保证,粗略统计在早期要完成整个流程化操作,从问题排查和解决,基本在半个从小时到一个小时,对于快速发展的业务来说,是显然不能满足需求的。
在运维管理端,需要做的一层改进就是把上面的潜在问题进行梳理和归类,把运维最关注,最需要的信息罗列出来,在这个基础上进行流程的改进和对接,对于一些可选插件和流程,需要做到灵活的配置管理。
3)运维侧的安装部署设计
在运维侧,MySQL部署的基本页面设计如下:
通过不断的调试改进,目前的环境部署时间可以简化到5分钟之内。
在这个基础上我们可以进一步提炼下,那就是前面的一些步骤除了一些动态的参数之外,我们是否可以进一步把整个MySQL的部署改造为一种更加通用的配置化部署,也就是说,我们可以预先做好一个模板配置和文件部署,对于最耗时的数据字典初始化来说就不用重新在做一次了,有点类似于yum的安装方式,而对于端口等其他的配置,完全可以通过参数配置解决,这是一种改进的思路,这样我们的部署服务其实就可以作为一种基础的系统服务交付,而对于DBA来说,就可以通过配置和优化的方式进行更加灵活的管理。
4)基于PaaS平台的设计
而对于业务使用来说,我们可以完全按照PaaS平台的设计理念来做。
以下是一个数据库资源申请的入口页面:
这样一来,可以很清晰传达出一种资源服务的意识,比如对于业务同学来说,其实他们从一开始是不关注灾备和高可用的,运维同学默默的做好了这些,有时候还会有互相不理解的情况,针对资源需求我们可以做一些定制化的改进,但是交付的标准就很清晰了,是需要申请多少个数据库实例。