数据恢复咨询热线:400-666-3702  

欢迎访问南京兆柏数据恢复公司,专业数据恢复15年

兆柏数据恢复公司

 行业新闻

 当前位置: 主页 > 行业新闻

【技术头条】京东数据库演变及MySQL运维自动化

浏览量: 次 发布日期:2023-08-17 21:48:51

【技术头条】京东数据库演变及MySQL运维自动化

个人简介 李京生,从事互联网运维管理、数据库管理16年,京东开源数据库运营部总监,全面负责京东开源数据库相关工作。2005~2011任百度首席DBA,推动百度数据库技术持续发展;2011年底加入京东,积极发展京东数据库技术,进行技术创新,带领团队平稳护航2012~2015年8次6.18、11.11大促。致力于电商数据库设计、优化、多中心多活交易、分布式数据库开发、超大规模下数据库运维自动化、自助化工作。个人荣获京东年度最佳舵手、优秀总监、优秀个人、金牌讲师等多项奖项。主题简介 京东数据库从收费数据库为主到现在以MySQL等开源数据库为主的演变;京东MySQL数据库在多交易中心部署、超大规模下如何进行管理:涉及自动化部署、自动化切换、监控智能分析、故障自动处理、性能优化处理等。精彩实录 技术头条将定期和大家分享技术大咖们的精彩演讲实录,为互联网从业者提供更多精彩的技术干货,打造技术圈前沿技术交流的平台。京东数据库演变及MySQL运维自动化 演讲实录1、京东数据库发展演变

2012年,是京东数据库发展的一个重要时刻,2012年之前数据库主要以sql server、ORACLE为主,MySQL作为边缘系统,从2012年春节开始MySQL迅速在京东崛起,以爆炸式的方式增长,到2013年618,MySQL的使用就占了京东一半的核心交易系统,发展到2014年MySQL已经成为京东的主流数据库,为京东95%以上的业务提供百分百安全、高效、稳定的服务。

2013年3月28日正式发布了MySQL数据库分布式数据库“蓝海豚”,它主要解决的是数据库自动拆库拆表问题,提供透明代理,同时解决了性能、扩展性和空间问题,这个系统也预示着京东MySQL会有非常好的发展;对于研发和DBA的工作,也得到了很大的提升和改善。这是我们团队用了不到半年时间开发出来的,后续又有多次版本升级、提升。

京东MySQL的几个大事记:2012年春节MySQL的数量突破了一百台,同年618订单中心使用MySQL;2013年移动、价格、促销、库存等一半以上的核心交易数据库使用MySQL;2014年使用更为广泛,特别是2014年11.11最核心的订单中间件数据库正式使用了MySQL,正式宣布了MySQL在京东的主流地位;2015年进行了一系列创新性项目,如诺亚方舟数据库大迁移项目和多中心多活交易项目,对数据库资源、架构、高可用等进行优化、改造。

纵观京东数据库的发展趋势,从2012年开始以MySQL为主,其他多种开源数据库并存,包括:MongoDB、MariaDB、PerconaDB等;同时还有ORACLE、SQL SERVER等商业数据库同时为京东提供服务,不同的业务特性满足不同的需求。2、京东MySQL发展方向

对于京东MySQL的发展方向,主要包含以下六个方面:数据库设计优化、数据库架构、数据库安全、数据库灾备、数据库技术研究和创新、以及数据库运维自动化。前四个方面决定了数据库能够稳定、安全、高效、高性能的运行。由于MySQL是开源数据库,因此新技术研究和创新以及运维自动化环节,是MySQL运维中极为重要的主题,对海量数据库服务的管理、提高人效、减少人为故障等方面是至关重要的,这也是我们四年多发展的比较好的原因之一。我认为只有这六个方向同步发展,数据库体系才能够健壮成长,才能为公司提供更好的服务,这也是京东数据库发展的好的原因之一。

3、数据库运维自动化

随着京东业务的飞速增长,业务增加,数据库相应增加,MySQL由最初的几十台到以上百倍的速度增长,对这些业务的管理、服务器的管理、数据库的管理、各种信息的管理,数据库运维自动化是必不可少的。相信大家有这样的经历,几台或几十台的服务器运维,靠人工管理很好,而上百台、上千台乃至上万台的话就需要各种自动化工具、手段的支撑,也就是需自动化运维平台的支撑。京东的数据库自动化运维平台叫JMySQL智能管理平台,主要涵盖部署、切换、监控、基础信息管理、性能智能分析、自动处理、安全审计、自动化上线、备份等方面。这个系统是我在京东四年多打造的数据库运维平台,京东超大规模数据库的运维工作,就是靠运维自动化平台完成的,下面简要说明部分功能。

