容器化 | MySQL on K8s 开源开放的高可用容器编排方案

本文探讨了MySQL在容器化,尤其是Kubernetes环境中的应用,阐述了MySQL运维面临的挑战,如成本、传统部署、运维和资源弹性问题。通过Kubernetes和Docker,实现了更高效的数据库管理,提供了RadonDB MySQL作为高可用解决方案的例子,包括Helm版和即将推出的Operator版,以实现自动化运维和资源弹性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

作者:高日耀 资深 MySQL 内核研发

本文源于作者在 KubeSphere & Friends 2021 上海站的演讲内容《MySQL on K8s:开源开放的 MySQL 高可用容器编排方案》。

MySQL 是世界上最流行的开源数据库,在容器及 K8s 技术出来之前,就已经在各行各业中广泛的应用。本文将为大家分享 MySQL 容器化方面的一些实践。

| MySQL 运维有哪些挑战?

图1.运维的四个维度

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

1、成本

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

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

2、传统部署

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

3、运维

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

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

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

4、资源弹性

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

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

主流解决方案

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

  1. 物理机 + 管理平台

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

  2. 上云

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

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

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

| 为什么要做数据库容器化?

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

容器技术

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值