为什么不建议在 Docker 中跑 MySQL？

你去Docker Hub官网上面搜MySQL的官方镜像，下载量是1B+，1 Billion，10个亿。。。未来的服务一定是容器化。

当然评论里一大堆都说是下载量不是部署量，这个我认同，大多数都是下载来学习，练习，测试小流量业务系统，但人嘛总有惯性的，你熟悉容器化这套东西之后，真的会发现原来除了开发，运维也可以这么有趣，当熟悉了容器化并且一路下来过关斩将获得相当的经验后，未来的你也会倾向于用容器化部署吧。

说个用docker让人开心的事哈，甲方不知哪里搞来的报告说内部docker部署的MySQL有漏洞，要求对MySQL打上修复补丁，我们这边的运维老哥说8.x的MySQL直接升级镜像就行了，他把MySQL挂载的数据卷原封CP一份backup，然后就把最新小版本的docker镜像拉下来，在启动容器的脚本里，改改版本号，断网，停掉删掉旧容器，启动新容器，盯着docker log，直到提示升级成功，恢复联网，OK，搞一杯咖啡犒劳自己，整个过程轻松愉快。

我问他万一升级失败了咋办，删掉新容器呗，在启动脚本里改回旧版本镜像，在数据卷挂载回备份目录，再启动旧容器就行了，应急方案就是如此简单！

换做以前他在裸机这样子操作，内心慌得要死，必须要先把MySQL数据dump一份备份出来，配置文件也要备份一份，然后再用安装包（rpm或者deb）升级MySQL或者解压补丁tar包 ./install xxx.sh，操作过程中手心猛出汗，如果打完补丁/升级完成后MySQL因各种奇葩原因启动不起来，那就完蛋了，裸机系统回退MySQL版本更是搞死人，不单单考虑软件版本的回退，还要考虑可能因为版本升级失败导致的配置污染/权限污染/数据污染问题。最坏的情况是回退旧版本的MySQL也启动不了，需要卸载干净MySQL，再重新安装旧版本的MySQL，先导入备份配置，再导入之前dump出来的数据。

当然有个例外，如果是壕气的甲方要求部署Oracle等商业数据库，咱们就不用争论数据库到底是部署在裸机还是容器里了，因为商业数据库运维方面的事情有厂家派专人来背锅了，他们背锅侠就是把数据库部署在ram disk里也不关自己事哈哈。