3.1、基础信息管理

基础信息管理是自动化运维的基础,京东的数据库规模已经覆盖数千条业务线,服务器数量巨大,那么其中的各种信息:设备信息、数据库集群信息、研发人员信息、账号管理信息、权限的划分、配置的管理、相关主从架构信息、DNS信息等的管理就非常必要,这些信息覆盖了监控、报警、备份、上线、切换等DBA运维中所有方面,如果没有这些信息,自动化运维无从谈起。比如说一个服务器故障了,需要知道这个服务器是那个机房的,是主库还是从库,上面是什么业务,业务的等级是什么,业务方的联系方式等信息,这个系统出来问题会影响到哪些业务,这些都是基础的,又是必须的。信息的完善、准确,对运维来说至关重要。另外,基于这些信息可以对故障进行自动判断,这和故障自动处理、报警合并技术相关联。

3.2、自动部署和扩容

对于DBA来说,数据库的扩容和改造是一个复杂且繁琐的工作,自动安装和自动部署可以使DBA提高人效,大部分的基础工作可以得以解放。扩容,这里指的扩容并不是单纯的扩容,而指的是水平拆分和垂直拆分,乃至更换硬件,或者是进行切换等等。很多情况下运维人员发现性能不够,就要去扩容,但事实上很多情况下,不见得一定要扩容来,相信很多人有过这种经验,改变一些策略或是一个业务逻辑甚至是一个SQL语句一个索引,就可以轻松解决问题,同时为公司节省资源,所以这里要强调的扩容是必须的扩容。

对于DB层面的扩容,主要是增加服务器部署数据库实例,导入数据,正式拆分切换。从服务器相关环境的初始化、数据库部署、制作从库等一系列实现自动化,最重要是做新从库的数据,可从备份存储中提取的备份文件来做,也可从线上从库动态取的。做这些工作的前提是一定不要影响生产业务,需要扩容的系统,做操作的时候一般选在业务低峰期间进行扩容。

对于水平扩容中对业务切换有两种方式,一种是自动的,一种是半自动的,自动切换的是因为有的业务使用分布式中间件系统,对于这种它可以进行自动的扩充,或者拆分,这个完全有中间件来完成,业务无感知。那么对于一些没有接入的中间件系统的,只需要研发和应用运维按照扩容拆分的规则,修改连接数据库DNS,垂直扩容相对简单这里略过。3.3、 自动切换

在大规模部署中,数据库在多个机房都会有从库,再加上多中心双活交易,会有双活的写库,场景会相对复杂。数据库宕机或网络异常后的切换是DBA一项重要工作,在MHA基础上DBA开发了自动切换程序JDSWITCH,在可接受自动切换的数据库上部署,其他的数据库因为业务原因会使用切换平台进行切换。切换平台也是一个极重要功能,支持按单台切换、按数据库集群切换、按子系统集群切换、整个机房进行切换。在可连通情况下,切换时会自动挂同步关系,所有数据不需要重做,如连不通则切换后有程序检验数据情况,能补齐的补齐,如无法补齐用自动部署系统重做。一旦整个机房异常,所有MySQL集群可在几分钟完成跨机房切换,防止挖土机关键时刻的绝杀。

特别提下,切换过程除切换外,必须包含监控的修改、资产信息的修改、备份策略的修改、主从角色的修改等,实现一键化流程完成,避免后续因此带来的二次故障。

3.4、数据库监控

对数据库服务运行的状态进行实时的监控,包括数据库会话、数据库日志、数据文件碎片、表空间监控、用户访问监控等,随时发现数据库服务的运行异常和资源消耗情况;输出重要的日常数据库服务运行报表以评估数据库服务整体运行状况,发现数据库隐患;监控对于DBA来说是至关重要的,是DBA的第三只眼睛,利于监控可以自动处理一些常规的故障,提前发现并解决潜在隐患。

市面上流行的监控软件很多,通过对比,京东数据库这边选用zabbix作为监控的基础,主要是因为它有很强的API,方便进行二次开发;监控粒度达到秒级,提高报警的及时性;触发报警条件的自主性,方便设置综合的触发条件,减少误报。我们对它进行了二次开发,并与资产信息、备份系统、切换系统等其他运维平台进行整合,可对监控数据进行深度分析,对报警项划分等级,不同的等级不同的告警处理方式,并结合监控报警启动故障自愈,使常见的故障可自动修复,必要的报警经处理后发给运维人员处理。我们已将其打造为具有京东特色的zabbix监控系统。

3.5 数据库性能智能分析

