“玄惭大师”谈双十一活动中云数据库保障经验

一、弹性扩容的两种方式

多数用户在双十一到来以前都会进行弹性扩容。常见的弹性扩容分为两类：本机升降级和跨机升降级。

本机升降级的话，比较简单。举个栗子，一个 6G/6C 的 RDS 数据库想要升级到 12G/12C，若是本机资源足够，则能够在本机完成升降级，无需迁移到其余机器上。

另外一种弹性扩容的方式是：跨机升降级。当本机资源不足以支撑升级所须要的资源的时候，须要将实例分配到另一台机器上。因此跨机升级须要使用数据库最近一次的备份和日志实时同步到新的主机上，保证新实例和旧实例的数据是彻底一致的。

这里须要注意的坑是：若是历史备份集较大或原主库压力较大时，会致使跨机迁移时间较长。

那些老司机踩过的坑：

1. 若是升级很长时间也没有完成，可能发生了跨机迁移或者主备存在延迟。
2. 可用区迁移、数据库版本升级耗时一般较长，是由于二者迁移都会发生跨机迁移。
3. 空间升级很是快，这是由于空间升级无需重启、迁移数据库，对业务也不会形成影响。
4. 弹性扩容时间的选择，建议在业务低峰期进行弹性扩容。 

二、双 11 期间，如何让访问链路更安全？

在云数据库中，访问链路分为两种模式：高安全访问链路和标准访问链路。双 11 期间，流量高的网站也会成为黑客的重点关注对象。因此建议商家提早采用高安全访问链路。

高安全访问链路在数据库的前面增长了一层代理层，全部请求在代理层都被解析，在解析过程当中添加了 SQL 拦截规则，进而能够防止 SQL 注入的攻击。

此外，高安全访问链路能够防止 90% 的链接闪断；并支持内外网地址同时访问；对短链接应用具备缓冲防御做用。
须要注意的是高安全访问链路较标准链路增长了 5% 左右的响应时间。
那些老司机踩过的坑：

1. 建议使用高安全访问模式，特别是短链接应用，高安全访问模式具备缓冲短链接对数据库冲击的效果。
2. 在标准访问链路切换到高安全访问链路时，切换过程最多会有30秒不可访问。
3. 若是ECS使用VPC，那么数据库只能选择高安全访问链路。
4. 访问链路上须要注意应用不要使用IP来访问数据库，避免因为IP变化致使故障。

三、双 11 的架构如何设计？

在历年的双 11 中，因为业务流量的突增，那些平时没有暴露出来的问题每每在这个时候爆发出来，因此咱们要把数据库这块地基打好，细节上作好，架构设计就须要咱们在这些上下功夫。

读写分离是常见的架构设计手段。RDS 支持只读节点，主库主要承担写和实时性要求高操做，一些复杂的分析计算业务操做最好不要放在主库上执行，而是选择放在只读节点运算。使用读写分离架构时，首先数据库版本须要升级到 MySQL 5.6 版本；同时目前 RDS 最多能够支持到五个只读节点。在读写分离时，延时是咱们必须关注的重点，目前 RDS 上经过源码改进并行复制，提高复制性能，下降了主库与备库之间数据同步的延迟。

引擎选择是数据库设计中很基础的一点，这里重点介绍下 Tokudb 引擎。日志型应用的特性是：写操做很高、读操做相对较少。Tokudb 引擎压缩比 Innodb 引擎高出 5~7 倍，适合写多读少的应用；同时，Tokudb 引擎 online ddl 速度较快，适合表很大须要常常 DDL 操做的应用。

对于大字段，数据库的更新写入压力过大，update、insert、delete 会致使 binlog 日志急剧增长，致使实例磁盘报警。所以在数据库设计时，要注意规避大字段引发的问题。常见的大字段有 varchar（8000）、text、blob、clob（sqlserver/mysql），使用时建议将大字段拆分出主表或者存入到其余存储系统中。

字段类型也是常见的问题之一。在设计开发阶段，就要避免数据库字段定义与应用程序参数定义不一致的状况。

字段大小一样会对数据库性能形成影响。字段长度超过索引容许的最大长度会致使索引字段被截断；同时，过长的字段定义会消耗大量的排序内存以及临时表空间。

索引设计也是你们常常犯错的一个点，在历年双十一保障中，索引出现的问题最多。
这里，重点讲解单条SQL的建立索引思路，常见的索引误区包括但不限于：

1. 对SQL语句的每一个查询条件字段创建一个单列索引，MySQL 只能使用其一个索引；
2. 对SQL语句的全部查询字段创建组合索引，致使索引远大于数据，同时性能低下；
3. 小表不创建索引。

四、双 11 的高可用配置如何搞？

RDS 自己是一个主备的高可用架构，当主库 Down 后，会快速切换到备库。在高可用架构中很重要的一点是数据同步，保障主备数据一致不丢失。

常见的高可用配置包括：

1. 单可用区：主备都在同一个可用区内，能够实现主备之间的快速切换；
2. Binlog 同步：采起异步和半同步的方式保障主备的数据一致；
3. Binlog 刷写：根据应用特色设置安全模式或者高性能模式；
4. 事务提交：默认采用最高安全模式。

此外，为了保障服务高可用，也能够采用多可用区配置，即主备在不一样可用区，此时，应用一样须要多可用区部署。须要注意 Binlog 在主备的同步模式，一般这种状况下开启半同步模式跨可用区访问，可能致使写入性能降低。
另外，还有一种跨数据中心的灾备方案，在历年的双 11 中，已经有不少用户实施过这样的方案，你能够选择在两个不一样的数据中心部署数据库和应用，好比在杭州和上海两个地区部署，两个数据中心的数据同步采用 DTS，以保证一个数据中心挂掉后，另一个数据中心可以接管起来。

此外，从 2015 年起，RDS 为天猫的商家后台数据库提供了异地灾备的功能。当主机房出现较大的负载压力、断网、断电等极端状况，RDS 可将商家的后台系统在 30 分钟内切换至灾备机房继续运行，以保障整体可靠性，进一步确保平台大型品牌商家双 11 期间后台系统安全、稳定。

五、针对双 11，如何作参数优化？

在 RDS 中，大部分参数是已经通过调优的，所以不少参数是不须要再去调整的。
可是用户能够根据应用场景的不一样选择合适的参数，这里重点看下 RDS 新增的四个参数优化：

1. rds_max_tmp_disk_space：控制 MySQL 可以使用的临时文件的大小，适用于一个 SQL 语句就消耗掉整个数据库的磁盘空间；
2. tokudb_buffer_pool_ratio：控制 TokuDB 引擎可以使用的 buffer 内存大小，适用于选择了 tokudb 做为存储引擎的场景；
3. max_statement_time：控制单个 SQL 语句的最长执行时间，适用于控制数据库中的慢 SQL 数量；
4. rds_threads_running_high_watermark：控制 MySQL 并发的查询数目，经常使用于秒杀场景的业务；

看完了“玄惭大师”的经验分享， 那么，你对大流量峰值下保障云数据库有什么好的经验能够分享吗？

原文来自：https://linux.cn/article-7941-1.html

本文地址：http://www.linuxprobe.com/doble11-operation.html