数据库自动化运维方案Word下载.docx
- 文档编号:14770448
- 上传时间:2022-10-24
- 格式:DOCX
- 页数:9
- 大小:330.14KB
数据库自动化运维方案Word下载.docx
《数据库自动化运维方案Word下载.docx》由会员分享,可在线阅读,更多相关《数据库自动化运维方案Word下载.docx(9页珍藏版)》请在冰豆网上搜索。
从事过大规模化运维的朋友都知道:
标准化是规模化,自动化的基础。
在我们开发MySQL自动化运维平台的之前,面临的主要问题就是各种”不标准”:
OS软件初始化不统一,软件目录结构不标准,配置文件路径不标准,主从配置不对称。
于是我们开始着手制定标准:
OS层面
1、磁盘统一做成RAID5模式扩大空间利用率。
2、统一RAID卡读写策略为WB,IO调度策略为deadline,以及其他SSDIO方面的优化。
数据库层面
1、统一目录配置,通过端口进行区分,例如my3306,my3307,在my3306下面创建对应的数据目录、日志目录、运行文件目录,tmp目录等。
2、每个实例独享一个配置文件,除server_id,innodb_buffer_pool_size等参数外其他参数均保持一致。
3、线上环境的MySQL软件目录和版本保持一致。
有了以上标准和规范,我们花了2个月左右的时间将以前不符合的标准的主机和实例进行改造,并且使用saltstack来维护DB服务器基础的软件安装和文件配置规范。
2.2、ZanDB的技术栈
ZanDB系统采用PythonDjango+Percona-Toolkit+Agent(servant)+Celery+前端相关(JQuery+Ajax)技术,同时利用了缓存Redis和MySQLDB作为存储,整套系统采用的技术栈较简单,实现的功能对于目前来说比较实用。
三、自动化运维之路一期
对于任何具有数据资产的公司而言,数据备份重于一切。
由于历史原因,有赞数据库的备份是由shell脚本堆砌的,没有统一的入口来查看备份结果是成功还是失败,如果DBA对自己维护的数据库的备份有效性一无所知,出现异常问题需要恢复而又恢复不了的时候,对有赞以及有赞的商家而言会是致命的打击。
因此,我们第一期的工作是开发ZanDB备份监控系统。
它的主要功能:
1、实时查看备份的执行情况,当前应备份实例个数,已完成实例数,备份失败的个数。
2、显示每个备份的耗费时长。
3、查看过去5天的备份统计信息,如总个数,大小等。
完成ZanDB备份监控系统开发,我们对备份情况情况有了基本的掌握,之后开始着手设计ZanDB的二期设计研发工作。
四、自动化运维之路二期
在设计ZanDB系统时架构时,我们选择使用B/S架构模式,在数据库服务器上部署我们使用go自研的agent—servant,ZanDB系统通过http服务调度agent执行各种任务,避免数据库服务器通过明文密码直连ZanDB的元数据库,增加系统的健壮性和安全性。
总体上我们将ZanDB的业务逻辑分成了七部分:
元数据管理,备份管理,实例管理,主机管理,任务管理,日志管理,日常维护。
(图2)ZanDB系统设计逻辑架构
4.1、任务系统
所有的自动化管理平台中都需要一个核心组件-任务管理系统,主动或者被动进行各种任务调度。
我们在ZanDB中实现了一个相对健壮的任务调度系统,用于执行实例的备份,元数据收集,实例维护比如添加从库,创建主从实例等工作,该系统支持多种类型的任务:
支持按照时间(分钟,小时,每天,星期,月份),还支持一定间隔的重复性任务。
该任务系统由数据库服务器上的agent-servant和下发任务的调度逻辑构成,任务调度的元数据表中记录了所有的任务和任务关联主机的时间策略。
通过任务系统,我们彻底的去掉了DB主机上的crontab脚本,动态修改任务执行时间、策略以及是否需要执行变得轻而易举。
(图3)任务管理系统
4.2、备份子系统
有赞的数据库备份是利用xtrabackup做物理备份,经过压缩,然后rsync到备份目的机器上,定期远程备份到异地机房。
在一期的基础上,我们完善了备份系统。
1、使用python重构底层备份脚本,由db服务器上的agent执行,添加回调api接口用于设置备份任务的运行状态,如果一台主机上存在备份失败的实例,会发送报警到DBA的手机,DBA可以直接在备份系统中查看其备份报错日志,执行重试,省去了登录DB主机执行的步骤。
2、和任务系统耦合,我们去掉了一期中依赖crontab进行备份的定时任务。
3、通过ZanDB系统设置备份时间以及实例是否需要备份,支持动态调整备份的目的机器。
同时,备份系统每天针对核心数据库的备份执行有效性校验。
如果发现备份校验失败,通过告警平台触发微信或者短信告警,通知DBA进行检查并进行重新备份。
4.3、主机管理
主机元数据是维护数据库实例的基础,包含主机名,ip地址,机房位置,内存,空间大小等核心信息,在ZanDB系统中,我们设置了定时任务通过Zabbix/open-falcon的api获取主机信息,比如磁盘可用空间,内存可用空间等定期更新元数据基本信息,为分配实例提供准确的数据决策。
同时可以做数据库集群数据运营,比如预警空间剩余多少天,为数据库集群扩容提供数据判断。
4.4、实例管理
(图4)实例管理功能
为了尽可能的发挥主机的性能,有赞的数据库采用单机多实例的模式,主机与DB实例是一对多的关系。
通过实例管理系统,我们可以实现如下功能:
1、查看当前的实例列表,获取实例当前的数据大小,日志大小,主从延迟状态,慢查个数等等。
我们还可以通过实例列表设置实例是否启用
2、新增单个实例,一对主从,添加一个或者多个从库。
新增实例的过程是通过rsync命令远程备份机或者本地机器上标准的数据库模板(一个预生成且关闭的mysql实例),然后用f模板渲染server_id,buffer_pool_size等生成标准f配置文件,执行的具体步骤可以通过web界面的流程系统查看,任务调度系统支持部分步骤的失败重试。
3、实例的主从一致性校验。
在MySQL主从复制中,有可能因为主从复制错误、主从切换或者应用使用不当等导致主从数据不一致。
为了提早发现数据的不一致,ZanDB每天都针对核心数据库,进行主从的一致性校验,避免产生线上影响。
4、实例拆分,用来将之前在同一个实例里面的多个schema拆分到不同的实例里面。
5、每天将实例的元数据进行快照,如慢查数据,数据目录大小等,方便实例的历史数据分析。
4.5、日志管理
ZanDB定义的日志管理和慢查询有关,用于维护slow_log和killed_sql,慢查询日志大家都了解,这里解释一下killed_sql。
为了防止实例被慢查拖垮,我们为每个实例启用类似pt-killer的工具—sql-killer进行实时监控,将被kill的sql写入到具体的指定规则的日志文件中。
大多数DBA优化的SQL路径是登陆机器,查看慢查询日志,登陆实例,获取表结构,explainsql,检查执行计划。
对于规模化的DB运维而言,如果只能通过登录每台DB主机才能检查慢查询是一件非常痛苦的事情。
为了解放DBA的双手,同时更好的发现和优化慢日志,保障DB的稳定性,ZanDB日志系统由此诞生,主要做TopN展示和慢查分析。
我们在收集实例元数据的过程中会去统计慢查和被kill的SQL的记录数并更新到ZanDB的元数据中,通过页面展示各个业务中慢查询最多的topN。
当然我们也设定慢查询报警阈值,慢查询超过一定阈值的实例会触发短信报警,及时通知DBA和开发关注。
(图5)慢查询系统
有了慢查询的数据之后如何解决”不在登陆主机查看慢查sql”呢?
我们的系统每天会将慢查询日志做轮转切割,每天产生一个日志文件,ZanDB通过agent调用pt-query-digest分析指定的慢查日志并返回给ZanDB的页面端,展示表结构,慢sql,对应的执行计划,以及表的大小信息。
系统要获取慢查详情的时候,通过调用pt-query-digest,分析慢日志文件,先将结果存到对应的实例slowlog里,系统下次再获取慢查的时候,如果发现该日期的慢查已经存在分析后的结果,直接返回。
同时,日志管理里面还包含了被kill的SQL的top情况,和慢查是类似的。
4.6、元数据管理
(图6)分片信息查询
元数据管理包含了binlog元数据、主键的溢出校验,分片信息信息等。
binlog元数据管理主要记录每个实例的每个binlog起始时间和结束时间,binlog保留时长,在进行数据恢复的时候可以快速的定位到某个日志。
通过主键溢出校验,我们可以及时的发现哪些表的主键自增已经达到了临界值,避免因主键自增溢出无法插入导致故障。
由于我们商品,交易等核心库是分库的,分析慢查,问题定位的时候,需要根据分片键找到对应的实例ip:
port。
我们开发了一个分片元数据查询功能,只要提供数据库名,表名,分片键,就可以快速的定位到一个实例,减少之前人工计算的过程。
4.7、日常维护
(图7)日常维护功能界面
日常维护主要是解决部分低频但是耗时的人肉操作,批量查看实例的某些参数,批量修改配置,紧急的binlog恢复等。
批量执行SQL是选择一批实例,执行维护的SQL。
例如,需要修改内存中某个参数的值,或者获取参数的值。
这个SQL只允许维护相关的,DML是不允许执行的。
批量修改配置和执行SQL类型的修改配置类似,不同的是,修改配置是会同步变更配置文件,永久生效,同时也修改内存,例如调整慢查时间等。
解析binlog是基于开源的binlog2sql做的,根据提供的数据库名称,表名,时间段,利用binlog元数据查到指定的binlog进行解析得到文本文件可以在网页查看和下载,在解决突发的开发误操作需要紧急恢复过程中特别有效。
4.8、数据运营
ZanDB从开发落地到现在已经半年多时间了,积累了一定量的实例数据空间大小,内存大小等,我们利用这些积累的数据做运营分析,开发了趋势图和成本核算功能。
趋势图用于展示数据库总体的空间和内存利用率情况,以及核心业务的增长曲线,方便dba对机器资源进行调配。
成本核算功能统计各个业务耗费的成本以及占用比例,为业务层决策提供一定的参考。
4.9、HA管理
有赞的数据库高可用经历了两个阶段。
第一个阶段是基于keepalived+vip架构的HA,但是我们也遇到了磁盘io抖动导致脚本检查失败切换和基础网络arp广播限速导致ha切换失效的问题。
这种方式也不可避免的会有脑裂问题。
第二阶段我们自研了基于go语言的HA管理工具hamster。
hamster有强大的集群管理能力,可以同时维护大量MySQL集群,进行健康检查,故障切换,主动切换,状态监控。
提供了完整的RestfulAP
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 数据库 自动化 方案
![提示](https://static.bdocx.com/images/bang_tan.gif)