知识中心

阿里云RDS MySQL版 使用最佳实践-阿里云开发者社区

2020-03-09 00:00:00 mimukeji

如何选购RDS MySQL

目前使用MySQL,首推使用云盘版(ESSD云盘),虽然在磁盘读写RT上较本地盘差了一些,从而导致跑分软件跑出的数据不太好看,但是云盘有着诸多天然优势:

使用云盘还是本地盘?

备份 && 恢复

云盘(SSD云盘、ESSD云盘):
由于云盘天然支持使用快照进行数据备份,可以做到几百G乃至上T的数据都可以在几分钟内完成备份,同样基于备份进行数据还原(克隆实例),也可以超快的完成。
再来看看本地盘:
本地盘由于无法采用快照备份,为了保证备份的可靠性,备份也不能存储到本地,当前是将备份不落地直接备份传输到OSS存储,通常备份到OSS一个3T的实例就需要1天以上来备份了,同样如果需要恢复,虽然比起备份会快些,差不多也要大半天了,假如数据出现问题,一般是非常着急的场景,#如果采用云盘,可以大大节省宝贵的救火时间#。
还有另外一个问题,由于使用xtrabackup备份,会需要将所有的库表文件打开,受限于操作系统,能同时打开的文件句柄是有限的,假如我们库里有60万以上的表,那么很有可能无法完成备份。假如长时间不备份,数据的风险不言而喻!

性能

本地盘相较于云盘来说,由于IO操作不经过网络,所以RT上来说一定是本地盘更好。但是IOPS可不一定哦~
ESSD云盘是SSD云盘的升级版,相较于SSD云盘来说,ESSD的存储系统内部采用了更高效的通信机制,从而使得ESSD云盘有了质的飞跃!ESSD PL1级别性能和SSD云盘相差不大,但是当达到PL2甚至PL3级别时,性能可以说是突飞猛进。其中PL3级别IOPS最高可达1000000;我们本地盘的版本独占物理机最高IOPS也只能达到144000,相较于PL2级别的云盘稍高一些。

单机版

首先,重要的事情说三遍!不建议使用单机版作为生产环境!不建议使用单机版作为生产环境!不建议使用单机版作为生产环境!
为什么呢?从成本考虑单机版确实可以节省一大笔开销,但是受限于单机版的架构,在发生故障时,单机版是无法快速恢复的!所以同样的单机版的SLA保障很低!
单机版一般来说,只建议作为开发调试,或者是测试环境使用!

高可用版

作为生产环境标配版本,兼顾成本和可用性,在大部分场景下推荐使用此版本!当前主可用区功能已经上线,实例默认创建在同城双机房,实现跨机房容灾能力!
image.png

三节点企业版

推荐金融领域的产品使用该产品,由于对内核进行了深度改造,采用了大名鼎鼎Paxos一致性协议保证了RPO(Recovery Point Object)=0,即在任何使用场景都不会丢失数据,可靠性非常高!
同城三机房部署,具备跨可用区容灾能力。还可以搭配异地灾备实例满足两地三中心的容灾要求。
想了解更多三节点企业版的优势,可以到阿里云官网查看相关介绍哦~
image.png

使用RDS的注意事项

实例卡慢,重启实例能立马解决?

大部分情况下,重启实例都不能解决实例卡慢的问题!大部分情况下,重启实例都不能解决实例卡慢的问题!大部分情况下,重启实例都不能解决实例卡慢的问题!
重要的事情还是要说三遍!
重启之前请先自查数据库运行情况,如果是存在DDL操作(可通过show processlist;查看是否有DDL语句在执行)或者大事务(可通过查看INFORMATION_SCHEMA.INNODB_TRX表来确认)的情况,重启实例反而会造成长时间的不可用!因为数据库在打开端口允许连入之前,需要保证自身数据一致性,所以需要做recovery或者undo的操作,根据事务的已经执行的时长或是事务本身要执行的时长,强制重启可能导致实例数小时无法正常使用!

员工删库,数据丢失?不存在的!云上RDS丰富的功能,护航您的宝贵数据!

近期互联网圈内,“微盟”事件可谓是闹得沸沸扬扬,删库后6天都没能完全恢复数据,究其原因还是他们自建了数据库,因为是自建的,运维管理人员掌握了极高的权限,甚至可以root权限登机器进行极其危险的操作,哪怕不是有意为之,一条错误的指令就可能造成极其严重的损失。
然而上云后,可以实现对数据库实例,乃至库表级别的细粒度权限控制,运维人员得不到不该有的权限也就无法进行如此高危操作。就算是执行了库级高危操作drop database,云上也是有很多解法的,完全不需要花6天之久进行恢复:
解法1:
使用云上冷备+binlog按时间点克隆,如果发生此类异常,云盘实例一般只需要几分钟的基于快照创建磁盘+数小时binlog重放即可完全恢复,本地盘实例也可以根据实例备份大小,一般也完全可以在1天内完全恢复。
解法2:
设置延迟读库,在发生删库事件后,立即停止复制,找到发生删库的时间点让binlog应用到删库之前就可以提供只读服务了,之后通过解法1所述的克隆实例恢复,一般也可以在1天内完全恢复读写。
解法3:
目前RDS本地盘已经支持分库分表恢复,通过这个功能可以表级粒度原地恢复,由于减少了恢复时数据处理量,可以相较于克隆实例更快速的完成恢复动作!

