percona与percona/percona-server Docker镜像的区别、成因及兼容性

很多人刚看到这两个同属Percona维护的Docker镜像，会误以为是重复建设的冗余资源，实际上二者并存的逻辑、核心差异和兼容性边界都非常清晰：

这两个镜像能同时存在，本质是不同发展阶段的发布体系遗留和延续的结果，并非两边无价值的重复开发：

• 早期Percona布局Docker镜像时，还没有搭建独立的全链路镜像发布运维体系。为了让用户能在Docker Hub核心官方库（带官方认证、无个人账号命名空间的镜像集合）中快速找到可信的Percona镜像，Percona按照Docker官方库的准入标准提交了入驻申请，通过审核后对应的镜像就是官方命名空间下的percona。
• 随着Percona逐步搭建起完整的自有产品镜像发布流水线，为了匹配自家全栈数据库产品的迭代节奏，Percona开始在自己的账号命名空间下维护独立的percona/percona-server镜像。按照Docker Hub的运营规则，已经入驻官方库的历史镜像不能随意下架，需要长期保留给已经形成固定使用习惯的老用户，两套镜像体系就一直并行运营到了现在。

二者的定位从设计阶段就存在本质差异，核心区别集中在三个维度：

• 维护目标不同
  官方命名空间下的percona镜像，核心目标是严格对齐Docker官方库的通用标准化要求，打造最轻量化、无生态绑定的通用Percona Server基础运行镜像，所有构建规则都满足跨场景通用要求，不会捆绑Percona自家的产品生态。
  Percona自有命名空间下的percona/percona-server镜像，核心目标是打造和Percona开源/商业产品体系1:1对齐的可交付镜像，从设计层面就适配Percona自家的运维、监控、备份生态的使用习惯。
• 迭代节奏不同
  官方命名空间下的percona镜像，每次版本更新、安全补丁都需要走Docker官方库的审核流程，提交构建脚本、等待官方团队核验通过后才能发布，迭代节奏往往滞后于Percona自己的正式版本发布节点。
  percona/percona-server镜像的构建和发布完全由Percona自己的CI流水线管控，和Percona Server的正式版本发布完全同步，新功能、安全补丁的上线速度更快。
• 内置组件不同
  官方命名空间下的percona镜像只保留Percona Server运行必需的最小组件集合，没有任何额外预装工具，镜像体积更精简。
  percona/percona-server镜像从构建阶段就会预装Percona生态常用的工具集，包括通用运维脚本、备份组件、监控对接适配层，不需要用户额外安装就能匹配企业级运维场景的需求。

两款镜像的兼容性边界非常清晰，不存在非黑即白的兼容或不兼容结论：

• 核心能力层面完全兼容
  两款镜像打包的Percona Server内核，都来自同一个官方开源仓库的对应版本源码构建，底层数据库引擎的逻辑没有差异。这意味着不管用哪款镜像初始化的数据库数据卷，都可以无迁移成本地挂载到另一款镜像的容器中直接启动，不会出现数据损坏、版本不匹配的问题。二者默认的核心运行路径（比如数据存储目录、主配置文件位置、初始化密码生成逻辑）也是对齐的，常规的单容器部署脚本不需要修改就能直接切换镜像。
• 扩展功能层面存在差异
  如果你的部署流程用到了percona/percona-server里预装的专属功能（比如自动备份脚本、内置的监控自动注册逻辑），直接切换到官方命名空间的percona镜像就会失效，因为后者根本没有内置这些组件。反过来，如果你基于官方命名空间的percona镜像做了自定义配置入口，直接切换到percona/percona-server镜像的话，可能会遇到后者内置的初始化脚本覆盖自定义配置的问题，需要手动调整启动参数适配。

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