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

开发者社区> 遥翔> 正文

阿里云RDS MySQL版 使用最佳实践

简介: # 如何选购RDS MySQL 目前使用MySQL,首推使用云盘版(ESSD云盘),虽然在磁盘读写RT上较本地盘差了一些,从而导致跑分软件跑出的数据不太好看,但是云盘有着诸多天然优势: ## 使用云盘还是本地盘? ### 备份 && 恢复 云盘(SSD云盘、ESSD云盘): 由于云盘天然支持使用快照进行数据备份,可以做到几百G乃至上T的数据都可以在几分钟内完成备份,同样基于备份进行数据还
+关注继续查看

如何选购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

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
MSSQL · 最佳实践 · 使用混合密钥实现列加密
摘要 在SQL Server安全系列专题的上两期月报分享中,我们分别分享了:如何使用对称密钥实现SQL Server列加密技术和使用非对称密钥加密方式实现SQL Server列加密。本期月报我们分享使用混合密钥加密方式实现SQL Server列加密技术,最大限度减少性能损失,最大程度保护用户数据安全。
1504 0
阿里云服务器端口号设置
阿里云服务器初级使用者可能面临的问题之一. 使用tomcat或者其他服务器软件设置端口号后,比如 一些不是默认的, mysql的 3306, mssql的1433,有时候打不开网页, 原因是没有在ecs安全组去设置这个端口号. 解决: 点击ecs下网络和安全下的安全组 在弹出的安全组中,如果没有就新建安全组,然后点击配置规则 最后如上图点击添加...或快速创建.   have fun!  将编程看作是一门艺术,而不单单是个技术。
3976 0
德歌:阿里云RDS PG最佳实践
5月27日云栖社区《云数据库RDS for PostgreSQL最佳实践》的直播分享顺利结束,来自阿里云的高级技术专家德歌与大家分享阿里云云数据库PostgreSQL的最佳技术实战,包括上云实战、数据迁移与同步、阿里云RDS相关周边组件用法、插件使用等内容。
14325 0
MSSQL - 最佳实践 - 使用SSL加密连接
--- title: MSSQL - 最佳实践 - 使用SSL加密连接 author: 风移 --- # 摘要 在SQL Server安全系列专题月报分享中,往期我们已经陆续分享了:[如何使用对称密钥实现SQL Server列加密技术](http://mysql.taobao.org/monthly/2018/08/03/)、[使用非对称密钥实现SQL Server列加密](http:/
2441 0
+关注
遥翔
MySQL运维
3
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载