95992828九五至尊2

美图秀秀DBA谈MySQL运维及优化,2011数据库技术大会印象与笔记

二月 9th, 2019  |  九五至尊ii

数据库技术大会(http://dtcc.it168.com/)是IT168等媒体主办的一个数据库方面的技术人士的议会。二〇一九年是第四届。二零一八年率先届,时间与清朗节假日争辩,我没参预。今年时刻上有了改正,没有与小长假争辨,时间是8月15,16二日,分别是星期二周四。

美图秀秀DBA谈MySQL运维及优化

会议地点是永泰福朋喜来登酒店,具体地方在西四环内侧四海桥与四季青桥之间,交通还算方便,附近不算太拥堵。第一天租了七个会议室。第二天改成了八个。我预计参会人数有500-800之内。招来了几家卖书的摆了书店。

https://mp.weixin.qq.com/s?\_\_biz=MzI4NTA1MDEwNg==&mid=401797597&idx=2&sn=a0fc08dbb8ce399f0d4cd70bff5b1366&scene=0&key=62bb001fdbc364e56abc83575de147aa1f6fe32d5f4bad7190eadb03350bcfba18b0c9740d43855a5b45e5286bd457cd&ascene=7&uin=MTY5MDMyNDgw&devicetype=android-19&version=26030848&nettype=cmnet&pass\_ticket=riM9zfPe6xeT8eL8AkHgcLA5unnvy5L1BKyiUC4RrOY%3D

二日的会自我都在场了。以下是部分映像与笔记。

 

先说一点总体映像:国内做IT应用程度最高的是Tmall、阿里、百度、博客园这几个网络老大们的技术人士。他们的工作需要远非现成的软件出品可以满意,只好协调去做,他们须要缓解的难点在境内是最复杂、最难处理的、最没有先例可循的。接下来是给银行电信经济等大佬做项目标人员,面对的难点也比较复杂相比较难处理,平日索要给那个行业定制开发一些出品。再下来是垄断行业的技术人士,有厂家给她们现成的方案供拔取。

乘机MySQL应用的纷来沓至推广和自家发展,怎么着更好的优化MySQL和运用MySQL,依旧是一个相比较有挑衅的标题,尤其是在作业急忙拉长的场景下。本次分享主要介绍部分通用的运维优化实践和难题,以及未来的部分主旋律。

先是场讲百度数据库架构(主要利用是百度明白和百度贴吧)(http://tech.it168.com/a2011/0415/1178/000001178522.shtml),第二场讲新浪网易数据库架构(http://tech.it168.com/a2011/0415/1178/000001178546.shtml)。百度的数据库架构经历了多少个阶段:分散式、集中式和分布式。腾讯网也经历了多少个等级:MySQL+MemCache,MySQL+UDF,Cache按冷热度分两层。
个人感觉两家面对的标题大致相同,然而天涯论坛乐乎更复杂,因为百度驾驭和百度贴吧相对来说更便于拆分。天涯论坛网易由于用户间有复杂的涉及,根本没办法按用户去拆分。实际上今日头条的做法是有三个可读的从库,每个从库的拆分方法不肯定相同,比如可能有一个从库是按用户拆的,其余一个从库是按大旨拆的。基本思路是把索引当作分化的拆分标准(那几个解决思路一笔带过,参会的人不必然注意到、意识到)。

 

上午剩余两场演讲印象不深。

目录

早晨听SQL Server专场。第一讲“SQL Server
探秘”,演说者极度重视日志,认为不打听日志就是把SQL Server当Excel
Access使用。
说到底两场圆桌会议,快停止的时候有演说者说了些很风趣的话题:中国银行与农行的技艺的可比。招商银行的技术人员并非个个都是权威,一大半也都是一般技术人员,技术人士的程度并不比光大银行强,然而交行的技巧,就是比平安银行强。强在严苛执行管理制度,包含:上线时间分外严酷(每季度三遍),技术人员对bug负责(与占收入一半的年底奖金直接关系),DBA严峻执行修改数据的科班,轻易不允许业务部门直接改数据库中数量的呼吁,由此数据质量相比高。

 

其次天深夜听商业智能专场。第一场和第三场不错。第一场“阿里巴巴(Alibaba):海量数据解析平台”,介绍了阿里巴巴(Alibaba)的多寡挖掘平台的一对情形,我觉着不错,挺有获取。有个小插曲:会后主持人说时间紧张,只给一个叩问机会,有一个千金问数据挖掘是否入侵隐衷。解说者居然跟他来往问答了多少个回合。我觉着那几个题材完全不应该在那几个会场来谈谈。演说者没察觉到他在这些地点不是我们,在那一个会上谈论那个题材是耽搁大家时刻。

  • MySQL的优势和逆风局

  • 数据库规范化

  • Sharding拆分

  • 数据库备份

  • 属性优化

     

其三场“国内电信领域数据仓库建设与行使实践”,解说者有成百上千电信业数据仓库项目标实施经验,基本是系列经验介绍,讲的可比快。也值得一听。

九五至尊ii 1

清晨的演讲中认为不错的是首先场“随需应变的云数据库架构与统筹”,解说者李强是Samsung首席DBA,讲了重重三星数据库设计方面的团种类统、流程、工具。

 

 

从每个月的db
engines排行可以看来,关周密据库如故占主导地位,nosql的档次和可选择空间更大,总共283种数据库,里面一大半也是NoSQL。

 

 

 

怎么样抉择数据库,从以下多少个因素考虑:

 

 

  • 采用场景:OLTP or OLAP

  • 数据量:亿级,百亿,照旧千亿?

  • 可用性要求:故障时间要求

  • 数量安全性必要

  • 运维复杂度

  • 工作援救

     

 

 

九五至尊ii 2

 

上面的两张图介绍了当前三种主流代表性数据库的利害和杰出应用场景。

 

 

九五至尊ii 3

 

上图是事先在今日头条大家针对不一样景色选用的数据库。

 

第一,大家罗列几点MySQL的优势和逆风局:

 

九五至尊ii,1、优势

  • 使用简便

  • 开源免费

  • 扩张性”好”,在自然等级增加性好

  • 社区活泼,作用日渐周到

  • 质量可以知足网络存储和品质须求,离不开硬件接济官方帮衬

 

2、劣势:

  • 优化器对复杂SQL支持不好

  • 对SQL标准扶助不好

  • 大面积集群方案不成熟,紧要指中间件

  • 逻辑复制

  • Online DDL

  • HA方案不周密

  • 备份和回复方案仍然比较复杂,必要借助外部组件

  • 表现给用户音讯过少

  • 很多分层

 

上述可以见见MySQL面临的标题还有好多,而这一个难点是运维中须求解决的,也是DBA落成价值的地点。MySQL的不止进步也离不开社区帮助,比如谷歌最早交付的半同patch,后来也联合到官方主线。非死不可推特等也都开源了其中使用MySQL分支版本,包罗了她们中间选拔的patch。

 

其次,大家看看MySQL DBA的经常须求:

 

  • 满意各个种种的支付必要

  • 饶有的Schema审核

  • SQL优化

  • 种种救火和拍卖报警 :主库故障,缓存“雪崩”

  • 各样工作和类型上线

  • 作业关联和须要审核

 

DBA解放自己和升高作用的前提有:规范化,自动化,平台化。

 

那么哪些规范化,大家来第一讲述一下。

 

数据库规范重大涵盖两部分:

 

1.数据库开发规范:

支付规范是指向内部支出的一多元指出或规则,由DBA制定(假设有DBA的话)。支出规范也含有:基本命名和封锁规范,字段设计规范,索引规范,使用正规多个部分片段

 

意义:(1)有限支撑线上数据库schema规范,收缩出标题几率,方便自动化管理;(2)须要长期水滴石穿,是一个互赢的事体。

 

规范示例:

 

  • 表字符集选取UTF8 ,假设须求存储emoj表情,需求动用UTF8mb4(MySQL
    5.5.3之后协助)

  • 存储引擎使用InnoDB

  • 变长字符串尽量使用varchar 和varbinary

  • 不在数据库中存储图片、文件等

  • 每张表数据量控制在5亿以下

 

2.数据库运维规范:

 

  • SQL审核,DDL审核和操作时间,尤其是大表DDL

  • 危险操作检查,Drop做好数据备份

  • 权力决定,既包涵DBA自身,也囊括开发

  • 日志分析,重即使指的MySQL慢日志

  • 高可用方案, 定期做演练和测试

  • 数据备份方案

 

在此间说一下MySQL DDL难题:

 

  • 原生MySQL执行DDL是须要锁表的,对劳动影响很大。

  • 虽说MySQL 5.6和5.7也平素在做,可是对于生产上依旧不是那么完美。

  • MySQL在那下面支撑的是相比较差的,对DBA来说是很忧伤的。

 

上面是一对方案相比较

 

九五至尊ii 4

 

下图是实际上运维进程中可以动用的DDL方案

 

九五至尊ii 5

 

从上图能够见到,MySQL5.6+的Online
DDL和pt-osc锁粒度是最轻的,不过pt-osc更通用一些。

 

pt-osc的规律 ,仍旧很巧妙的:

 

九五至尊ii 6

 

MySQL 5.6和pt-osc的比较,在某些场景5.6依然要好于pt-osc的,毕竟pt-osc
每一遍都要copy全表数据。

 

九五至尊ii 7

 

pt-OSC一些坑:

  • 添加唯一键,导致数据丢失

  • 延时备份的难题

  • 行格式下,只在从库使用OSC,丢数据

     

一体化来说pt-osc的可信性照旧很高的。

 

 

集群方案首如果怎么样社团MySQL实例的方案,主流方案基本依旧选择的是MySQL原生的复制方案。原生主从同步肯定存在着质量和安全性难点。

MySQL 半一同复制。

现行也有部分别样选项,理论上可用性更高的方案:

  • Percona XtraDB Cluster(没有足够的把控力度,不指出上)

  • MySQL Cluster(有法定协助,但是实在用的不多)

  • group replication(MySQL 5.7合法帮衬)

 

以下是MySQL复制协理的复制拓扑:

 

九五至尊ii 8

 

不等集群方案的可信性:

 

九五至尊ii 9

 

接下去大家讲一下sharding拆分难点:

 

Sharding is very complex, so itʼs best not to shard until itʼs obvious
that you will actually need to!

 

Sharding是遵从一定规则数据重复分布的主意,拆分是对应用层有损的,首要解决单机写入压力过大和容量难题。主要有垂直拆分和水准拆分,拆分要适当,切勿过渡拆分,今日头条天涯论坛单表最大60亿+,单表数据文件大小1TB+,DBA有时候将要懒一些。

 

九五至尊ii 10

 

上图是三种拆分的架构。

 

然后大家讲一下很重点的数据库备份

以此不论是何等数据库,数据库数据安全性是率先要力保的,也是最主旨的。日常优化做的再好,一旦须要恢复生机时候,备份有难点就挂了。备份的意义是怎么样呢

 

数据恢复生机!

大家来看一下脚下的种种备份方案:

 

  • 全量备份 VS 增量备份

  • 热备 VS 冷备

  • 大体备份 VS 逻辑备份

  • 延时备份

  • 全量binlog备份

 

自家提议的不二法门是:
热备+物理备份,主旨工作:延时备份+逻辑备份+全量binlog备份

 

下边说一下性质优化:

 

1.复制优化

那是MySQL应用最广大的应用的技能,扩大费用低。为逻辑复制。单线程难题,从库延时难点。可以做备份或读复制。难点多多,可是能解决主题难题。

 

规律图如下,我们应该都驾驭。

 

九五至尊ii 11

 

单线程解决方案

 

1.官方5.6+十六线程方案

  1. Tungsten和阿里的transfer为代表的第三方工具
    3.sharding
    4.硬件升级

 

下图复制矩阵对咱们选用复制方案得以参考

 

九五至尊ii 12

 

半同步
更好的数据安全性
可以计划三个从库
引入loss-less semireplication,,通过
rpl_semi_sync_master_wait_point
能够经过5.6+的mysqlbinlog作为从库,可以增强半一头复制效用

loss-less改造的规律

 

九五至尊ii 13

 

以下是复制的有些注意点

 

  • Binlog格式,提出都应用row格式

  • Replication filter应用

  • 大旨数据一致性难题,比如出现分化等怎么样修复

  • row格式下的数据復苏难题

  • GTID应用

 

2.InnoDB优化

开源事务存储引擎,匡助ACID,辅助工作八个隔离级别更好的数额安全性,高质量高产出,MVCC,细粒度锁辅助O_DIRECT。

 

重点优化参数如下:

九五至尊ii 14

 

InnoDB近来的一些特性:

 

  • Bufferpool预热和动态调整大小

  • Page size自定义调整

  • InnoDB 压缩,大大下落数据容量,一般可以减小50%

  • Transportable tablespaces,迁移ibd文件,用于火速单表复苏

  • Memcached API,full text,GIS等

 

下图是MySQL5.6和MySQL 5.7的默许参数比较,咱们可以感受一下

 

九五至尊ii 15

 

3.系统优化

 

以下是系统优化周边的多少个点:

 

  • NUMA难题,提议关闭,其实不停歇也没察觉越发大标题

  • 调整swappiness

  • 修改IO调度算法为noop/deadline

  • 文件系统XFS/Ext4

  • 系统limits限制

  • 网卡多队列,当然一般可能遇不到那种气象

  • Io中断多队列,对于高品质存储设备是必不可少的

 

4.未来可优化:

 

前途可优化首要有几个点:

软硬件结合
软件优化

 

5.软硬件优化案例:

接下去大家来看一个案例:

 

Amazon Aurora:
Compatible with the open source MySQL
Most of the smarts are in the storage
A data insert in MySQL requires six writes ,Aurora requires only two

软硬件结合
最根本的地点就是可用性的擢升,品质是次要。当然现在aurora的健壮性还亟需时日验证,据说仍然有坑的。

 

amazon aurora文档上的架构图

 

九五至尊ii 16

 

6.软件和存储层的优化

LSM Tree:LevelDB,RocksDB
适配高质量存储SSD,更高的压缩比,,更低的写入放大比例
症结:读质量差
适合写多读少场景
MyRocks: MySQL + RocksDB

 

总结

  • MySQL是足以用好的

  • MySQL可选的方案和可优化的点依旧游人如织

  • MySQL 5.7性质和新特征依旧很有吸动力的

 

自然依旧会有人都会来吐槽优化器是做的烂,比xxxxx差远了,应该把MySQL换掉,优化器差那是不争的实际情形,但并不影响在网络境况的应用,MySQL也是有和好的优势的,所以不要任意说何人一定可以取代哪个人,场景分裂,都会有温馨的短板。对待技术本身要宽容,比如最好的编程语言
最好的数据库之类的那种非黑即白的概念,对待技术细节要探索。

 

教授介绍:杨尚刚

 

  • 【DBA+社群】联合发起人

  • 美图高级DBA。数据库管事人,负责美图后端数据存储平台建设和架构设计。

  • 前虎扑高等数据库工程师,负责今日头条网易要旨数据库架构改造优化,主导了和讯微博宗旨数据库的每趟架构变迁,数据库平台相关的服务器存储选型设计。

相关文章

Your Comments

近期评论

    功能


    网站地图xml地图