微店 MySQL 自动化运维实践

标签: tuicool | 发表时间:2016-12-16 08:00 | 作者:
出处:http://itindex.net/admin/pagedetail

前言

互联网时代,数据库如何满足敏捷开发,敏捷交付的要求。传统靠DBA人肉执行的方式,在面对大量业务需求时,DBA手速再快,记忆力再好估计也不能提供好的数据库服务。在介绍自动化运维之前,我们来了解下是怎么使用数据库的。

数据库的使用方式主要有两种:

应用混合部署(实例):有新数据库需求时,很多人都会选择找个实例,建个数据库和帐号提供给业务。好处是能快速提供数据库服务,这种方式在数据库运维的过程中会出现一些问题:第一,相互影响,个别应用有问题会影响所有数据库;第二, 应用DB的性能指标(qps, tps, rt...)不能获取;第三,定位问题源困难;第四,资源使用不合理。为了解决以上问题,最终会有拆库的过程,拆过库的同学都知道,一个拆库动作需要确认很多东西,所花费的时间是非常多的,过程中容易产生故障。

应用独享(实例):在虚拟化,微服务深入人心的今天,应用独享实例是数据库给出的解决办法。我们做到的是所有应用独享实例(分库分表的应用如:分成32个库的应用,业务初期阶段会分布在几个实例中,业务确实需要更多资源时再进行自动化拆库扩容)。这种方式需要大量的实例,传统单机单实例的运维体系就需要演变成单机多实例的方式。

由此引出会有一系列问题需要解决:如何快速提供数据库服务?如何避免数据库资源合理分配?数据库监控怎么做?多实例数据库HA怎么做?

MySQL的标准化与自动化

我们实现的MySQL自动化运维体系能够解决规模化的痛点,主要包括实例创建、部署、监控、备份、HA切换、迁移、扩容等的自动化,所有模块的主发点是要能“自动化”的方式运作,尽量少的人为参与。

一、标准化

数据库上了一定规模后,数据库的各方面都需要标准规范起来,才能接下去做自动化。实例上的标准化我们主要做了以下几点:

1.应用独享实例

2.数据库M<==>S结构,备库不提供业务流量(异地容灾除外)

很多人会选择一主多备,备库提供读流量。这种架构引起的故障挺多的,因为备库一定会存在延时,备库机器也会挂掉。事实上大部分时候流量都在主库是没问题,如果确实主库压力真的太大怎么办,我们应该及时发现问题并作出应对(方法可以是缓存+拆库)。

3.MySQL标准化(带thread_pool 功能MySQL)

  • 数据库版本一致

  • “相同”的my.cnf(除个别个性参数如server_id,buffer_pool_size等)

  • 文件目录一致

二、构建MySQL自动化运维体系

一套很好的大规模运维体系DBManage,整体思路是让一切自动化起来,不需要打通机器间的信任关系,避免或减少人为参与。

1.多实例创建

一台机器上面开启多个不同的端口,运行多个MySQL服务进程,共用MySQL程序,使用不同配置文件,提供服务。

关键点:

  • “相同”的my.cnf(除个别个性参数如server_id,buffer_pool_size等)

  • 数据文件目录标准化

  • 创建实例(1.初始化一个标准的数据库,2.新建实例通过rsync控制速率,通过修改 " my.cnf " 文件新建不同实例,因为mysql_install_db安装新实例会占用过多IO)

2. 元数据与监控

数据库监控没有采用类似“lepus”的方式,中心控制的方式对于规模化精细华数据库管理冲突。中心化存在问题1:增加实例需要手动录入;问题2:不能获取响应时间RT(tcprstat);问题3:不能获取主机性能数据等等。我们采用自研 db_agent 实现实例的自动发现,各项元数据及性能数据采集,告别人工处理。

每台数据库服务器上运行db_agent;自动发现实例,自动采集实例数据,主机数据,磁盘数据,自动添加监控。db_agent主要实现以下功能。

  • 采集实例信息(数据库列表,复制信息,表元数据等等)

  • 心跳更新(每秒更新,因为show slave status的延时是不可靠的)

  • 数据库性能数据( QPS, TPS......)

  • 数据库响应时间RT(tcprstat)

  • 实时慢SQL

  • 主机性能数据(告别zabbix)

3. 备份

数据库机器部署备份脚本(不区分是否主备机器),告别手动配置。

  • 只备份备库(备份前判断脚色)

  • 多实例并发控制(控制速率及时间)

  • 直接写入hdfs 或server(推荐hdfs存储)

4. 本地执行agent

远程操作DB机器(创建实例,恢复数据库,etc),通过自定义一些消息调起DB机器对应脚本进行操作

5. 监控告警

基于db_agent采集数据,性能画图及告警。性能数据写入graphite

6. MySQL高可用