不使用MyISAM引擎

为什么不推荐使用MyISAM引擎?因为MyISAM引擎本身不支持事务,这是一个很大的问题,在高可用版本中,不支持事务会经常因为各种原因(比如OOM自动重启,比如主备切换等),导致备库和主库的不一致,这是从原理上就决定的。而且,由于不支持事务,我们在进行备份时,只能选择将整个数据库实例加锁,从而阻塞写入,来保证备份的一致性,假如我们有几G的非事务数据,那么备库损坏时需要修复时(通过主库备份来重建备库),可能就有数十分钟不可写入了,对实例的可用性有不小的冲击。此外,除了不支持事务意外,MyISAM引擎本身有很多缺陷,这些缺陷同样会导致数据损坏甚至丢失,引发主从数据不一致,现代数据库看来,相较于InnoDB,MyISAM也没有什么明显优势,所以还在使用MyISAM引擎的需要尽快评估自己的业务尽快迁移到InnoDB。

请给所有表加主键(或隐式主键)

为了尽量保证主备数据一致,我们系统默认采用Row格式的Binlog进行主从同步。
image.png
这种格式的Binlog在有主键时会使用主键作为Where子句的判断条件写入binlog如果没有主键时,我们Update 多条数据,会产生使用普通字段作为Where判断条件的Binlog,这种Binlog在从库应用时,相较于主键一般都需要进行全表扫描,再加上主库执行一条DML,从库要执行N条,从而导致从库应用效率远不如主库,从而迅速产生严重的主备延迟。如果存在主键,那么通过主键的聚簇索引可以快速定位到要修改的记录了,从而主库和从库可以保持基本追平的状态。

  • 备库延迟是个很严重的问题,在主库发生宕机时,为了保证数据一致性,系统会判断备库延迟在一定范围内才允许HA切换,如果备库长期保持延迟,那么高可用功能相当于没有了!

此外,没有主键引起的长时间的备库延迟,我们的备份也只能在主库去做(否则数据是很久之前的),备份多多少少的还是要锁表一段时间,影响主库的可用性。

由于存量的无主键表,增加主键可能影响到业务逻辑,所以我们也提供了隐式主键功能,该功能现已默认开启,但是存量表需要变更才能使用,新增表如果没有提供主键默认增加一个隐式主键,保证row模式Binlog可以快速应用,有需要改动的可以咨询阿里云售后。

避免大量集中单表操作

由于数据库默认的并行复制功能是基于库表级的并行复制(可参考我的上一篇文章,有介绍各版本并行复制功能),大量的单表操作同样会造成不能并行复制的问题,从而影响备份以及HA等相关功能。

大事务(长时间查询、数据变更)

根据mysql的设计,事务在提交时才会写入binlog,较大的事务,例如执行1小时以上的事务,在完成后写入binlog,从库也需要1小时来完成binlog的应用,从而导致这期间备库延迟。在备库延迟时,同样会影响备份和HA相关功能。

大促前提前预估、规划升级,保证实例磁盘、规格充裕,就是保住业务自己的生命线!

实例业务突然上量时,不仅仅是产生的数据会占用大量磁盘空间,由于除了数据本身,还会产生大量的Binlog,根据不同的binlog上传、保留策略(可在控制台配置),可能会发生 binlog占用大量空间迅速让实例空间满锁定的情况。
由于实例升级大部分情况下都需要做数据迁移(特别是本地盘的情况,数据搬迁会随着数据量大幅增加),此时进行实例升级,可能也不会特别顺畅:业务压力大时,如果优化不好可能会有严重的备库延迟问题,追不上就没办法切换到升级后的新实例,届时只能停服停写来完成升级,对业务的损失不可计量!
请在业务上量前,尽量评估好数据规模,至少提前一周升级RDS,并做好压测,避免在业务高峰时升级升不上去,造成业务上的严重损失!

包年包月到期怎么办?

阿里云为尽最大可能保障您的数据,已经将实例过期后数据保留延长到15天,15天内都可以在控制台的回收站功能中操作恢复,其中7天内续费可以秒恢复,7~15天可以通过备份恢复。假如您的数据比较敏感,也可以在回收站功能中立即销毁实例。
image.png