MySQL
去 Docker Hub 官网搜索
MySQL 的官方镜像，可以看到它的下载量达到了 1B+，也就是 10 亿次以上。这说明容器化技术已经成为未来服务部署的重要趋势。当然，也有人在评论区指出，下载量并不代表实际的部署量，这点我完全认可。大多数用户可能只是下载镜像用于学习、练习或者测试一些小流量业务系统。然而，
人类的行为往往带有惯性。一旦你熟悉了容器化的操作方式，你会发现不仅开发工作变得更加高效，运维也可以变得如此有趣。当你积累了足够的容器化实践经验后，在未来的项目中，你很可能会优先选择容器化部署。举个例子来说，有一次甲方根据一份报告指出我们内部通过 Docker 部署的
MySQL 存在漏洞，要求我们必须打上修复补丁。我们的运维同事处理得非常轻松：对于
MySQL 8.x 版本，他直接升级了镜像。他首先将挂载的数据卷完整复制了一份作为备份，接着拉取了最新版本的小版本 Docker 镜像。然后在启动容器的脚本里简单修改了版本号，断开网络后停止并删除旧容器，再启动新容器。整个过程中，他密切
监控着 Docker 日志，直到看到升级成功的提示才重新连接网络，最后给自己倒了一杯
咖啡犒劳自己。整个流程一气呵成，完全没有压力。我好奇地问他：如果升级失败怎么办？他淡定地那就删掉新容器，在启动脚本里改回旧版本镜像，把数据卷挂载回之前的备份目录，再启动旧容器就行了。应急方案竟然如此简单！而在以前，如果是在裸机上进行类似的操作，那可就麻烦多了。运维人员必须先手动 dump 出
MySQL 数据并备份配置文件，然后再通过安装包（比如 rpm 或 deb）升级
MySQL 或者解压补丁 tar 包运行安装脚本。整个过程紧张兮兮，手心直冒汗。更糟糕的是，如果打完补丁或升级完成后，
MySQL 因为各种奇怪的原因无法启动，那简直就是灾难。而且在裸机系统上回退
MySQL 版本更是令人头疼，除了需要考虑软件版本的回退，还要解决因版本升级失败可能导致的配置污染、权限污染以及数据污染等问题。最坏的情况是，即使回退到旧版本，
MySQL 也无法正常启动，这时就必须彻底卸载干净
MySQL，重新安装旧版本，再导入备份的配置和数据。不过也有一个例外情况：如果是高端客户明确要求部署 Oracle 等商业数据库，那么我们就无需争论数据库是否应该部署在裸机还是容器中了。因为商业数据库的运维工作通常由厂商专门派遣的技术人员负责，他们承担所有相关责任。哪怕是把数据库部署在 ram disk 中，也与我们无关了，毕竟那是他们的锅。
