MySQL-05-管控

管控即自动化运维平台的建设，分为元数据管理、备份管理、实例管理、主机管理、任务管理、日志管理、日常维护。

标准化

  标准化是规模化、自动化的基础。制定标准并使用 saltstack 来维护 DB 服务器基础的软件安装和文件配置规范:

1. 磁盘统一做成 RAID5 模式扩大空间利用率。
2. 统一 RAID 卡读写策略为 WB，IO 调度策略为 deadline，以及其他 SSD IO 方面的优化。
3. 统一目录配置，通过端口进行区分，例如 my3306, my3307，在 my3306 下面创建对应的数据目录、日志目录、运行文件目录，tmp目录等。
4. 每个实例独享一个配置文件，除 server_id , innodb_buffer_pool_size 等参数外其他参数均保持一致。
5. 线上环境的 MySQL 软件目录和版本保持一致。

备份监控

  如果没有统一的入口来查看备份结果是成功还是失败，DBA 对自己维护的数据库的备份有效性一无所知，出现异常问题需要恢复而又恢复不了的时候，会是致命的打击：

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

任务系统

  所有的自动化管理平台中都需要一个核心组件-任务管理系统，主动或者被动进行各种任务调度。并需要支持多种类型的任务：支持按照时间(分钟，小时，每天，星期，月份)，还支持一定间隔的重复性任务。
  任务系统由数据库服务器上的 agent 和下发任务的调度逻辑构成，任务调度的元数据表中记录了所有的任务和任务关联主机的时间策略。通过任务系统，我们彻底的去掉了DB主机上的 crontab 脚本，动态修改任务执行时间、策略以及是否需要执行变得轻而易举。

备份管理

  数据库备份是利用 xtrabackup 做物理备份，经过压缩，然后 rsync 到备份目的机器上，定期远程备份到异地机房。

1. 使用 python 重构底层备份脚本，由 db 服务器上的 agent 执行，添加回调 api 接口用于设置备份任务的运行状态，如果一台主机上存在备份失败的实例，会发送报警到 DBA 的手机，DBA 可以直接在备份系统中查看其备份报错日志，执行重试，省去了登录 DB 主机执行的步骤。
2. 和任务系统耦合，我们去掉依赖 crontab 进行备份的定时任务。
3. 支持在管理页面设置备份时间以及实例是否需要备份，支持动态调整备份的目的机器。
4. 每天针对核心数据库的备份执行有效性校验。如果发现备份校验失败，通过告警平台触发微信或者短信告警，通知 DBA 进行检查并进行重新备份。

主机管理

• 主机元数据是维护数据库实例的基础，包含：主机名，ip地址，机房位置，内存，空间大小等核心信息
• 使用定时任务通过 Zabbix/open-falcon 的 api 定期获取主机信息，比如：磁盘可用空间，内存可用空间等
• 数据库集群运营，比如：空间剩余预警

实例管理

  为了尽可能的发挥主机的性能，往往采用单机多实例的模式，主机与 DB 实例是一对多的关系。通过实例管理系统，我们可以实现如下功能:

1. 查看当前的实例列表，获取实例当前的数据大小，日志大小，主从延迟状态，慢查个数等等。我们还可以通过实例列表设置实例是否启用
2. 新增单个实例，一对主从，添加一个或者多个从库。新增实例的过程是通过 rsync 命令远程备份机或者本地机器上标准的数据库模板(一个预生成且关闭的 mysql 实例)，然后用 my.cnf 模板渲染 server_id,buffer_pool_size 等生成标准 my.cnf 配置文件，执行的具体步骤可以通过管理界面查看，任务调度系统支持部分步骤的失败重试。
3. 实例的主从一致性校验。在 MySQL 主从复制中，有可能因为主从复制错误、主从切换或者应用使用不当等导致主从数据不一致。天都针对核心数据库，进行主从的一致性校验，避免产生线上影响。
4. 实例拆分，用来将之前在同一个实例里面的多个 schema 拆分到不同的实例里面。
5. 每天将实例的元数据进行快照，如慢查数据，数据目录大小等，方便实例的历史数据分析。

日志管理

  日志管理用于维护 slow_log 和 killed_sql(将被 kill 的 sql 写入到具体的指定规则的日志文件中)

• 展示各个业务中慢查询最多的 topN 和对应的慢查分析(pt-query-digest)
• 慢查询超过一定阈值的实例会触发短信报警，及时通知 DBA 和开发关注。
• 展示被 kill 的 SQL 的 topN 情况

元数据管理

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

• binlog 元数据管理主要记录每个实例的每个 binlog 起始时间和结束时间，binlog 保留时长，在进行数据恢复的时候可以快速的定位到某个日志。
• 通过主键溢出校验，我们可以及时的发现哪些表的主键自增已经达到了临界值，避免因主键自增溢出无法插入导致故障。
• 通过提供数据库名、表名、分片键，就可以快速的定位到一个实例，提高实例定位效率

日常维护

  日常维护主要是解决部分低频但是耗时的人肉操作：批量查看实例的某些参数，批量修改配置，紧急的binlog恢复等。

• 批量执行 SQL，智能执行维护的 SQL，例如：需要修改某个参数的值，或者获取某个参数的值，DML 是不允许执行的。
• 批量修改配置文件，例如：调整慢查时间等。
• 解析 binlog，基于开源的 binlog2sql，根据提供的数据库名称，表名，时间段，利用 binlog 元数据查到指定的 binlog 进行解析得到文本文件可以在网页查看和下载。

数据运营

  根据积累的具体业务场景的发展规律（实例数据空间大小、内存大小等）,用这些积累的数据做运营分析，形成趋势图和成本核算。

• 趋势图用于展示数据库总体的空间和内存利用率情况，以及核心业务的增长曲线，方便 dba 对机器资源进行调配。
• 成本核算功能统计各个业务耗费的成本以及占用比例，为业务层决策提供一定的参考。

HA管理

  高可用管理包括：健康检查，故障切换，主动切换，状态监控。

• 提供了完整的 Restful API （前后端分离思想）来管理集群和实例。
• 基于 relay log 解析和基于 GTID 两种方式来处理 MySQL 故障切换时的数据填补问题。
• 主动切换和故障切换在秒级时间内完成。
• 故障转移可以使用 VIP、DNS、中间件等形式，除了切换还可以用来控制客户端访问

其他

  后续在运维方面还需要实现秒级监控，日志审计，实例巡检，实例水平拆分等功能，面向开发方面需要完善数据库性能诊断，自动分析数据库慢查等功能。
  从用户使用交互来看，初级的管控是给 DBA 用的，但是系统最终服务的对象是业务方或者开发，如何提高系统的有效使用率，在交付和维护使用上给开发带来收益也是需要思考和落地的目标。

参考文档

https://cloud.tencent.com/developer/article/1173882