微信朋友圈:应对新年千亿访问量背后的故事

此文是按照杨尚刚在【QCON高可用架构群】中,针对MySQL在单表海量记录等景色下,业界普遍关心的MySQL难题的阅历分享整理而成,转载请声明出处。

迎接大家前往腾讯云社区,获取愈多腾讯海量技术实施干货哦~

杨尚刚,美图公司数据库高级DBA,负责美图后端数据存储平台建设和架构设计。前和讯高等数据库工程师,负责今日头条和讯主旨数据库架构改造优化,以及数据库相关的服务器存储选型设计。

作者:腾讯技能工程官方号

前言

MySQL数据库我们应该都很熟知,而且趁机前年的阿里的去IOE,MySQL逐步引起更多个人的垂青。

微信朋友圈包括图形和视频两套业务架构重组,朋友圈图片的表征是请求量大、消耗总计资源较多,摄像则首要消耗带宽。朋友圈的数目是永远存储的,而且趁机工作的敏捷发展,存储容量、带宽和配备的消耗多量充实,而根本节日带来的使用量拉长,更强化了消耗,也给运维人士的保险带来了英雄压力。

MySQL历史

  • 1979年,Monty Widenius写了初期的版本,96年揭发1.0
  • 1995-2000年,MySQL AB成立,引入BDB
  • 2000年4月,集成MyISAM和replication
  • 2001年,Heikki Tuuri向MySQL提议集成InnoDB
  • 2003发表5.0,提供了视图、存储进度等职能
  • 2008年,MySQL AB被Sun收购,09年推出5.1
  • 2009年4月,Oracle收购Sun,2010年12月推出5.5
  • 2013年2月推出5.6 GA,5.7开发中

节沐日有限支撑重点由三地点结合:软件有限支撑指通进程序、业务逻辑层面的优化和评估,减轻负载;硬件有限帮衬主要指带宽、机器负载的评估和扩容;柔性措施指的是透过工作调整,下降局部不根本特点的资源,来保险紧要特性的正规运作。

MySQL的优点

  • 利用简易
  • 开源免费
  • 扩大性“好”,在自然等级伸张性好
  • 社区活泼
  • 质量可以满意互连网存储和质量必要,离不开硬件帮忙

地点那多少个要素也是超过半数商家选用考虑MySQL的因由。可是MySQL本身存在的题材和限制也很多,有些难点点也平时被其余数据库吐槽或鄙视

软件保证

恋人圈全体意况:

 

图片 1

 

朋友圈的架构,紧要分为OC和IDC二种,IDC指的是数码基本,即数据最终诞生存储的地点,OC指的是带外网的单身机房,SOC指规模较大的OC。每个IDC都有一整套接口机/逻辑设备/存储设备用以协助用户的上传下载、及文件落地存储的要求。

OC点的主要功用是提供外网访问,承载用户的下载流量。每个OC内的设施,一起组成一个缓存池,用户下载时,本地OC中缓存不命中,才到IDC去回源拉取文件。每个OC的效应都是一样的,用户一般到跟前的OC点下载,当单个OC点故障时,会经过重试或者切换让用户到此外OC点下载,确保下载成功。

MySQL存在的题材

  • 优化器对复杂SQL支持不佳
  • 对SQL标准接济不佳
  • 大面积集群方案不成熟,紧要指中间件
  • ID生成器,全局自增ID
  • 异步逻辑复制,数据安全性难点
  • Online DDL
  • HA方案不健全
  • 备份和回复方案或者比较复杂,需求借助外部组件
  • 表现给用户信息过少,排查难点困难
  • 广大拨出,令人为难抉择

看看了刚刚讲的MySQL的优势和逆风局,可以看出MySQL面临的题材或者巨大于它的优势的,很多标题也是大家实际需求在运维中优化解决的,那也是
MySQL
DBA的另一方面价值所在。并且MySQL的频频前进也离不开社区接济,比如谷歌最早交付的半一起patch,后来也合并到官方主线。
脸谱推特(Twitter)等也都开源了其中使用MySQL分支版本,包含了她们中间选取的patch和特点。

容灾及重试机制:

