数据库自动化运维方案.docx

《数据库自动化运维方案.docx》由会员分享，可在线阅读，更多相关《数据库自动化运维方案.docx（15页珍藏版）》请在三一办公上搜索。

1、数据库自动化运维方案一前言有赞作为新零售”的软件服务供应商，随着业务的不断发展，从第一批几十家商户到现在300万商 家，涉及零售，美业，餐饮，自媒体等众多商家，业务规模以及访问量爆发式增长。一方面给后端数据库带来的影响是服务器数量和DB实例的数据量出现成倍增加。各种业务需求:快 速交付实例，慢查询优化以及备份恢复管理等都给DBA的日常运维支持带来更高的要求。另一方面 最开始以excel作为CMDB管理数据库实例的纯人肉运维又给高效的数据库运维带来阻碍。本文介绍有赞DBA研发的数据库自动化管理平台-ZanDB，解决上面的业务方发展中遇到的问题,抛砖引玉，希望能给面临同样需求的同行带来帮助。的主机

2、内存斑盘使用建分皿&3 g皿瑚；獭0 2 由职州2Cn?i2fe20i,1 砌2CI mil 20讽也 囤训团的 520171213 4$蠕AO Jhipo伽m ngqliong Daanboartl3 理 E任HUW g理n主机雀理 EM 理 番知I理5hD* 25 * 切tffeiSearch. KME 理 n* IF任携名或访失般执行中札MX曰用?急任碧旭理-7主4g虹GF 90D0-Of CJfO任归查看6墓职迎打近幅的元甚:面ra oflV*O任舅岳更&或耻琳息cr aqu*a E郭ft护dy oadiiaB成率现1跋窕.哗杼Qt 570D -M口主机怪理SKWfng 1015PtH

3、V-OUShAWlC -4- IE（图3）任务管理系统4.2,备份子系统有赞的数据库备份是利用xtrabackup做物理备份，经过压缩，然后rsync到备份目的机器上，定期远程备份到异地机房。在一期的基础上，我们完善了备份系统。1、使用python重构底层备份脚本，由db服务器上的agent执行，添加回调api接口用于设 置备份任务的运行状态，如果一台主机上存在备份失败的实例，会发送报警到DBA的手机，DBA可 以直接在备份系统中查看其备份报错日志，执行重试，省去了登录DB主机执行的步骤。2、和任务系统耦合，我们去掉了一期中依赖crontab进行备份的定时任务。3、通过ZanDB系统设置备份时

4、间以及实例是否需要备份，支持动态调整备份的目的机器。同时，备份系统每天针对核心数据库的备份执行有效性校验。如果发现备份校验失败，通过告警平台触发微信或者短信告警，通知DBA进行检查并进行重新备份。4.3、主机管理主机元数据是维护数据库实例的基础，包含主机名，ip地址，机房位置，内存，空间大小等核心信息，在ZanDB系统中，我们设置了定时任务通过Zabbix/open-falcon的api获取主机信息，比如磁盘可用空间，内存可用空间等定期更新元数据基本信息，为分配实例提供准确的数据决策。同时可以做数据库集群数据运营，比如预警空间剩余多少天，为数据库集群扩容提供数据判断。4.4 ,实例管理ZanD

5、B woolO DtuitxHudo买隅列聂 .虚本IE理MySQL实例堆护& wcrn 直度Hast =箱事样=J AM：iSackTn:诅汨Portappnair-eAppfy Th*Ha atPOflTAPPStHlEBeginCre-utorGlKiorHuffier Port啊 F； y FE33DT3017-12-15 1B：Q12fr27-12-15 13：5S：1BS3Dfasm2017-12-16 2C:07:4a（图4）实例管理功能为了尽可能的发挥主机的性能，有赞的数据库采用单机多实例的模式，主机与DB实例是一对多的 关系。通过实例管理系统，我们可以实现如下功能1、查看当前

6、的实例列表，获取实例当前的数据大小，日志大小，主从延迟状态，慢查个数等等。我 们还可以通过实例列表设置实例是否启用2、新增单个实例，一对主从，添加一个或者多个从库。新增实例的过程是通过rsync命令远程备份 机或者本地机器上标准的数据库模板（一个预生成且关闭的mysql实例），然后用f模板渲染 server_id,buffer_pool_size等生成标准f酉己置文件，执行的具体步骤可以通过web界面的 流程系统查看，任务调度系统支持部分步骤的失败重试。3、实例的主从一致性校验。在MySQL主从复制中，有可能因为主从复制错误、主从切换或者应用 使用不当等导致主从数据不一致。为了提早发现数据的不

7、一致ZanDB每天都针对核心数据库，进行 主从的一致性校验，避免产生线上影响。4、实例拆分，用来将之前在同一个实例里面的多个schema拆分到不同的实例里面。5、每天将实例的元数据进行快照，如慢查数据，数据目录大小等，方便实例的历史数据分析。4.5、日志管理ZanDB定义的日志管理和慢查询有关用于维护slow_log和killed_sql，慢查询日志大家都了解， 这里解释一下killed_sql。为了防止实例被慢查拖垮，我们为每个实例启用类似pt-killer的工具一 sql-killer进行实时监控，将被kill的sql写入到具体的指定规则的日志文件中。大多数DBA优化的SQL路径是登陆机器

