有赞 MySQL 自动化运维之路 — ZanDB

转自：https://tech.youzan.com/youzan-mysql-auto-ops-road/

 

1、前言

在互联网时代，业务规模经常出现爆发式的增加。快速的实例交付，数据库优化以及备份管理等任务都对DBA产生了更高的要求，单纯的凭借记忆力去管理那几十套DB已经再也不适用。那么如何去批量管理这些实例的备份、元数据、定时脚本和快速实例交付就成了急需解决的的问题。

2、数据库的标准化

在实现MySQL的自动化运维的过程当中，最痛苦的无非是目录的不统一，配置文件的混乱以及DB主机的不标准，而这些不标准的环境会让自动化运维的路途荆棘重重。因此首先咱们将相应的DB主机以及目录作了标准化，将之前不符合的标准的主机和实例进行改造。

1. 一台机子上全部实例，都是在统一的目录下，经过端口进行区分，例如my3306,my3307。而后在my3306下面建立对应的数据目录、日志目录、运行文件目录等
2. 每一个实例独享一个配置文件，除serverid , bufferpool_size等参数外其余参数保持一致
3. 线上环境的MySQL软件目录和版本保持一致

3、自动化运维之路一期

在一开始的时候，咱们须要着手解决目前的最要紧的事情：备份。对于DBA来讲，备份重于一切。若是DBA对本身维护的数据库的备份状况都一无所知，那么总有一天，你会遭遇数据丢失的灾难。所以，咱们开始第一期的工做，ZanDB 备份监控系统。 它实现的主要功能是：

1. 实时查看备份的状况，当前应备份实例个数，已完成实例数
2. 显示每一个备份的耗费时长
3. 查看过去5天的备份统计信息，如总个数，大小等

4、自动化运维之路二期

在实现了ZanDB备份监控系统以后，咱们着手开始设计ZanDB 的二期设计研发工做。

在设计ZanDB的过程当中，咱们将主要功能分红了七部分：备份管理，实例管理，主机管理，任务管理，元数据管理，日志管理，平常维护。

一、任务系统

为了实现实例的备份、元数据、定时脚本等工做，必需要有一个健壮的任务调度系统。该任务系统支持多种类型的任务：天天的定时任务，每一个星期的定时任务，每月的定时任务，还支持必定间隔的重复性任务。

该任务系统由一个执行任务的agent和下发任务的调度系统完成，任务调度系统中记录了全部的任务和任务下主机的时间策略。

经过任务系统，咱们完全的去掉了db主机上的crontab 脚本，修改任务执行时间、策略以及是否须要执行变得垂手可得。

二、备份管理

在一期的基础上，咱们完善了备份系统。经过和任务系统相结合，能够轻松的设置备份的时间以及备份的实例，是否须要备份等，保证了在业务低峰期执行备份操做。

备份操做由agent执行，备份成功失败经过相应的回调地址设置状态。若是一台主机上存在备份失败的实例，能够直接在备份系统中查看其备份报错日志，执行重试，省去了频繁登陆DB主机的痛苦。

同时，备份系统天天针对核心数据库的备份执行校验操做。若是发现备份校验失败，经过告警平台触发微信或者短信的告警，方便维护人员第一时间知道是否存在备份失效的状况。

三、主机管理

主机的元数据是数据库实例的基础。在进行主机新增的时候，ZanDB 可以自动的链接Zabbix 获取主机信息，例如磁盘大小，磁盘可用空间，内存可用空间等。

四、实例管理

为了尽量的发挥主机的性能，咱们在一台主机上部署了多个实例，所以主机和实例是一对多的关系。

经过实例管理系统，咱们能够实现以下功能：

1. 查看当前的实例列表，获取实例当前的数据大小，日志大小，主从状态，是否存在慢查，被kill的SQL，实例历史信息性能信息等等。
2. 新增单个实例，一对实例，针对一个实例/一对主从添加从库。新增实例的过程是经过rsync 标准的数据库模板，而后用my.cnf模板渲染生成标准my.cnf配置文件，执行的具体步骤能够经过流程系统查看 ，支持失败重试。
3. 实例的主从校验。在MySQL主从复制中，有可能由于主从复制错误、主从切换或者软件的BUG等致使主从数据不一致。为了提前发现数据的不一致，就须要天天都针对核心数据库，进行主从的一致性校验，避免产生线上影响。
4. 实例拆分，用来将以前在同一个实例里面的多个schema 拆分到不一样的实例里面
5. 天天将实例的元数据进行快照，如慢查数据，数据目录大小等，方便实例的历史数据分析。

五、日志管理

数据库运行最多的就是SQL，优化SQL是DBA的职责。面对那么多的实例，若是没有一个日志系统，只能经过登陆每台DB主机去发现慢查将是一件很是痛苦的事情。为了解放DBA的双手，同时更好的发现和优化慢日志，保证DB的稳定性，ZanDB 日志系统由此诞生。

首先实例元数据收集的过程当中，会统计慢查和被kill的SQL的数据，而后更新到实例的元数据中。经过实例元数据的慢查信息，获取昨日的TOP 慢查。

那么如何去获取慢查呢？固然要经过伟大的agent去获取慢查日志。慢查在天天都会进行rotate，产生一个新的慢日志文件。系统要获取慢查详情的时候，经过调用pt-query-digest，分析慢日志文件，将结果缓存起来，进行返回。系统下次再获取慢查的时候，若是发现该日期的慢查已经存在分析后的结果，直接返回。

同时，日志管理里面还包含了被kill的SQL的top状况，和慢查是相似的。

六、元数据管理

元数据管理包含了binlog 元数据、主键的溢出校验，分片信息等。

经过binlog 元数据管理，实现了全部实例的binlog信息管理。binlog元数据记录了实例的每一个binlog起始时间和结束时间，binlog 保留时长，在进行数据恢复的时候能够快速的定位到某个日志。

经过主键溢出校验，咱们能够及时的发现哪些表的主键自增已经达到了临界值，避免因主键自增溢出没法插入致使故障。

因为交易等核心库数据量很是大，分析慢查等相关信息的时候，须要根据分片键找到对应的实例。咱们开发了一个分片元数据查询功能，只要提供数据库名、分片id和分片数量，就能够快速的定位到一个实例，大大的方便了DBA，实现了问题的快速定位。

七、平常维护

平常维护主要是经过agent执行，包括了批量执行SQL，批量修改配置等。

批量执行SQL是选择一批实例，执行维护的SQL。例如，须要修改内存中某个参数的值，或者获取参数的值。这个SQL只容许维护相关的，DML 是不容许执行的。

批量修改配置和执行SQL类型的修改配置相似，不一样的是，修改配置是会同步变动配置文件，永久生效，同时也修改内存，例如调整慢查时间等。

5、展望

整套ZanDB 系统是采用了Python Django + Percona-Toolkit + Agent + 前端相关技术，同时利用了缓存Redis 和 MySQL 后端DB，整套系统采用的技术栈较简单，实现的功能对于目前来讲比较实用。后续会加入数据库性能诊断，自动分析数据库慢查，获取关键信息，自动化拆库等功能。相信随着自动化的深刻，DBA的手动重复操做将愈来愈少，将有限的时间投入到更有价值的事情上去。

 
如无特殊说明，本文版权归 本文做者及有赞技术团队 全部，采用 署名-非商业性使用 4.0 国际许可协议 进行许可。
转载请注明：来自有赞技术团队博客 http://tech.youzan.com/youzan-mysql-auto-ops-road/