恋人圈的模块容灾重假若落实单机故障时的自发性删除,紧要方式是通过master管理服务器的ip列表,通过心跳探测等措施找到至极设备,并屏蔽故障ip,不回来给前端选用,以front层的单机剔除为例:

 

图片 2

若是整个OC或IDC点遇到故障,由于改变较大,一般仰仗运维人士手工切换到回复,或者经过模块之间的重试机制来维系

情人圈下载的重试:

 

图片 3

无论是是用户到OC的下载进度,依然OC到IDC的回源进度,默许都会展开2次前功尽弃后的重试,并且重试一定会选用异地的接入点,避免后续重试到故障的节点。落成的法则是每一层master都会回到给前端至少两组ip列表,并保管两组ip列表为外地节点,前端战败时才得以兑现异地重试。

但重试由于会促成请求的加码,所以是把双刃剑,节日时期由于请求我涨幅一度很高,重试更易于吸引难题,须求举办调整:

1.通过master路由下发,关闭重试。在新正/元宵那种请求有数倍拉长的纪念日举办。

2.值班人士严密监督,倘若IDC败北率当先20%,则火急手工关闭重试。这种在春耕节/国庆那种拉长并不高的节假期进行。

Front模块的重试控制界面:

图片 4

 

数据库开发规范

数据库开发规范定义:开发规范是针对内部支出的一多级提议或规则,
由DBA制定(即使有DBA的话)。

支付规范自身也隐含几片段:基本命名和封锁规范,字段设计规范,索引规范,使用正式。

硬件有限协助

 

容量评估和装置扩容:

节日前运维人士会连同资源组,根据业务预算和业务抓实的须求及实际负荷,举行逐一机房、模块的设施扩容。预算以外的请求上涨,则透过柔性或者过载的办法,举行下跌或者拒绝。

 

  • 机房容量紧要根据沟通机带宽的上限评估
  • 接入层设备容量主要依据CPU、内存的载荷比例、网卡的流量/包量占比来评估。
  • 积存层设备容量首要基于CPU、内存的载荷比例、磁盘IO的读写次数来评估。

新年情侣圈上传负载:

 

图片 5

 

事情侧春龙节需要的增强比例,是上传支持9倍拉长,下载协理1倍进步,超越那个比重的哀告可以拒绝掉,但依照预算扩容后,达到上图的成效,依旧有一些模块无法支撑那一个涨幅,更加是压缩compress模块,该模块每匡助一倍升高就必要多量虚拟机扩容,预算内不能支撑,那样就须要使用柔性策略来解决。

标准存在意义

  • 保险线上数据库schema规范
  • 裁减出标题几率
  • 方便自动化管理
  • 专业必要漫长水滴石穿,对开发和DBA是一个互赢的政工

考虑没有开发规范,有的开发写出各样全表扫描的SQL语句或者各个奇葩SQL语句,我们前边就看过支付写的SQL
可以打印出一点页纸。那种造成工作本身不稳定,也会让DBA天天忙于各类救火。

柔性策略

恋人圈的柔性策略分为两层:

 

率先层是野蛮柔性,即按比例、接工作一贯限制上传下载的央浼,被限制的呼吁会再次来到给用户失利,与微信C2C相同,那种一般用来当先系统预估的载荷能力,造成系统故障时用来火速上涨工作时采纳。

第二层是按工作特点柔性,即从作业规模通过降落图片摄像清晰度、延迟用户更新等种类化下跌系统的载重。上边首要详述业务柔性

对象圈业务的主要增进与瓶颈:

 

从前文的装置负载评估图看,在预算范围内,接入层和逻辑层都不得不扶助5倍增进,而压缩compress模块只可以支持1倍进步。

 

图片 6

着力命名和约束规范

  • 表字符集选取UTF8 ,要是急需存储emoj表情,须要动用UTF8mb4(MySQL
    5.5.3将来支持)
  • 仓储引擎使用InnoDB
  • 变长字符串尽量使用varchar varbinary
  • 不在数据库中存储图片、文件等
  • 单表数据量控制在1亿之下
  • 库名、表名、字段名不利用保留字
  • 库名、表名、字段名、索引名使用小写字母,以下划线分割 ,须要见名知意
  • 库表名不要设计过长,尽可能用最少的字符表明出表的用途

