本文是上海站 Meetup 讲师高日耀根据其分享内容整理的文章。点击查看视频回放

传统的物理部署方式，即把数据库部署在物理机上。对运维人员而言，会遇到图 1 中四个维度的挑战。

自建 MySQL 数据库集群，需要的硬件设备包括：服务器、网络交换机、内存、CPU、硬盘等 硬件设备。

硬件设备成本包括：选型、购买、维护、升级、损坏、数据丢失等。

每新增一套集群，都要进行操作系统安装、环境配置、MySQL 数据库安装、调试、性能优化、调参，后续还有系统升级，数据库升级…

针对不同对场景，比如一源一副本，一源两副本，多源多副本（MGR）等，需要编写对应的运维脚本。

在集群规模不大，MySQL 实例不多的情况下，运维人员尚且能应付，但是当集群不断增加，MySQL 实例达到成千上万个的时候，会极大的增加运维人员的负担，效率也会变得低下。

规模越大，出现误操作的概率会越高，严重的甚至要 “从删库跑路”。误删除关键数据，对于一般企业而言，应对能力较弱，危害很可能是致命的。

传统物理机部署不具备秒级弹性的能力，来针对 MySQL 在高峰或低谷时资源的自动弹性伸缩。例如，在业务高峰扩展 CPU、内存等资源，在低峰期收回闲置资源。

如果设计一次电商秒杀的场景持续时间是 30 分钟，那么我们可以在 30 分钟内，将网络、CPU、内存、磁盘等资源提升到最大。在秒杀结束之后，释放这些资源，极大节省成本。

针对如上挑战，主流的解决方案有两种：

物理机 + 管理平台

通过数据库管理平台，对数据库的统一管理，减轻数据库运维成本，提高数据库整体的可用性。

上云

将数据库部署到一个虚拟计算环境中，也就是常说的数据库上云。市面上各大云厂商都提供了 RDS 服务。

数据库上云可以实现按需付费、按需扩展、高可用性以及存储整合等优势。大大降低运维人员大规模部署和运维数据库的难度。

那么，还有没有其它方案来解决这些挑战呢？接下来为大家介绍数据库容器化。

据 CNCF 云原生产业联盟发布的《中国云原生用户调查报告2020年》显示，60% 以上的中国企业已在生产环境中应用容器技术，其中 43% 的企业已将容器技术用于核心生产业务。

相当轻量镜像标准化制作

使安装部署和交付非常高效。解决了 PaaS 服务打包复杂，环境不一致等问题。

轻量级虚拟化(rootfs/cgroup/namespace)

有助于资源共享，降级性能损耗

依托着 Google Borg 项目的理论优势，继承了 Google 的大规模生产环境的经验。K8s 提供了一套基于容器构建分布式系统的基础依赖。K8s 也成为容器编排的事实标准。

运维能力

路由网关、水平扩展、监控、备份、灾难恢复等。

声明式 API

描述容器化业务和容器间关系。

容器编排

按照用户的意愿和整个系统的规则，完全自动化地处理好容器之间的各种关系。

通过观察用户实际使用 MySQL 时对容器化产品的迫切需求，可以看出 MySQL 容器化进程势在必行。以 KubeSphere 开源社区为例，在其应用商店呼声最高的就是高可用版的 MySQL。

RadonDB MySQL 是一款基于 MySQL 的开源、高可用、云原生集群解决方案。支持一主多从高可用架构，并具备安全、自动备份、监控告警、自动扩容等全套管理功能。目前已经在生产环境中大规模的使用，包含 银行，保险，传统大企业 等。

RadonDB MySQL Kubernetes 支持在 Kubernetes 和 KubeSphere 上安装部署和管理，自动执行与运行 RadonDB MySQL 集群有关的任务。服务高可用由已经开源的 MySQL 集群高可用工具 Xenon 来实现。

每一个 Pod 里面的 Xenon 管理当前 Pod 中的 MySQL，主要获取并保存当前状态，获取当前执行的复制状态信息。

通用的包管理工具，将 K8s 资源模版化，方便共享。主要解决如下问题：

主要功能：

可以通过终端执行命令部署回显信息。

Operator 版针对特定场景做有状态服务，针对复杂应用的自动化管理。除了满足 Helm 版的需求之外，主要解决如下问题：

借助 Operator 框架，以及对精细粒度操控应用等功能需求。

【即将推出】主要功能：