数据库性能的智能分析,主要是对数据库监控数据的二次分析,根据过去预测未来,根据当前排除安全隐患。在实际的生产中,有些隐患没有达到设置的报警阀值,处于一个报警的临界点,其实这种情况是最危险的,随时可能爆发,为解决这些隐患,我们通过对监控数据的环比、同比、TOP指标等方面进行分组汇总分析,提取出这些隐患,解决于萌芽状态。这点很重要,服务器的量级达到一定级别时,这个需求就显得即为重要,这是对监控的一个补充。

性能智能分析对数据库管理工作非常有用,举个应用线上的例子,本次大促数据库是按照前端流量可能增加20倍进行备战的,对于“抵挡”前端流量的数据库来讲风险非常大,算法上我们为这类数据库确定了压力倍数A,负责后端处理的数据库压力倍数通常小于A,因为有中间一系列环节处理,它的压力倍数被确定为B,有些系统压力会增加的非常大,DBA从研发处得到可能增加的压力倍数,则这个系统的特定压力倍数为C,在当前性能指标的基础上,可计算出性能是否满足,需要增加多少,哪种方式增加。对于不同类型应用对数据库的压力也不同,如IO型、CPU计算型、网络IO型、混合型等,会对数据库及服务器产生不同程度的影响。一定要避免木桶效应,并考虑峰值,举个简单例子:假设一个数据库别的指标都忽略,IO使用率均值是20%,但峰值达到30%,那这个数据库就不是能再抗4倍压力的,因为有峰值,如果确定压力真的会再增加4倍,那就要采取解决措施了。如果因为特定原因,不能进行数据库改造,则一定要制定预案,一旦压力上来,抗不住了,确保数据库不被打死。

特别强调下对于核心数据库不只是单纯地先进行指标评估分析,然后扩容改造就行了的,还要尽量进行压测,通过压测进行把关,既:要尊重指标分析,但还要注重实际情况。现在系统设计时大都会在应用和数据库层之间加Cache层,对于“抵挡”流量的数据库一定要考虑到Cache层被打穿或者关键时刻Cache层异常的情况,DBA这里会按照一个比例预留。基于资源考虑不可能为所有风险点无限制的改造,会按个比例进行,一旦异常情况超出压力范围,马上采用预案,比如该限流的限流、该降级的降级,首先保证主要的核心服务正常,不被打死。这里并不是说只对核心服务这样处理,时间允许、资源允许的话所有重要服务、服务都需要这样做。

回到SQL的话题,SQL性能好坏影响着数据库性能,要根本解决问题需要整改SQL、优化表结构或索引,那么对慢SQL的分析就是DBA的一项日常工作。京东这边为解决这个问题,根据京东的实际情况,开发出一套适合自己的慢查询订阅系统,定时分析慢SQL,发给指定的研发、DBA,大家也可以到慢查询平台去查,方便处理异常。

3.6 安全审计

对于MySQL数据库安全审计这块,京东主要这边主要分为四部分:安全策略、健康检查、行为审计、统计报表。通过以上策略,确保京东数据库数据的安全、完整、可靠、高效运行。

另外,DBA工作中最重要的一块就是数据库的备份,建立合理有效规范的数据库备份系统至关重要,在数据遭到严重故障时,不至于束手无策。备份分为常规备份和业务变更备份。常规备份一般指的是每天定时整备和增量备份,业务变更备份指的的是收到业务部门的指令备份数据或上线系统进行的操作前备份。备份会有多套,在本地、异地、云存储上等,并进行多重加密保护。

作为DBA,对SQL的准入制定相关的规范,对数据库访问权限的严格把控,对数据库的进行操作审计,严防数据信息外泄等也是工作的重要组成部分和工作职责,京东在这方面都建立了比较完善的体系。

4、京东MySQL发展展望

应该说这4年多,京东的MySQL等开源数据库取得了非常好的成绩,京东MySQL数据库规模巨大,运行极其稳定,很好的支撑了京东业务飞速发展,各种技术创新倍出,但我认为还有很多可提升、完善、细化的地方。在2016,基于云上的自动化、智能化、平台化、可视化是我们的目标,我会带领团队为了这个目标不断努力前进。

现场视频直击

活动推荐 4月9日,麒麟会将在北京五洲皇冠国际酒店二层会议室1举办一场深度技术交流沙龙活动,活动邀请了Open-Falcon社区发布Open-Falcon v0.1.0最新版本,还邀请到美团、快网、滴滴出行的一线互联网技术精英为大家现场全面解析Open-Falcon的学习成果与实战经验。

您可以进入麒麟会官网www.kylinclub.com报名或扫描以下二维码关注麒麟会微信在线免费报名!

我们审核通过后,将会在第一时间发送带有二维码连接的短信到您的手机,请您注意查收!


南京兆柏数据恢复中心 南京兆柏数据恢复中心
相关推荐