1.压缩compress柔性

Compress模块的作用是将客户端上传出的原始图片按须求压缩成各类格式和尺寸,以协理特定的政工场景,并且节省存储空间和带宽。由于削减技术的不停升高,使用更进步的压缩格式,同等清晰度的图纸压缩比例越高,需求开支的压缩总计资源就越来越多。

 

图片 7

就此倘若反向操作,将近期使用的hevc格式替换回jpeg格式存储的话,就足以节省压缩资源,实测compress的cpu负载可以降为20%,即帮助5倍拉长。但图片的平均大小也会上升,造成下载流量回涨。

为此选拔的低头方法,是在上传图片换回jpeg格式的还要,将图纸的清晰度从70降为50,那样可以减小文件平均大小,从而抵消换回jpeg格式带来的流量上升效果。实际测试中,发现用户对降清晰度的感知并不显眼,在节日不久开启不会影响用户体验。

 

字段规范

  • 拥有字段均定义为NOT NULL ,除非您真的想存Null
  • 字段类型在满意急需原则下越小越好,使用UNSIGNED存储非负整数
    ,实际运用时候存储负数场景不多
  • 动用TIMESTAMP存储时间
  • 应用varchar存储变长字符串
    ,当然要小心varchar(M)里的M指的是字符数不是字节数;使用UNSIGNED
    INT存储IPv4 地方而不是CHAR(15) ,那种格局只好存储IPv4,存储不了IPv6
  • 选取DECIMAL存储精确浮点数,用float有的时候会有标题
  • 少用blob text

关于为啥定义不使用Null的由来

* 1.浪费囤积空间,因为InnoDB须求有额外一个字节存储

* 2.表内默许值Null过多会影响优化器采用执行布置

有关利用datatime和timestamp,现在在5.6.4后头又有了变更,使用二者存储在仓储空间上大差别更是小
,并且自己datatime存储范围就比timestamp大过多,timestamp只好存储到2038年

图片 8

2.小摄像码率柔性

小摄像的带宽平常会领先1TB,节日效应增强明显。所利用的降流量方法与图片类似,即下落上传视频的码率,通过降落文件平均大小的艺术来节省带宽。

柔性: 小视频码率1800 -> 1200 平均大小 2.1MB -> 1.3MB

经测试,降码率后基本不会潜移默化用户体验,但由于是对新上传录像生效,要突显到下载带宽的回落中,就有卓殊程度的延迟,几乎需要4时辰完全奏效。所以这一柔性措施在节日之前就要求开启,不可以用于应付殷切情状。

图片 9

降码率生效时期流量变动

目录规范

  • 单个索引字段数不当先5,单表索引数量不领先5,索引设计坚守B+
    Tree索引最左前缀匹配原则
  • 选择区分度高的列作为索引
  • 树立的目录能覆盖80%重视的询问,不求全,解决难点的主要龃龉
  • DML和order by和group by字段要建立适宜的目录
  • 幸免索引的隐式转换
  • 幸免冗余索引

关于索引规范,一定要铭记在心索引这一个事物是一把双刃剑,在加速读的还要也引入了成千成万相当的写入和锁,下跌写入能力,那也是干吗要控制索引数原因。在此以前看来过很五个人给表里每个字段都建了目录,其实对查询可能起不到如何效益。

冗余索引例子

  • idx_abc(a,b,c)**
  • idx_a(a) 冗余
  • **idx_ab(a,b) 冗余

隐式转换例子

字段:remark varchar(50) NOT Null

MySQL>SELECT idgift_code FROM gift WHERE deal_id = 640 AND
remark=115127; 1 row in set (0.14 sec)

MySQL>SELECT idgift_code FROM pool_gift WHEREdeal_id = 640
AND remark=‘115127’; 1 row in set (0.005 sec)

字段定义为varchar,但传播的值是个int,就会促成全表扫描,必要程序端要搞好项目检查

3.上传TSSD缓冲池柔性

 

图片 10

