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

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

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

 

随着MySQL应用的不断普及和自身发展，如何更好的优化MySQL和使用MySQL，依然是一个比较有挑战的问题，尤其是在业务快速增长的场景下。本次分享主要介绍一些通用的运维优化实践和问题，以及未来的一些方向。

 

目录

 

  • MySQL的优势和劣势

  • 数据库规范化

  • Sharding拆分

  • 数据库备份

  • 性能优化

     

 

从每个月的db engines排名可以看到，关系数据库依然占主导地位，nosql的种类和可选择空间更大，总共283种数据库，里面大多数也是NoSQL。

 

如何选择数据库，从以下几个因素考虑：

 

  • 应用场景:OLTP or OLAP

  • 数据量:亿级，百亿，还是千亿？

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

  • 数据安全性要求

  • 运维复杂度

  • 事务支持

     

 

 

 

上面的两张图介绍了目前几种主流代表性数据库的优缺点和典型应用场景。

 

 

 

上图是之前在微博我们针对不同场景采用的数据库。

 

首先，我们罗列几点MySQL的优势和劣势：

 

1、优势

  • 使用简单

  • 开源免费

  • 扩展性”好”，在一定阶段扩展性好

  • 社区活跃，功能逐步完善

  • 性能可以满足互联网存储和性能需求，离不开硬件支持官方支持

 

2、劣势：

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

  • 对SQL标准支持不好

  • 大规模集群方案不成熟，主要指中间件

  • 逻辑复制

  • Online DDL

  • HA方案不完善

  • 备份和恢复方案还是比较复杂，需要依赖外部组件

  • 展现给用户信息过少

  • 众多分支

 

上述可以看到MySQL面临的问题还有很多,而这些问题是运维中需要化解的，也是DBA实现价值的地方。MySQL的不断发展也离不开社区支持，比如Google最早提交的半同patch，后来也合并到官方主线。Facebook Twitter等也都开源了内部使用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来说是很痛苦的。

 

下面是一些方案对比

 

 

下图是实际运维过程中可以采用的DDL方案

 

 

从上图可以看出，MySQL5.6+的Online DDL和pt－osc锁粒度是最轻的，不过pt-osc更通用一些。

 

pt-osc的原理 ，还是很巧妙的：

 

 

MySQL 5.6和pt-osc的对比，在某些场景5.6还是要好于pt-osc的，毕竟pt-osc 每次都要copy全表数据。

 

 

pt-OSC一些坑：

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

  • 延时备份的问题

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

     

整体来说pt－osc的可靠性还是很高的。

 

 

集群方案主要是如何组织MySQL实例的方案，主流方案核心依然采用的是MySQL原生的复制方案。原生主从同步肯定存在着性能和安全性问题。

MySQL 半同步复制。

现在也有一些其他选择，理论上可用性更高的方案：

  • Percona XtraDB Cluster(没有足够的把控力度，不建议上)

  • MySQL Cluster(有官方支持，不过实际用的不多)

  • group replication（MySQL 5.7官方支持）

 

以下是MySQL复制支持的复制拓扑:

 

 

不同集群方案的可靠性：

 

 

接下来我们讲一下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有时候就要懒一些。

 

 

上图是两种拆分的架构。

 

然后我们讲一下很重要的数据库备份


这个不论是什么数据库，数据库数据安全性是首先要保证的，也是最核心的。平时优化做的再好，一旦需要恢复时候，备份有问题就挂了。备份的意义是什么呢 。

 

数据恢复！

我们来看一下当前的各种备份方案：

 

  • 全量备份 VS 增量备份

  • 热备 VS 冷备

  • 物理备份 VS 逻辑备份

  • 延时备份

  • 全量binlog备份

 

我建议的方式是：
热备＋物理备份，核心业务：延时备份＋逻辑备份+全量binlog备份

 

下面说一下性能优化：

 

1.复制优化


这是MySQL应用最普遍的应用的技术，扩展成本低。为逻辑复制。单线程问题，从库延时问题。可以做备份或读复制。问题很多，但是能解决基本问题。

 

原理图如下，大家应该都了解。

 

 

单线程解决方案

 

1.官方5.6+多线程方案
2. Tungsten和阿里的transfer为代表的第三方工具
3.sharding
4.硬件升级

 

下图复制矩阵对大家选择复制方案可以参考

 

 

半同步
更好的数据安全性
可以配置多个从库
引入loss-less semireplication,,通过 rpl_semi_sync_master_wait_point
可以通过5.6+的mysqlbinlog作为从库，可以提高半同步复制效率

loss-less改造的原理

 

 

以下是复制的一些注意点

 

  • Binlog格式，建议都采用row格式

  • Replication filter应用

  • 主从数据一致性问题，比如出现不一致如何修复

  • row格式下的数据恢复问题

  • GTID应用

 

2.InnoDB优化


开源事务存储引擎，支持ACID，支持事务四个隔离级别更好的数据安全性，高性能高并发，MVCC，细粒度锁支持O_DIRECT。

 

主要优化参数如下：


 

InnoDB目前的一些特性：

 

  • Bufferpool预热和动态调整大小

  • Page size自定义调整

  • InnoDB 压缩，大大降低数据容量，一般可以压缩50%

  • Transportable tablespaces，迁移ibd文件，用于快速单表恢复

  • Memcached API，full text，GIS等

 

下图是MySQL5.6和MySQL 5.7的默认参数对比，大家可以感受一下

 

 

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文档上的架构图

 

 

6.软件和存储层的优化


LSM Tree:LevelDB,RocksDB
适配高性能存储SSD，更高的压缩比,，更低的写入放大比例
缺点：读性能差
适合写多读少场景
MyRocks: MySQL + RocksDB

MongoDB也有，mongo+RocksDB

 

总结

  • MySQL是可以用好的

  • MySQL可选的方案和可优化的点依然很多

  • MySQL 5.7性能和新特性还是很有吸引力的

 

当然依然会有人都会来吐槽优化器是做的烂，比xxxxx差远了，应该把MySQL换掉，优化器差这是不争的事实，但并不影响在互联网场景的应用，MySQL也是有自己的优势的，所以不要轻易说谁一定能够替代谁，场景不一样，都会有自己的短板。对待技术本身要宽容，比如最好的编程语言 最好的数据库之类的这种非黑即白的定义，对待技术细节要深究。

 

新浪微博DBA去向，  去了聚美优品，去了唯品会，去了美图秀秀

 

讲师介绍：杨尚刚

 

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

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

    • 前新浪高级数据库工程师，负责新浪微博核心数据库架构改造优化，主导了新浪微博核心数据库的历次架构变迁,数据库平台相关的服务器存储选型设计。

posted @ 2015-12-31 09:38  huangchaolilli  阅读(754)  评论(0)  编辑  收藏  举报