如何选购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保障很低！
单机版一般来说，只建议作为开发调试，或者是测试环境使用！

高可用版

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

三节点企业版

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

使用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进行主从同步。

这种格式的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天可以通过备份恢复。假如您的数据比较敏感，也可以在回收站功能中立即销毁实例。