鉴于上传preupload接口机及后层的逻辑模块等,都爱莫能助支撑10倍涨幅。所以在架设中此外搭建了两套TSSD缓冲池,缓冲池用于临时存储新上传的文书,能够支撑读写。按上图所示,在zone模块处扩大了缓冲池一,在上传preupload处,扩充了缓冲池二。七个缓冲池的职能是有分其他:

 

  •  zone模块即便过载,主动过载掉的上传请求,不会一贯重回败北,而是将请求写入到缓冲池一中,缓冲池一中的文书并不能被下载到,但会按比较慢的快慢将文件发出,写入到后端模块。所以缓冲池一的要紧职能是舒缓长期内大批量的上传请求,而不是一点一滴抵消上传请求,并且缓冲池一中的文本是无法被下载到的。

 

  • 在preupload模块处扩大了缓冲池二,preupload模块中对存储TFS的写请求次数做了限定,假如上传请求数超越了储存TFS的能力,则preupload会将呼吁写入缓冲池二。用户下载时,会基于文件标识举行判定,倘诺发现文件存储在缓冲池二而不是TFS中,则会到缓冲池二中去得到文件。所以缓冲池二得以替代TFS的功能,起到有限支撑底层模块的功效。等到缓冲池二下架时,需求将其中的文件人工写入到TFS中。

 

SQL类规范

  • 尽量不使用存储进度、触发器、函数等
  • 防止使用大表的JOIN,MySQL优化器对join优化策略过于简单
  • 防止在数据库中开展数学运算和此外多量划算义务
  • SQL合并,首如若指的DML时候几个value合并,减弱和数据库交互
  • 合理的分页,更加大分页
  • UPDATE、DELETE语句不采取LIMIT ,简单导致主从分化

4.仇敌圈timeline按比例柔性

timeline指的是微信朋友圈更新的时日戳,这一柔性的规律是将布告用户好友朋友圈更新的光阴戳先缓存起来,不下发给用户的微信终端,那样微信上就看不到朋友圈更新的内容了,也就不会生出下载图片/摄像的伸手,能够直接压缩下载流量。

图片 11

timeline柔性后那里不会更新了

 

但也有几点注意事项:

 

  • 简单引起用户投诉,用户一般会分明感知到朋友圈内容缩小了。
  • 若果缓存timeline的年月过久,将缓存下发的经过就非得很慢,否则会挑起下载流量的进一步暴涨。

 

图片 12

除夕人工执行柔性的步调

 

数据库运维规范

推介阅读

新年微信访问突发,存储业务怎么稳定度过?

六个月清洗近千亿条微信支付交易记录,他们要搞哪样大工作?

云服务器20元/月起,更享千元续费大礼包


此文已由小编授权腾讯云技术社区公布,转载请申明原稿出处

运维规范重大内容

  • SQL审核,DDL审核和操作时间,更加是OnlineDDL
  • 危急操作检查,Drop前做好数据备份
  • 权限控制和审计
  • 日志分析,紧倘若指的MySQL慢日志和不当日志
  • 高可用方案
  • 数据备份方案

本子接纳

  • MySQL社区版,用户群体最大
  • MySQL企业版,收费
  • Percona Server版,新特点多
  • 玛丽亚DB版,国内用户不多

提出接纳优先级为:MySQL社区版 > Percona Server > MariaDB >
MySQL 公司版

唯独现在只要大家使用RDS服务,基本还以社区版为主

Online DDL问题

原生MySQL执行DDL时索要锁表,且锁表时期工作是无能为力写入数据的,对劳动影响很大,MySQL对那上面的支撑是相比较差的。大表做DDL对DBA来说是很惨痛的,相信广大人经验过。如何达成Online
DDL呢,是还是不是就无解了吗?当然不是!

图片 13

下边表格里关系的 非死不可 OSC和5.6 OSC也是近期三种比较可靠的方案

MySQL
5.6的OSC方案依旧解决不了DDL的时候到从库延时的难点,所以现在提出选择FacebookOSC那种思路更优雅

下图是Facebook OSC的思路

图片 14

新生Percona公司按照非死不可OSC思路,用perl重写了一版,就是大家现在用得很多的pt-online-schema-change,软件本身极度成熟,扶助如今主流版本。

使用pt-online-schema-change的长处有:

  • 1.无阻塞写入
  • 2.周到的规格检测和延时负荷策略控制

值得一提的是,腾讯互娱的DBA在其间分支上也完结了Online
DDL,此前测试过真正不错,速度快,原理是透过修改InnoDB存储格式来贯彻。

