云数据库

rds, 全称是关系型数据库系统。 这个在所有云上也都有，一个云要是没有数据库，那你让别人怎么用呢。不过我记得早些年oracle云上就没有数据库的，只有云服务器。

之前我们说的负载均衡和云服务器都是属于IAAS层的，到了rds这块就属于PAAS层面的东西。后面的redis, s3这些都属于PAAS层的东西。

我们以MySQL for rds为例来说吧，这个是所有厂商都有，其他什么mongodb, postgresql这些未必所有厂商都会去做。从客户角度来说，少依赖于云厂商的专有组件总是好的，至少你后面想迁移都是随时迁移的。

既然是MySQL了，那MySQL版本的支持是一个很重要的指标，有些厂商是跟着MySQL官方走的，官方停止更新了，那他们也会停止更新。比如aws这样的，官方5.7版本停止维护后，aws这边就需要你强制升级到8.0（不升级就会收双倍的钱，并且1年后还要强制升级），而且升级期间是有几分钟时间只读不可写的状态。

所以在用这种rds的时候一定要保证及时升级，如果你的是那种老旧项目，连开发都找不到了，那就只能自己想办法了。

主从架构

这个是作为MySQL数据库必备的功能了，除了一些所谓经济型的产品，一般都会有主从。一个比较重要的指标就是当主挂了需要多久才能切换成功。而且切换过程中的状态是不能写，还是不能读，还是不能连接，这些都是很重要的指标。

另外一点因为是主从架构，那平时那个从我们是可以读取的吗？还是说隐藏掉的。这样对于成本也是有比较的影响的。

最后是主从读写分离是需要自己去做还是云厂商的proxy来做的， 如果是云厂商的proxy来做，那需要确认哪些条件下读，哪些条件下写，这个需要自己去验证。我见过很多国内的一些厂商，明明写着proxy自动读写分离，但是实际上都是去读写主的节点，只有非常少的情况下才会去到从节点上读。 这里有些是事务的原因，也有是主从复制延迟的问题。

磁盘

云盘： 数据是存放在云盘的架构，那未来的扩容这些就会相对比较简单，但是受限于现在的网络瓶颈，它的性能整体还是比较弱的，io延迟会500微秒，而且价格上其实并不便宜。但是出问题可以很快的迁移。

本地盘：数据是存放在nvme的本地盘的，所以一旦所在物理机宕机的话，那就要靠主从切换来进行了。相对来说价格会便宜，io延迟就50微秒，是云盘架构的1/10左右。

默认配置

随便搞过数据库的都知道，数据库的配置项多如牛毛。但是在不同的云厂商上，都有不同的默认配置，因此你必须导出一份你们自己使用的配置，并在所有云厂商里都导入保持一致。我一般的做法是每个数据库都保存一份这样的配置。但是有些数又是云厂商根据规格固定的，比如最大连接数，还有一些query cache等等。

常见的

1. innodb_flush_log_at_trx_commit到底是设置为0,1,2 ，但是这个其实又会影响到主从同步的延迟。
2. 大小写是否敏感
3. server字符集
4. timezone
5. 临时表大小

以上是比较容易有问题的地方，可以先提取出来统一一下，不然后患无穷。

监控

这个一定要看云厂商的监控是否齐全。不光是常见的内存，cpu，磁盘iops，磁盘使用量，tps, qps这些，还有innodb自己的一些监控，如缓存命中率等等。以及云厂商一些大事务监控什么的，这个就非常方便去排查问题了。

这个之前我们就碰到aurora里居然没有磁盘使用量的监控，虽然aurora是存算分离的，但是其实MySQL单表的大小也是有上限的，你这都不显示也不大好吧，而且这个这个数获取应该很容易。

另外一个就是监控的间隔，一般都是1分钟级别的，你要秒级得加钱了，但是也有一些厂商是5分钟级别的，这要出了问题那真的是黄花菜都凉了，所以针对那些厂商，我们自己更多的是用的自己的业务程序的报警和云厂商监控组合来看的。

可管理性

1. 支持跨az部署：就是master和slave节点要在同一region的不同az里。
2. 备份：提供增量，全量的的备份策略。提供额外的备份下载。
3. 异地备份：跨az还不大够，最好来个跨南北，跨东西的异地备份。保证你最重要的数据甭管花多少时间还能恢复回来。
4. 权限账号：可以在控制台添加root级别账号，也可以添加某些库或者表的只读账号。千万别都自己去数据库里手动grant, 那样审计就很麻烦。
5. 恢复：支持恢复到某一个秒。
6. 弹性伸缩：是否支持设置某个cpu阈值来进行自动扩容和缩容等等，帮助节省成本。但是一定要知道带来的风险。确认完了再搞。
7. 访问白名单：内网访问白名单，公网访问白名单。
8. 慢日志：慢日志明细要有，方便经常内部排查问题。
9. sdk：api和sdk的支持情况，主要是监控和报警那块的。
10. 其他相对优先级低一点。
    1. ssl连接：这个个人感觉有了白名单的话意义不大，还增加了无谓的开销，毕竟不光是建连的时候有开销，你后面每次往返都是有开销的。对于核心或者涉及个人隐私数据通过kms这种加密存储就行。这种对于安全收效成果更好。
    2. 全球多活： 这个看业务情况了。个人觉得多活意义不大，而且这种实现一般都是云厂商自己搞的，你非要用上了，那以后怎么迁移呢？
    3. 审计：这个看公司吧。

这里列的比较细，因为个人确实看到有些云厂商就直接搞了个PhpMyAdmin就算是一个管理后台了，这点真让人无语。

压测

很多人会用sysbench来进行压测，这个测试结果只能作为参考。最好还是用自己线上的业务来进行测试。

测试中需要注意的事项是：

1. 数据量要够：一定要模拟线上的数据量，要是数据量不够，那测试出来的肯定是不准的。毕竟到了数据量之后MySQL的Optimizer和Query Cache都可能会有不同表现。
2. 并发一定够：不能测试并发的时候不考虑延迟，测试延迟的时候不考虑并发。测试前一定要有对响应时间有提前的预期。
3. 做好监控：把MySQL的各项性能指标都需要提前准备好，一旦压测结果不符合预期，我们就需要靠这些监控来排查问题了，不然不如不压。