怎么从生命周期的角度来规划数据库运维体系

91次阅读
没有评论

共计 1700 个字符,预计需要花费 5 分钟才能阅读完成。

本篇内容介绍了“怎么从生命周期的角度来规划数据库运维体系”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让丸趣 TV 小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!

最近在和团队规划 OKR 目标的时候,我们讨论了很多问题,我先抛砖引玉,列举了一些现有的问题,打算按照推导的方式:

1) 列举当前问题

2) 问题归类和总结

3) 梳理现有经验和现有方案

4) 结合时间 / 性价比得到一定时期的预期目标。

整体来看,工作量还是蛮大的,再加上大家对于问题的理解角度不同,所以在容易在很多细节上讨论太多,难以聚焦。

所以我想了下,准备按照生命周期的维度来进行考虑,于是整理了一版设计图,整体是分为四个层面,也就是按照业务从申请资源和权限,到服务上线,服务优化,最后是相关的服务数据迁移和流转。

整体设计下来,我们会发现很多考虑中不足的地方和遗漏的角度。在多次提炼之后,我把这个设计图调整为如下的模式:

我来逐个解释下:

1) 规范 / 选型 / 规划:这个阶段更强调整体,很多问题如果直接从基础运维入手,其实就已经晚了,有些服务质量差,交付时间长,本质上还是前期的基础建设不够扎实,所以这是一个互惠互利的关系,比如开发规范的设计和落地执行,架构设计 (如分布式架构设计),技术选型 (如 MySQL  8.0 适配的中间件技术调研,ClickHouse 技术调研,TiDB 技术选型,MyRocks 存储引擎测试分析等),SQL 审核 (已有审核服务的升级和改进等),高可用 (重中之重,涉及健康检查脚本,Consul 服务快速切换,数据库高可用方案预研测试等),基础服务 (如监控,报警和任务调度等相关服务),基础设置 (如抛弃 CentOS_6 等低版本,磁盘配置统一为 SATA-SSD 等类似的方式)

2) 基础运维:涉及资源交付 (包括上下线,资源扩容等),权限交付 (申请账号,账号权限变更,账号回收等),安装部署 (如数据库软件安装部署,初始化),基础配置 (基础配置,如 ntp,crontab 等),备份恢复 (按照数据备份,数据恢复的基础维度实现基本备份集,基于时间点的数据恢复)

3) 运维优化:对象变更 (需要演进为自动化上线模式),对于大表变更需要集成在线变更工具来实现,此外,重点是做一些相关的优化,如参数优化 (如数据库优化参数,基础配置适配),对象优化 (数据表优化,索引优化),SQL 优化 (执行计划优化,索引建议等),配置优化 (系统配置,服务配置优化等)

这三个维度做好之后,其实会发现一些还是会恨吃力,那就涉及到数据迁移和数据流转,数据本身是在不同类型的环境间流转的,如何保证数据能够稳定,准确的流转也是重要的目标。

4) 数据迁移和数据流转,数据迁移主要实现一键式数迁移,主要包括两个个方面:

(1) 一键式数据库迁移,从 1 个服务器迁移到另外一个服务,一键实现

(2) 数据库版本升级,如从 MySQL 5.5 升级到 5.7,从 5.7 升级到 8.0 等,可以一键实现

此外,数据流转到数据仓库,大数据,如何高效稳定的支持,如何实现实时的数据流转机制和多环境间的快速迁移 / 同步也是重点目标。

对于技术底座而言,首要的目标就是文档,文档可以从上面的四个维度拆分为多种文档, 如规范设计文档,预研文档,方案设计文档,操作文档,案例文档等。

接下来的服务的交付都应该统一为 API 的模式,演进可以从脚本到工具,从工具到 API 的路径来演进。

底座的两大分支是云平台建设和服务建设,云平台建设覆盖面更大,提供的是产品化思维的服务交付,对于技术架构和开发效率的要求较高,这部分不能好高骛远,还是得结合自身情况来提供强大的动力,其中,元数据建设是核心目标,在这个层面元数据要集成,实现流程化管理。

而右侧的服务建设更贴近后端服务,从生命周期的角度来进行实例,数据库,表,字段,索引层面的周期性管理,而提供的辅助服务则是更加贴近运维实际的,比如慢日志优化,巡检服务和故障自愈,和业务侧是一种半透明的开放形式。

“怎么从生命周期的角度来规划数据库运维体系”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注丸趣 TV 网站,丸趣 TV 小编将为大家输出更多高质量的实用文章!

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-07-27发表,共计1700字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)