行使pt-online-schema-change的界定有:

  • 改表时间会比较长(相比较间接alter table改表)
  • 修改的表须求有唯一键或主键
  • 在同样端口上的面世修改不可以太多

可用性

有关可用性,大家前些天分享一种无缝切主库方案,可以用于普通切换,使用思路也相比较简单

在常规尺度下怎么无缝去做主库切换,要旨思路是让新主库和从库停在一如既往地点,首要依赖slave
start until 语句,结合双主结构,考虑自增难题。

图片 15

MySQL集群方案:

  • 集群方案首如若何许协会MySQL实例的方案
  • 主流方案基本依旧选用的是MySQL原生的复制方案
  • 原生主从同步肯定存在着品质和安全性难点

MySQL半一头复制:

前些天也有部分驳斥上可用性更高的别样方案

  • Percona XtraDB Cluster(没有丰裕的把控力度,不指出上)
  • MySQL Cluster(有官方协助,不过事实上用的不多)

图片 16

红框内是现阶段我们利用比较多的布局社团和方案。当然格外层面的HA也有不少第三方工具援救,比如MHA、MMM等,推荐应用MHA

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+,人有时候将要懒一些

图片 17

上图是程度拆分和垂直拆分的示意图

数据库备份

首先要保管的,最中央的是数据库数据安全性。数据安全都维持不断的动静下谈其余的目的(如质量等),其实意义就不大了。

备份的含义是什么吧?

  • 数据復苏!
  • 数据復苏!
  • 数据復苏!

眼前备份格局的几个纬度:

  • 全量备份 VS 增量备份
  • 热备 VS 冷备
  • 物理备份 VS 逻辑备份
  • 延时备份
  • 全量binlog备份

提出措施:

  • 热备+物理备份
  • 中心工作:延时备份+逻辑备份
  • 全量binlog备份

借用一下某大型互连网商家做的备份系统数据:一年7000+次扩容,一年12+次数据复苏,日志量每一天3TB,数据总量2PB,每一日备份数据量百TB级,全年备份36万次,备份成功了99.9%。

重在做的几点:

  • 备份策略集中式调度管理
  • xtrabackup热备
  • 备份结果统计分析
  • 备份数据一致性校验
  • 应用分布式文件系统存储备份

备份系统采取分布式文件系统原因:

  • 焚林而猎存储分配的难题
  • 缓解存储NFS备份效用低下难题
  • 积存集中式管理
  • 多少可信性更好

运用分布式文件系统优化点:

* Pbzip压缩,下落多副本存储带来的囤积开销,下落互连网带宽消耗

* 元数据节点HA,提升备份集群的可用性

* erasure code方案调研

数据復苏方案

现阶段的MySQL数据复苏方案紧要仍然根据备份来平复,可知备份的紧要。比如自己后日中午15点删除了线上一张表,该怎么着回复呢?首先肯定删除语
句,然后用备份扩容实例启动,要是备份时间点是凌晨3点,就还亟需把凌晨3点到明天关于那一个表的binlog导出来,然后使用到新扩容的实例上,确认好苏醒的时间点,然后把删除表的数据导出来应用到线上。

质量优化

复制优化

MySQL复制:

  • 是MySQL应用得最广大的应用技术,增添费用低
  • 逻辑复制
  • 单线程难题,从库延时难题
  • 可以做备份或读复制

题材多多,可是能一举成功主干难题

图片 18

上图是MySQL复制原理图,红框内就是MySQL一向被人非议的单线程难点

单线程问题也是MySQL主从延时的一个主要原因,单线程解决方案:

  • 法定5.6+多线程方案
  • Tungsten为表示的第三方并行复制工具
  • sharding

图片 19

上图是MySQL5.6
近日促成的并行复制原理图,是依照库级其他复制,所以借使您唯有一个库,使用那么些意义不大

自然MySQL也认识到5.6那种互相的瓶颈所在,所以在5.7引入了其余一种并行复制格局,基于logical
timestamp的并行复制,并行复制不再受限于库的个数,效能会大大升级

图片 20

上图是5.7的logical timestamp的复制原理图