8、，查看慢查询日志，登陆实例，获取表结构，explain sql， 检查执行计划。对于规模化的DB运维而言，如果只能通过登录每台DB主机才能检查慢查询是一 件非常痛苦的事情。为了解放DBA的双手，同时更好的发现和优化慢日志，保障DB的稳定性，ZanDB日志系统由此诞生，主要做TopN展示和慢查分析。我们在收集实例元数据的过程中会去统计慢查和被kill的SQL的记录数并更新到ZanDB的元数 据中，通过页面展示各个业务中慢查询最多的topN。当然我们也设定慢查询报警阈值，慢查询超过 一定阈值的实例会触发短信报警，及时通知DBA和开发关注。有了慢查询的数据之后如何解决不在登陆主机查看慢查sql”呢？

9、我们的系统每天会将慢查询日志 做轮转切割，每天产生一个日志文件，ZanDB通过agent调用pt-query-digest分析指定的慢查 日志并返回给ZanDB的页面端，展示表结构，慢sql，对应的执行计划，以及表的大小信息。系统要获取慢查详情的时候，通过调用pt-query-digest，分析慢日志文件，先将结果存到对应的实 例slow log里，系统下次再获取慢查的时候，如果发现该日期的慢查已经存在分析后的结果，直接 返回。同时，日志管理里面还包含了被kill的SQL的top情况，和慢查是类似的。4.6、元数据管理（图6）分片信息查询元数据管理包含了 binlog元数据、主键的溢出校验，分

10、片信息信息等。binlog元数据管理主要记录每个实例的每个binlog起始时间和结束时间,binlog保留时长，在进 行数据恢复的时候可以快速的定位到某个日志。通过主键溢出校验，我们可以及时的发现哪些表的主键自增已经达到了临界值，避免因主键自增溢出 无法插入导致故障。由于我们商品，交易等核心库是分库的，分析慢查，问题定位的时候，需要根据分片键找到对应的实 例ip:port。我们开发了一个分片元数据查询功能，只要提供数据库名表名，分片键，就可以快速的定 位到一个实例，减少之前人工计算的过程。4.7、日常维护（图7）日常维护功能界面日常维护主要是解决部分低频但是耗时的人肉操作，批量查看实例的某些参

11、数，批量修改配置，紧急 的binlog恢复等。批量执行SQL是选择一批实例，执行维护的SQL。例如，需要修改内存中某个参数的值，或者获 取参数的值。这个SQL只允许维护相关的，DML是不允许执行的。批量修改配置和执行SQL类型的修改配置类似，不同的是，修改配置是会同步变更配置文件，永久 生效，同时也修改内存，例如调整慢查时间等。解析binlog是基于开源的binlog2sql做的，根据提供的数据库名称，表名，时间段，利用binlog 元数据查到指定的binlog进行解析得到文本文件可以在网页查看和下载，在解决突发的开发误操 作需要紧急恢复过程中特别有效。48,数据运营ZanDB从开发落地到现在

12、已经半年多时间了，积累了一定量的实例数据空间大小，内存大小等我们利用这些积累的数据做运营分析，开发了趋势图和成本核算功能。趋势图用于展示数据库总体的空间和内存利用率情况，以及核心业务的增长曲线，方便dba对机器 资源进行调配。成本核算功能统计各个业务耗费的成本以及占用比例，为业务层决策提供一定的参考。4.9、HA管理有赞的数据库高可用经历了两个阶段。第一个阶段是基于keepalived + vip架构的HA,但是我们也遇到了磁盘io抖动导致脚本检查失 败切换和基础网络arp广播限速导致ha切换失效的问题。这种方式也不可避免的会有脑裂问题。第二阶段我们自研了基于go语言的HA管理工具hamste

13、ro hamster有强大的集群管理能力，可 以同时维护大量MySQL集群进行健康检查故障切换主动切换状态监控。提供了完整的Restful API来管理集群和实例。在高可用方面，总体原理上类似MHAo实现了基于relay log解析和基于GTID两种方式来处理 MySQL故障切换时的数据填补问题。主动切换和故障切换通常在秒级时间内就能完成。高可用体系 还结合了我们的proxy来控制客户端访问。数据库切换不再使用vip，避免了之前的arp导致的切 换失效，也不再受arp不能跨网络的限制，为实现有赞IT基础架构双机房容灾打下基础。五、展望目前开发完成的ZanDB系统能够解决70%左右的人肉运维工作，但是距离完全的自动化还是有一 定的差距，后续在运维方面还需要实现秒级监控，日志审计，实例巡检，实例水平拆分等功能，面向 开发方面需要完善数据库性能诊断，自动分析数据库慢查等功能。从用户使用交互来看，现在的ZanDB更多的是给DBA用的，但是系统最终服务的对象是业务方或 者开发，如何提高系统的有效使用率，在交付和维护使用上给开发带来收益也是我们要思考和落地的 目标。最后，有赞的业务正在快速发展，我们要走的路还很长，这路上挑战与机遇并存，我们需要更多优秀 的运维人才加入有赞，和我们一起构建稳定，高效的IT基础设施。