传统的使用MHA做MySQL HA架构是比较通用的方案,主要特点:通过Health Check 监控MySQL集群,应用通过VIP访问MySQL,VIP通过keepalive选主。这里不展开这种方式和一些改进型(zookeeper +MHA)的痛点,主要讲下多实例下基于zookeeper是怎么实现MySQL自动化高可用。

改造后的HA架构,跟通常架构的区别在于我们去掉了MySQL集群里的VIP,使用VDDS替代;完全去掉MHA。通过zookeeper分布式,实现ha_console的高可用。

整个流程是

  • VDDS(微店分布式数据库) 新建应用配置

  • ha_agent向zookeeper注册临时节点,并实时更新实例信息。

    {

    "source_db_role": "slave",

    "master_instance": "192.168.1.12_3306",

    "repl_status": "ok",

    "h_time_delay": 0,

    "repl_delay": 0,

    "last_change_time": "2016-10-15-01:00:45"

    }

  • ha_console根据zookeeper节点信息构造切换元数据(包括延时,切换对象,复制状态)

    "192.168.1.11_3306": "{

    "source_db_role": "master",

    "master_instance": "192.168.1.12_3306",

    "repl_status": "ok",

    "h_time_delay": 0,

    "repl_delay": 0,

    "last_change_time": "2016-10-15-01:00:45"

    }"

  • ha_console监听alive目录临时节点

  • alive目录临时节点消失进行切换(判断延时及复制状态,不符合条件不切换),切换VDDS和数据库

  • 切换前记录切换信息(slave:master_log_file: mysql-bin.000007,exec_master_log_pos: 57830。主库恢复后,用来生成日志解析)

场景一:实例Crash,实例所在的服务器正常运行,ha_agent运行正常

实例Crash,ha_agent 正常运行,主动删除zookeeper 临时节点,ha_console 判断数据库角色,是主库走切换流程。原实例起来之后,作为备库运行。

场景二:实例所在的主机Crash。(实例和ha_agent同时Crash)

此时,由于ha_agent和实例同时Crash,zookeeper到ha_agent间的通讯失败。zookeeper 等待超过租约的时间,ha_console 判断数据库角色,是主库走切换流程。原实例起来之后,作为备库运行。

场景三:实例正常,网络异常

网络异常会发生大量实例掉线或部份异常。大量节点异常:ha_console判断时间范围内异常实例数量,超过阀值不进行切换,同时切换过程:切换脚本会去判断数据库状态,避免误切。(zookeeper client 连接掉线后,尽管实例及ha_agent正常运行,节点不能重用必须等待超时)

特点:完全不需要人工建入,切换元数据自动构建,所有实例自动注册,构造完整的切换元数据,避免了繁锁的配置或配置出错导致不能切换。

7.DBTask

通过DBTask 替代人工操作。实现了数据库创建,配置VDDS, 数据库迁移,拆库扩容,恢复等等。整体思路是分解动作,每个脚本干一件事,再串起所有脚本。以数据库迁移为例我们可以分解为各个子任务,串起任务就是一个完整的自动化数据库迁移任务。

数据库迁移:

  • 申请可用资源

  • 实例创建

  • 恢复备库A

  • 恢复备库B

  • 配置数据源(VDDS)

  • 切换前检查

  • 切换

  • 清除VDDS配置

  • 关闭老实例

数据库资源申请:

  • 申请可用资源

  • 实例创建

  • 新建库,MySQL帐号

  • 配置数据源(VDDS)

成果及展望

全套自动化运维体系采用:后台由python+shell+go(实时慢sql解析部分);前端采用laravel+angularjs。 目前单机日常环境运行100+实例,agent的资源占用不多;业务申请数据库资源<1分钟完成;自动化拆库(部份老的合在一起的还是要拆的:sob:)等等。另外随着MySQL自动化运维的深入,慢慢的发现这将会演变数据库成私有云平台。对于如何更好的服务业务,如何诊断业务数据库等等都需要我们去完善。

参考资料

python socket通信:

https://github.com/chris-piekarski/python-json-socket 

python hdfs

https://pypi.python.org/pypi/hdfs/ 

响应时间(rt):

https://github.com/Lowercases/tcprstat 

python zookeeper:

https://github.com/python-zk/kazoo 

go tidb解析sql 中的表(用来合并分表)

https://github.com/pingcap/tidb 

相关 [mysql 自动化 运维] 推荐:

微店 MySQL 自动化运维实践

- - IT瘾-tuicool
互联网时代,数据库如何满足敏捷开发,敏捷交付的要求. 传统靠DBA人肉执行的方式,在面对大量业务需求时,DBA手速再快,记忆力再好估计也不能提供好的数据库服务. 在介绍自动化运维之前,我们来了解下是怎么使用数据库的. 数据库的使用方式主要有两种:. 应用混合部署(实例):有新数据库需求时,很多人都会选择找个实例,建个数据库和帐号提供给业务.

