RDS开发一日测试手记，binlog日志问题是硬伤

昨天因为公司新站上线，在考虑到流量和安全性能的前提下，我开始着手研究RDS数据库，在经过一天的测试使用发现，RSD的速度和可靠性确实很高，但是有一个异常情况又是我们开发者担忧的。

在RDS运转过程中会对数据进行备份，每一段数据有备份其中一种形式的备份文件就是binlog，我的一个数据库在初期建立只有4.0M左右，但是binlog的速度确达到1小时将近500M也就是输10小时就是5G，整体一天24小时下来就达到10多个G的binlog数据。

RDS数据库的磁盘是很贵，一般最低套餐都是5G的硬盘容量，也就是说，我们必须每天手动的释放RDS的binlog数据，不然的话数据库就会直接卡爆，导致无法访问。

如果不能解决RDS的binlog问题，我们最直观的问题就是要每天手动的清理日志数据，这样与一个不稳定的服务器是没有什么本质区别的实在是没有必要。

经过一天的测试之后，反复与阿里云售后工程师进行工单交流之后也是没有得到很好的处理方案：

1. Binlog 文件是RDS HA 架构的基础，是不能够关闭的。

2. Binlog 默认会在实例上保存 1天左右，超过时间会自动上传OSS并从实例上删除。

3. 查看您的实例，规格为5GB， 这两天容量使用的最大值在 2.5GB 左右； 如果真的使用数据量比较大，担心超过容量被锁，建议您单独升级下磁盘空间。

4. 您可以从控制台 备份恢复=》Binlog 列表下载相关binlog 分析下为什么产生大量的Binlog数据。相关命令 mysqlbinlog -v --base64-output=decode-rows binlog_file_name

经过一天一夜的研究和测试，最终我还是选择了放弃RDS，回到自建数据库上来，毕竟在服务器出现问题的时候，可以一键重启，解决当前问题。