刚刚自家也论及MySQL原来只帮助异步复制,那种数据安全性是老大差的,所未来来引入了半一块复制,从5.5起来援救

图片 21

上图是原生异步复制和半同台复制的分别。可以看来半联机通过从库重回ACK那种艺术确认从库收到数额,数据安全性大大提升

在5.7过后,半一起也足以配备你指定五个从库加入半一头复制,之前版本都是默许一个从库

对此半合办复制效能难点有一个小的优化,就是利用5.6+的mysqlbinlog以daemon格局作为从库,同步效能会好广大

关于更安全的复制,MySQL 5.7也是有方案的,方案名叫Group replication
官方多主方案,基于Corosync完成

图片 22

宗旨延时难点

缘由:一般都会做读写分离,其实从库压力反而比主库大/从库读写压力大相当简单导致延时。

杀鸡取卵方案:

  • 第一定位延时瓶颈
  • 假如是IO压力,能够经过升级硬件解决,比如替换SSD等
  • 万一IO和CPU都不是瓶颈,卓殊有可能是SQL单线程难题,解决方案可以设想刚才提到的并行复制方案
  • 只要还有题目,可以考虑sharding拆分方案

论及延时不得不提到很坑人的Seconds behind master,使用过MySQL的相应很熟谙

本条值的源码里算法

long time_diff= ((long)(time(0) – mi->rli.last_master_timestamp) – mi->clock_diff_with_master);

Secondsbehindmaster来判断延时不可依赖,在网络抖动或者部分奇异参数配置情状下,会导致这一个值是0但其实延时很大了。通过heartbeat表插入时间戳那种体制判断延时是更可靠的

复制注意点:

  • Binlog格式,指出都施用row格式,数据一致性更好
  • Replication filter应用

着力数据一致性难题:

  • row格式下的数据恢复生机难题

InnoDB优化

干练开源事务存储引擎,匡助ACID,支持工作三个隔离级别,更好的数据安全性,高品质高产出,MVCC,细粒度锁,帮助O_DIRECT。

首要优化参数:

  • innodbfileper_table =1
  • innodbbufferpool_size,依据数据量和内存合理设置
  • innodbflushlog_attrxcommit= 0 1 2
  • innodblogfile_size,可以安装大一些
  • innodbpagesize
  • Innodbflushmethod = o_direct
  • innodbundodirectory 放到高速设备(5.6+)
  • innodbbufferpool_dump
  • atshutdown ,bufferpool dump
    (5.6+)图片 23

上图是5.5 4G的redo log和5.6 设置大于4G redo
log文件质量相比,可以看看稳定性更好了。innodblogfile_size设置仍然很有含义的

InnoDB相比好的特色:

  • Bufferpool预热和动态调整大小,动态调整大小必要5.7帮助
  • Page size自定义调整,适应当前硬件
  • InnoDB压缩,大大下降数据容量,一般可以减掉50%,节省存储空间和IO,用CPU换空间
  • Transportable tablespaces,迁移ibd文件,用于飞速单表复苏
  • Memcached API,full text,GIS等

InnoDB在SSD上的优化:

  • 在5.5以上,提高innodbwriteiothreads和innodbreadiothreads
  • innodbiocapacity须求调大
  • 日志文件和redo放到固态硬盘,undo放到SSD,提出如此,但必要性不大
  • atomic write,不需要Double Write Buffer
  • InnoDB压缩
  • 单机多实例

也要搞清楚InnoDB哪些文件是逐一读写,哪些是轻易读写

肆意读写:

  • datadir
  • innodbdata file_path
  • innodbundo directory

逐条读写:

  • innodbloggrouphomedir
  • log-bin

InnoDB VS MyISAM:

  • 多少安全性关键,InnoDB完胜,曾经遭受过五回90G的MyISAM表repair,花了两日时间,倘诺在线上大致不可忍受
  • 并发度高
  • MySQL 5.5默许引擎改为InnoDB,标志着MyISAM时代的落幕

TokuDB:

  • 辅助工作 ACID 特性,辅助多版本控制(MVCC)
  • 基于Fractal Tree Index,分外适合写入密集场景
  • 高压缩比,原生匡助Online DDL
  • 主流分支都扶助,收费转开源 。如今可以和InnoDB比美的贮存引擎

