阿里云还刚成立不久时，Vans 爱好者就举家搬入了 ECS 云服务器。由于初期阿里云主机硬盘 IO 普遍不足，加上通过论坛活动获得了一年的 RDS 免费使用权（主要原因），所以很早便采用了数据库和主机分离的架构。
不过随着 VXXSFXXS 上线、业务量进一步扩大，之前的小内存 RDS 已经远不能满足需求，在一次 RDS 高负载宕机之后，妥妥将其升级到了 2C4M 的配置。但是升级过程一波三折，一句话概括就是：由于之前数据库配置太差，导致付费了之后，也没有足够的资源完成配置升级。晚上 20:00 故障发生、发现付费后升级配置进度频繁卡死、无限重复后，通过各种加急工单催促阿里云 “工程师” 协助处理，但都没有任何效果。最后迫不得已在凌晨断掉所有请求，腾出资源进行配置升级，直到早晨才恢复正常。
经过这次故障事件之后，对阿里云 “工程师” 的极致差评服务倍感失望。同时由于 RDS 仍是单节点版本，仍然怀着忐忑心情担心故障重演，但奈何预算不够，只能这样将就使用了一年。
在 RDS 快到期、且有 618 活动的情况下，注意到阿里云在大力宣传 PolarDB 这个自研的关系型数据库。它号称 100% 兼容 MySQL（也有其他版本），并在性能上有巨大提升。当时还有 RDS 免费迁入等活动，于是就趁着活动优惠，将数据库换到了 PolarDB MySQL 多集群版本。
PolarBD 的迁入过程非常的丝滑顺畅，基本只要严格仔细按照官方文档操作即可完成：https://help.aliyun.com/document_detail/121582.html
迁移完成之后，由于 PolarBD 实例费用和数据库占用空间是分开付费的，而我们的数据库容量也不是很大，所以就没有着急购买存储包。
但是随着使用时间增加，这周阿里云开始频繁告警通知账户余额不够，由于出差在外也没有太过留意，在周末充值了 200 元，周一就又告警额度不足，才意识到问题严重。
遂打开阿里云账户费用账单，果然是 PolarBD 的存储空间费用仅这一两天就到了 200+ RMB。结果不看不知道，一看好家伙：
于是开始查 PolarDB MySQL 产品文档，看如何处理。发现 PolarDB 实际上默认使用了更高级别的物理日志代替 Binlog（Binlog 通常记录数据库改动等信息，方便备份恢复），所以应该默认情况下 Binlog 是关闭的。
而我们碰到的这种情况，想当然都能猜到是由于数据迁移导致，原本 RDS 开启了 Binlog，故此迁移时 PolarDB 保留了此配置，而且由于 PolarDB 默认保留 2 周的本地 Binlog，才会占用到如此之大的空间。这些 Binlog 都是需要按照存储空间付费的。
由于使用的是 MySQL 5.7，影响本地 Binlog 的配置参数有两个：loose_polar_log_bin 通过 ON/OFF 控制是否开启 Binlog；binlog_expire_logs_seconds 通过秒为单位的值控制 Binlog 存储时长，超时直接删除过期数据。
直接关闭 Binlog 的话，已有的 Binlog 文件还会一直保留，不会默认删除，所以需要先将 binlog_expire_logs_seconds 设置成一个除 0 以外较小的值（0 表示不删除 Binlog 文件）。譬如我就是改成了 1 秒，然后再将 loose_polar_log_bin 设置成 OFF 关闭。
更具体的可以参考官方文档：https://help.aliyun.com/document_detail/113546.html