可使用Docker镜像部署MySQL时为何仍需选用AWS RDS？

很多人一开始算成本的时候只会对比「EC2跑Docker的费用 vs RDS的订阅费」，完全没算自部署带来的隐形成本和潜在风险，除了大家熟知的基础备份能力，RDS的核心价值基本都是对着自部署MySQL最容易踩的坑做的原生兜底：

• 全链路托管运维，省掉无价值的重复劳动
  别以为拉个Docker镜像、启动容器就完事了：生产环境跑MySQL需要持续做的版本升级、安全补丁更新、内核参数调优、磁盘容量告警、实例异常排查，全是要专人持续投入的活。RDS把这些日常运维动作全部打包到服务里：小版本自动升级、安全补丁后台静默打、磁盘使用率阈值自动告警，甚至实例硬件故障时AWS后台会自动完成迁移恢复，根本不用你半夜爬起来捞容器日志、停业务导数据升镜像。对没有专职DBA的小团队来说，光这部分省下来的人力成本，往往比RDS的月费高得多。
• 原生高可用能力，不用自己搭复杂的故障切换链路
  单Docker容器跑的MySQL只要宿主机宕机就是直接业务中断；就算你想自己做主从高可用，得自己配置半同步复制、自己写故障切换脚本、自己做应用层的路由切换，中间但凡配置出点问题，就会出现主从数据不一致、切库切错的事故。RDS的多可用区部署是开箱即用的：主库故障时几十秒内自动完成主从切换，不需要人工介入，底层存储自动跨可用区做三副本冗余，单块磁盘损坏完全不影响数据可用性，可靠性比单EC2上挂个EBS卷跑Docker高几个量级。
• 内置安全与合规能力，减少自建审计系统的工作量
  自部署Docker版MySQL时，你得自己配置存储加密、强制SSL传输加密、维护数据库访问白名单，还要自己搭一套审计系统，记录谁在什么时间访问了什么表、做了什么变更操作；遇到等保、PCI这类合规检查时，得从零开始攒审计日志、整理合规材料，耗时久还容易漏项。RDS默认内置全链路加密能力，数据库操作审计日志自动生成，和IAM权限体系打通，谁能访问数据库、做了什么操作全留痕，合规要求需要的材料基本可以直接导出，不用自己从零搭安全体系。
• 配套生态无缝集成，省掉自建中间件的开发量
  自部署Docker版MySQL要做性能监控，得自己装Prometheus、配MySQL exporter、搭Grafana看板；要做慢查询分析，得自己导binlog、攒分析脚本；要做读扩容，得自己搭只读副本、配读写分离路由；要做跨区域容灾，得自己搭跨公网的同步链路，还要操心带宽成本、同步延迟、数据一致性问题。RDS把这些周边能力全部做进产品里：实例运行指标在控制台直接可查，慢查询自动捕获分析，加只读副本只要点几下按钮就自动完成主从同步，跨区域灾备只要配置一次就能自动同步，根本不用自己写脚本、搭中间件。
• 可靠的数据恢复机制，避开备份失效的经典坑
  很多人自己搭Docker版MySQL的备份链路时，要么写的备份脚本漏跑没监控，要么备份时锁表影响业务，要么备份文件和数据库存在同一块磁盘上，真到误删数据、库表损坏需要恢复时，才发现备份是坏的。RDS会自动做全量备份+连续的binlog增量备份，最长支持恢复到过去35天内的任意时间点，触发恢复时只要点一下按钮，就会自动拉起一个全新的恢复实例，不用你自己折腾备份链路，也不用担心备份文件失效的问题。

客观来说，Docker部署MySQL本身没有问题，它特别适合临时测试环境、轻量小项目的场景，但如果是跑核心生产业务，你省下来的那点RDS订阅费，最后多半会在半夜故障、数据丢失、合规过不了的时候加倍补回去。

内容的提问来源于stack exchange，提问作者CCCC