当下主流应用TokuDB重倘诺惬意了它的高压缩比,Tokudb有三种收缩格局:quicklz、zlib、lzma,压缩比依次更高。现在游人如织拔取zabbix的后端数据表都选拔的TokuDB,写入品质好,压缩比高。

下图是本身事先做的测试对照和InnoDB

图片 24

图片 25

上图是sysbench测试的和InnoDB质量相比图,可以看到TokuDB在测试进程中写入平稳是可怜好的。

tokudb存在的标题:

  • 官方分支还没很好的支撑
  • 热备方案难点,方今唯有公司版才有
  • 照旧有bug的,版本更新对比快,不指出在着力业务上用

譬如我们事先碰到过一个题材:TokuDB的中间景观突显上两次成功的checkpoint时间是“Jul
17 12:04:11 2014”,距离当时意识现在都快八个月了,结果堆积了大气redo
log无法去除,后来只好重启实例,结果重启还花了七七个小时

MySQL优化相关的case

Query
cache,MySQL内置的查询加快缓存,理念是好的,但设计不够客观,有点out。

锁的粒度相当大MySQL 5.6默认已经倒闭

When the query cache helps, it can help a lot. When it hurts, it can
hurt a lot.鲜明前半句已经远非太大用处,在高并发下万分不难境遇瓶颈。

至于业务隔离级别
,InnoDB默认隔离级别是可重新读级别,当然InnoDB尽管是安装的可重复读,但是也是缓解了幻读的,提出改成读已提交级别,可以满意半数以上场合须要,有利于更高的产出,修改transaction-isolation。

图片 26

图片 27

上图是一个比较经典的死锁case,有趣味可以测试下

关于SSD

关于SSD,照旧提一下吧。某老牌大V说过“方今10年对数据库品质影响最大的是闪存”,稳定性和总体性可依赖性已经取得广大验证,多块SATA
SSD做Raid5,推荐应用。选拔PCIe SSD,主流云平台都提供SSD云硬盘帮助。

最后说一下我们关切的单表60亿记录难点,表里数据也是线上相比较基本的。

先说下立即意况,表结构相比不难,都是bigint那种整型,索引比较多,应该有2-3个,单表行数60亿+,单表容量1.2TB左右,当然内部肯定是有散装的。

多变原因:历史遗留难题,根据大家眼前讲的支出规范,这几个相应早拆分了,当然不拆有多少个原因:

  1. 属性未赶上瓶颈 ,主要缘由
  2. DBA比较“懒“
  3. 想看看InnoDB的极端,挑战一下。不过风险也是很大的,想想若是在一个1.2TB表上加个字段加个索引,那感觉相对酸爽。还有就是单表复苏的题材,復苏时间不可控。

咱俩后续做的优化
,采纳了刚刚提到的TokuDB,单表容量在InnoDB下1TB+,使用Tokudb的lzma压缩到80GB,压缩效果更加好。这样也解决了单表过大苏醒时间难题,也支撑online
DDL,基本落成大家预料。

今天讲的紧要针对MySQL本身优化和专业性质的事物,还有部分比较好的运维经验,希望大家能拥有收获。前天这么些内容是为一而再数据库做平台化的功底。我明日享受就到此地,谢谢我们。

QA

Q1:use schema;select * from table; 和select * from
schema.table;三种写法有哪些不平等吧?会对骨干同步有震慑呢?

对此主从复制来说执行功能上差异不大,不过在接纳replication
filter时候这种状态须要小心,应该要使用ReplicateWildIgnoreTable那种参数,假设不选取带wildignore,第一种办法会有难题,过滤不起成效。

Q2:对于用于MySQL的ssd,测试办法和ssd的参数配置方面,有没有好的提出?首要针对ssd的安顿哈

有关SATA SSD配置参数,指出选取Raid5,想更保障使用Raid50,更土豪使用Raid
10

图片 28

上图是根本的参数优化,质量提高最大的是率先个修改调度算法的

Q3:数据库规范已制定好,怎样确保开发人员必须遵守专业来开发?