MGR复制架构+自动化运维平台,汽车之家MySQL高可用建设实践

- -
陶会祥,2020年加入汽车之家,任职智能数据中心-云平台部,负责之家数据库的运维及RDS产品研发工作,致力于为公司提供安全,稳定,可靠的数据库服务. MySQL具有开源免费,运维简单,性能好等优点,是在汽车之家使用最多的一种数据库. 数据库作为应用的后端存储,承担着数据持久化存储的功能,是应用可以正常对外提供服务的关键组件,数据库的高可用非常重要.

一文详解Ansible自动化运维

- - DockOne.io
Ansible是近年来越来越火的一款开源运维自动化工具,通过Ansible可以实现运维自动化,提高运维工程师的工作效率,减少人为失误. Ansible通过本身集成的非常丰富的模块可以实现各种管理任务,其自带模块超过上千个. 更为重要的是,它操作非常简单,即使小白也可以轻松上手,但它提供的功能又非常丰富,在运维领域,几乎可以做任何事.

大型企业 Unix 服务器的自动化运维

- Edwin - IBM developerWorks 中国 : Linux : Articles,Tutorials
企业主机服务器日常运维工作中,经常需要登录并以 root 方式执行系统操作,如果在主机数量少的情况下,手工方式登录并执行效率尚可,但如果主机数量庞大(如笔者运维的国外客户服务器数量达 2000+),依次对一台台服务器进行手工操作工作量巨大且出错概率与主机数量成线性增大. 本文分析了在大数量企业服务器情况下,利用 shell 管道,Java SSHD 开源包,Expect 脚本三种方式实现自动登录并执行系统运维操作,三种方式分别适用于不同的场景,可以满足绝大多数企业主机服务器自动化运维的工作内容,大大减轻了系统管理员的工作量,同时降低了操作失误的风险.

自动化运维之企业实际案例分析

- - IT技术博客大学习
标签:   puppet   自动化. 随着IT行业的迅猛发展,传统的运维方式靠大量人力比较吃力,近几年自动化运维管理快速的发展,得到了很多IT运维人员的青睐,一个完整的自动化运维包括系统安装、配置管理、服务监控三个方面. 那今天咱们大家一起来学习一下puppet实际运维中的案例. 仅供参考,欢迎大家提更多的意见.

从分布式存储设计到自动化运维

- - 五四陈科学院-坚信科学,分享技术
以下内容由 [五四陈科学院]提供. http://www.infoq.com/cn/articles/nosql-dynamo 三年前在infoq发表的一篇关于两种特别有代表性的分布式存储的设计思路解析,三年过去了,今天再来总结看看这几年的变化. 实际上,这三年,还是两个东西,一直没有冒出来更牛B的东西.

自动化运维工具Ansible详细部署

- - 开源软件 - ITeye博客
ansible是新出现的自动化运维工具,基于Python开发,集合了众多运维工具(puppet、cfengine、chef、func、fabric)的优点,实现了批量系统配置、批量程序部署、批量运行命令等功能. ansible是基于模块工作的,本身没有批量部署的能力. 真正具有批量部署的是ansible所运行的模块,ansible只是提供一种框架.

运维角度浅谈MySQL数据库优化

- - 程序师
一个成熟的数据库架构并不是一开始设计就具备高可用、高伸缩等特性的,它是随着用户量的增加,基础架构才逐渐完善. 这篇博文主要谈MySQL数据库发展周期中所面临的问题及优化方案,暂且抛开前端应用不说,大致分为以下五个阶段:. 项目立项后,开发部根据产品部需求开发项目,开发工程师工作其中一部分就是对表结构设计.

来自Facebook的一些MySQL运维经验

- - 运维派
每台机器都使用多实例的模型. 每个机器放多个实例,每个实例放多个DB. 一些信息可以参考: https://www.youtube.com/watch?v=UBHcmP2TSvk. 多实例之间没有进行资源隔离,这么做是让每个实例都能发挥最大性能. 目前大部分核心业务已切换成MyRocks引擎,在机器硬件配置不变的情况,约可节省一半机器.

【转载】单表60亿记录等大数据场景的MySQL优化和运维之道 | 高可用架构

- - 数据库 - ITeye博客
此文是根据杨尚刚在【QCON高可用架构群】中,针对MySQL在单表海量记录等场景下,业界广泛关注的MySQL问题的经验分享整理而成,转发请注明出处. 扩展性“好”,在一定阶段扩展性好. 性能可以满足互联网存储和性能需求,离不开硬件支持. 上面这几个因素也是大多数公司选择考虑MySQL的原因. 不过MySQL本身存在的问题和限制也很多,有些问题点也经常被其他数据库吐槽或鄙视.