【Mysql】数据库管理员的工作思考

大背景

从去年金融科技部启动“云化工程”以来，辖内地区的应用都走在了被规划的道路，原来部署在物理机上的应用及中间件纷纷迁往VMware虚拟机，由本部统一管理，减轻了各下属机构科技人员的运维压力。

云化工程确实既减少了本机构的科技投入，又增强了协调管理效率，但却对云化工程相关责任人提出了更高的要求，包括上下级间的沟通协调、技术领域的架构设计、功能逻辑的编码实现。

见微知著，未雨绸缪

得益于oracle的主流地位，今年4月份从前任手中接手MYSQL以来，一直都没有发生什么难以应付的事情，现有70+套MYSQL环境，日常的工作也只是安装单机以及维护清单。
虽说备份、监控这两大块，前任都已经做了，但鉴于技术背景与思维的不同，他的方案仍有很多值得我去优化改进的地方。

1. 原有的备份方案

每次新增完数据库实例后，需要手动新增一条信息到清单，再往配置文件中天添加一条备份记录，xxljob定时调度的备份任务会去执行备份shell脚本并将备份文件存储在一台nas主机上。
基于配置文件的备份方案，实现起来较简单只需要用shell脚本就可以完成读取、解析、备份、存储这一系列操作，但由于无法可视化操作、对系统侵入性较高，我可以将其改为基于数据库的备份方案，2022年年初开始实施。

2. 原有的监控方案

除了zabbix对数据库进程与端口的监控外，针对主从复制的机器特别设计了一个监控方案，监控其主备延迟指标，当初日常巡检的一个部分。每小时采集备机上的延时数，如果超过阈值，维护人就会收到报警通知。
这一块暂时不用优化，只需要熟悉其监控了那些指标即可，比如主备延时时间、端口。

以史为镜，可以正衣冠

从上半年“oracle数据库自动备份平台”的运营效果来看，我有以下3点思考：

1. 面向的客户群体都有谁？

平台设计的初衷是非常好的，减轻下属机构科技人员的运维压力。可实际上，他们并没有新增任何备份策略，只有oracle dba一人在笔耕不辍，这样一来它存在的意义就只能是减轻数据库管理员的工作压力了。

2. 备份是为了应对灰犀牛吗？

是的，以防万一是备份的唯一目的，不要等到沧海桑田了才想起曾经拥有过。作为企业员工来说，哪怕只有一次应用数据库无法恢复就算是你乃至你团队的失职，所以备份数据库是没有商量余地的。

3. 对后来的自动化备份平台有何建议？

既然99%的时间都是dba在使用，为便于管理，可以考虑在设计上少一些定制化的功能、多一些统一的规范，比如备份策略只让业务人员填写应用数据库的连接字符串信息和是够开启备份即可，备份后日志的前台显示就不必去大费周章了。

纸上终觉浅，觉知要躬行

本来有想过在原Oracle备份平台中兼容Mysql的，但是这样会使用原平台变得更加臃肿、更加难以管理，所以决定另外构建一套相同架构的自动化备份平台。设计架构和各主要实施步骤见下图：

1、将单个备份任务封装成接口或函数（登录shell并执行远程备份mysql语句，同时转存备份文件）。
2、python读取数据库策略表，需要执行备份时再去调用备份任务接口。
3、备份数据的存储与清理，
4、备份策略的可视化操作，使用公司自动化运维平台。
5、任务调度使用开源工具xxljob。