有关数据库规范执行难题,也是有七个地方呢,第一、定期给开发培训支出规范,让开发能更通晓。第二、照旧在流程上专业,比如把大家日常通用的建表和字段策略固化到程序,做成自动化审核系统。那两上边结合
效果会比较好。

Q4:怎么样最大限度进步innodb的命中率?

以此题材前提是你的数目要有叫座,读写热点要有交集,否则命中率很难提升。在有热门的前提下,也须求您的你的内存要丰富大,可以存更加多的紧俏数据。尽量不要做一些或者污染bufferpool的操作,比如全表扫描那种。

Q5:主从复制的气象下,若是有CAS这样的要求,是否只可以强制连主库?因为有延期的留存,假设读写不在一起的话,会有脏数据。

如若有CAS须求,确实仍旧直接读主库好一些,因为异步复制照旧会有延迟的。只要SQL优化的比较好,读写都在主库也是没什么难题的。

Q6:关于开发规范,是不是有必不可少买国标?

其一国标是何许事物,不太通晓。不过从字面看,国标应该也是偏学术方面的,在实际工程举办时候未必能用好。

Q7:主从集群能或不能够再细化一点那?不晓得那样问合适不?

看现实哪方面呢。主从集群每个小集群一般都是运用一主多从点子,每个小集群对应特定的一组工作。然后监控备份和HA都是在每个小集群达成。

Q8:怎么着跟踪数据库table某个字段值爆发变化?

追踪字段值变化可以透过分析row格式binlog好一些。比如原先同事就是由此友好支付的工具来解析row格式binlog,跟踪数据行转变。

Q9:对超大表水平拆分,在运用MySQL中间件方面有怎么着提出和经验分享?

对此超大表水平拆分,在中间件上经历不是很多,早期人肉搞过几遍。也应用过自己研发的数据库中间件,不过线上选取的框框不大。关于当前游人如织的开源中间件里,360的atlas是眼前还不错的,他们公司内部选用的可比多。

Q10:大家用的MySQL
proxy做读负载,可是少量多少压力下并从未负载,请问有那回事吗?

少量数码压力下,并从未负载 ,这么些没测试过,不好评价

Q11:对于binlog格式,为啥只推荐row,而不用网上半数以上篇章援引的Mix

其一重中之重是考虑数据复制的可靠性,row更好。mixed含义是指倘若有局地便于造成主从分化的SQL
,比如包涵UUID函数的这种,转换为row。既然要革命,就搞的根本一些。那种mix的中间状态最坑人了。

Q12: 读写分离,一般是在程序里做,仍然用proxy
,用proxy的话一般用哪些?

以此依然单独写程序好一些,与程序解耦方便前期维护。proxy国内如今开源的可比多,接纳也要慎重。

Q13:
我想问一下有关mysql线程池相关的难点,什么情形下适合使用线程池,相关的参数应该怎么陈设,老师有那方面的最佳实践没有?

线程池那几个我也没测试过。从常理上来说,短链接更契合用线程池格局,减少建立连接的损耗。那些地点的一级配置,我还没测试过,前边测试有举行可以再聊聊。

Q14: 误删数据这种,数据苏醒流程是何许的(从库也被一道删除的情况)?

看您剔除数据的景况,尽管只是一张表,单表在几GB或几十GB。倘若能有延时备份,对于数据復苏速度是很有补益的。復苏流程可以参照我刚刚分享的部
分。目前的MySQL数据復苏方案紧要仍然依照备份来平复
,可知备份的机要。比如我后天晌午15点删除了线上一张表,该怎么回复呢。首先肯定删除语句,然后用备份扩容实例启动,如果备份时间点是凌晨3点。就还
须求把凌晨3点到现行关于这么些表的binlog导出来,然后利用到新扩容的实例上。确认好苏醒的时间点,然后把删除表的数据导出来应用到线上。

Q15:
关于备份,binlog备份自然不用说了,物理备份有好多艺术,有没有推荐的一种,逻辑备份在量大的时候復苏速度比较慢,一般用在什么境况?

物理备份选取xtrabackup热备方案相比好。逻辑备份一般用在单表苏醒功用会尤其好。比如你删了一个2G表,但您总数据量2T,用情理备份就会要慢了,逻辑备份就充足实用了。

发表评论

电子邮件地址不会被公开。 必填项已用*标注