实测对比：哪款开源 Kubernetes MySQL Operator 最值得用？（2026 深度评测）

小猿姐2026-04-14 1:33

本文基于作者在 AWS EKS 上对四款 MySQL Operator 的真实部署与测试，覆盖集群搭建、高可用切换、弹性扩缩容、动态参数、TLS 等维度，适合正在评估 MySQL Kubernetes 方案的工程师参考。

一、为什么要做这次对比测试？

过去两年，越来越多的团队开始将 MySQL 从虚拟机迁移到 Kubernetes。驱动力很直接：统一的基础设施管控、更快的弹性扩容、以及 GitOps 风格的声明式运维。

但随之而来的问题是：MySQL Operator 怎么选？

我们决定不依赖文档和宣传材料，而是直接在 AWS EKS 上把四款 Operator 都装起来跑一遍，看看实际表现如何。整个测试过程没有提前准备 runbook------我们用 Claude Code 直接检索各 Operator 的官方文档和 GitHub README，让它帮助理解 CRD 结构和部署步骤，然后在集群上实际执行。这种方式最接近一个新团队"第一次上手"的真实体验，也更容易暴露文档缺失和 API 设计问题。

测试环境：

  • 平台：AWS EKS，Kubernetes v1.31.14
  • 节点：3 个 m5.xlarge（4 vCPU / 16 GiB RAM）
  • 时间：2026 年 4 月

测试对象：

Operator 版本 维护方 开源协议
KubeBlocks MySQL Operator 1.0.2 ApeCloud AGPL 3.0
Percona Operator for MySQL ps-operator v1.0.0 Percona Apache 2.0
MySQL Operator for Kubernetes 9.2.0 Oracle 官方 GPL 2.0
Bitpoke MySQL Operator v0.6.3 Bitpoke Apache 2.0

测试维度包括了SRE/DBA 常用的 17 项功能矩阵，包括：拓扑支持、高可用 RTO、弹性扩缩容、动态参数、TLS、Prometheus 监控等。

二、部署实录：门槛差异明显

我们的测试方式是：用 Claude Code 实时检索各 Operator 的官方文档和 GitHub README，读懂 CRD 结构后直接在集群上操作，遇到报错就地排查。这样的测试更接近一个新团队"第一次上手"的真实体验。以下是各 Operator 完整的部署实录。

KubeBlocks（总耗时：约 5 分钟）

KubeBlocks 通过 Helm 安装控制平面，MySQL addon 单独启用：

bash 复制代码 
helm repo add kubeblocks https://apecloud.github.io/helm-charts
helm install kubeblocks kubeblocks/kubeblocks \
  --namespace kb-system --create-namespace

kbcli addon enable mysql

创建集群使用统一的 Cluster CRD：

yaml 复制代码 
apiVersion: apps.kubeblocks.io/v1
kind: Cluster
metadata:
  name: kb-mysql
  namespace: kb-mysql-test
spec:
  terminationPolicy: WipeOut
  componentSpecs:
    - name: mysql
      componentDef: "mysql-8.0"   # 半同步主从；MGR 改为 "mysql-mgr-8.0"
      serviceVersion: "8.0.35"
      replicas: 3
      resources:
        limits:
          cpu: "500m"
          memory: "1Gi"
        requests:
          cpu: "500m"
          memory: "1Gi"
      volumeClaimTemplates:
        - name: data
          spec:
            accessModes: [ReadWriteOnce]
            resources:
              requests:
                storage: 20Gi

实测体验：集群 3 分钟内就绪，所有密钥自动生成，连接信息通过 Secret 获取：

bash 复制代码 
kubectl get secret kb-mysql-mysql-account-root -n kb-mysql-test \
  -o jsonpath='{.data.password}' | base64 -d

Percona ps-operator（总耗时：约 90 分钟，含多次重装）

第一波：Helm Chart 版本找不到

Claude Code 根据文档最初尝试：

bash 复制代码 
helm install percona-op percona/ps-operator --version 0.9.0

报错：Error: chart "ps-operator" matching 0.9.0 not found。文档版本和实际 Chart 版本对不上。检索后发现正确的 Chart 是 percona/ps-operator（不带版本号，最新稳定版 1.0.0），另外数据库实例需要用单独的 percona/ps-db Chart，operator 和实例是分开安装的。

第二波：MGR 副本数校验失败 + orchestrator 必填字段

第一次尝试部署了 2 副本：

bash 复制代码 
helm install percona-db percona/ps-db \
  --set mysql.clusterType=group-replication \
  --set mysql.size=2

CRD webhook 直接拒绝：

csharp 复制代码 
The PerconaServerMySQL "percona-db" is invalid:
spec.mysql.size: Invalid value: 2: must be >= 3 for group-replication

MGR 模式要求至少 3 个节点（奇数）。改成 size=3 后重试，operator 又报：

csharp 复制代码 
orchestrator.size is required when orchestrator.enabled=true

文档里 orchestrator 部分写的是可选，但实际 v1.0.0 版本的 CRD 校验把它列为必填。补上 --set orchestrator.enabled=true --set orchestrator.size=1 后通过校验。

第三波：OOMKill 导致 datadir 损坏，被迫重装

Pod 起来后 MySQL 容器反复 OOMKill：

sql 复制代码 
Last State: Terminated  Reason: OOMKilled

依次尝试了 512Mi → 1Gi，都 OOMKill。根本原因：MySQL 8.4 + MGR 协议的内存开销显著高于普通主从，实测至少需要 2Gi 才能稳定启动。

但升到 2Gi 后发现 StatefulSet 的 resource limit 没更新（Helm upgrade 没有触发 Pod 重建），需要手动 force-delete：

bash 复制代码 
kubectl delete pod percona-db-ps-db-mysql-0 -n percona-test --force

此时又发现之前 OOMKill 发生在 MySQL 初始化阶段，导致 datadir 写了一半，Pod 重建后进入 crash loop。必须彻底清除数据：

bash 复制代码 
helm uninstall percona-db -n percona-test
kubectl delete pvc --all -n percona-test

从零重装，指定 2Gi 内存，约 8 分钟后三个 Pod 全部 2/2 Running，MGR 成员状态正常：

sql 复制代码 
MEMBER_HOST                                           MEMBER_STATE  MEMBER_ROLE
percona-db-ps-db-mysql-0.percona-db-ps-db-mysql...   ONLINE        PRIMARY
percona-db-ps-db-mysql-1.percona-db-ps-db-mysql...   ONLINE        SECONDARY
percona-db-ps-db-mysql-2.percona-db-ps-db-mysql...   ONLINE        SECONDARY

最终可用的安装命令：

bash 复制代码 
helm repo add percona https://percona.github.io/percona-helm-charts
helm install percona-op percona/ps-operator -n percona-test --create-namespace

helm install percona-db percona/ps-db \
  --set mysql.clusterType=group-replication \
  --set mysql.size=3 \
  --set mysql.resources.limits.memory=2Gi \
  --set mysql.resources.requests.memory=2Gi \
  --set orchestrator.enabled=true \
  --set orchestrator.size=1 \
  -n percona-test

Oracle 官方 Operator（总耗时：约 40 分钟）

安装分两步：operator 和 InnoDBCluster 实例。

bash 复制代码 
helm repo add mysql-operator https://mysql.github.io/mysql-operator/
helm install mysql-op mysql-operator/mysql-operator -n oracle-test --create-namespace

# 先创建 root 密码 Secret
kubectl create secret generic oracle-mysql-secret \
  --from-literal=rootPassword="MyP@ssw0rd" \
  -n oracle-test

kubectl apply -f - <<EOF
apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: oracle-mysql
  namespace: oracle-test
spec:
  secretName: oracle-mysql-secret
  tlsUseSelfSigned: true
  instances: 3
  router:
    instances: 1
  version: "9.6.0"
EOF

遇到的问题：Router Pod 风暴

InnoDBCluster 创建后，Router Deployment 进入快速 crash/restart 循环。原因是 MySQL 实例还在初始化，Router 无法连接，每次失败后 Kubernetes 快速重启，加上 Router 镜像本身较大，节点磁盘被多个并发拉取的镜像塞满，触发 DiskPressure，进而把其他 Pod 驱逐出去。高峰时 oracle-test namespace 下出现了 25 个 Router Pod 同时存在（大部分处于 Failed/Evicted 状态）。

手动清理失败的 Pod：

bash 复制代码 
kubectl delete pods -n oracle-test \
  --field-selector=status.phase=Failed

清理后等待 MySQL 实例初始化完成（约 15 分钟），Router 自然稳定在 1 个。整个集群就绪大约需要 25 分钟。

文档体验：Oracle 官方文档比较完整，CRD 字段清晰，Claude Code 能直接读懂并生成正确的 YAML，没有遇到字段校验类的报错。

Bitpoke MySQL Operator（总耗时：约 8 分钟）

Bitpoke的部署比较顺利：

bash 复制代码 
helm repo add bitpoke https://helm-charts.bitpoke.io
helm install bitpoke-op bitpoke/mysql-operator -n bitpoke-test --create-namespace

# 先创建 root 密码 Secret
kubectl create secret generic bitpoke-mysql-secret \
  --from-literal=ROOT_PASSWORD="Test@1234!" \
  -n bitpoke-test

kubectl apply -f - <<EOF
apiVersion: mysql.presslabs.org/v1alpha1
kind: MysqlCluster
metadata:
  name: bitpoke-mysql
  namespace: bitpoke-test
spec:
  replicas: 3
  secretName: bitpoke-mysql-secret
  mysqlVersion: "8.0"
  podSpec:
    resources:
      limits:
        cpu: "500m"
        memory: "512Mi"
EOF

约 5 分钟，3 个 Pod（每个 4 容器：mysql、sidecar、metrics-exporter、pt-heartbeat）全部就绪。512Mi 内存完全够用（无 MGR 协议开销）。

遇到的问题 ：无明显报错。唯一注意点是 Bitpoke 的 Secret 字段名是 ROOT_PASSWORD（全大写），和其他 Operator 的 rootPassword 不同，文档里有说明。

文档体验：GitHub README 比较简洁，核心字段一目了然。不过部分高级功能（如 Orchestrator 参数调优）没有详细说明，需要看源码。

三、功能实测结果

3.1 拓扑支持

这一项最重要的结论在于 Percona ps-operator 和 Oracle 的拓扑选择是锁死的，不是我们事先预期的。

Percona ps-operator v1.0 只支持 MGR（clusterType=group-replication），传统半同步主从根本没有入口------我们尝试用 clusterType=semisync 创建，CRD webhook 直接拒绝。值得注意的是，Percona 其实有两款 MySQL Operator：ps-operator（对应 Percona Server）和 pxc-operator（对应 Percona XtraDB Cluster），两者功能差异很大，文档里容易混淆，选型前一定要确认自己用的是哪一款。Oracle 同理，InnoDB Cluster 和 MGR 是绑定的，没有其他选择。

Bitpoke 则相反，只有异步/半同步主从 + Orchestrator，MGR 完全不在支持范围内。

KubeBlocks 是四款里唯一能在同一套 CRD 下切换拓扑的------componentDef 填 mysql-8.0 是半同步，填 mysql-mgr-8.0 就是 MGR，API 不变，只改一个字段。

拓扑 KubeBlocks Percona ps-op Oracle 官方 Bitpoke
主从复制（半同步） ✅ ❌（仅 MGR） ❌（仅 InnoDB Cluster） ✅
MySQL Group Replication（MGR） ✅ ✅ ✅ ❌
Orchestrator 高可用 ✅ ❌ ❌ ✅
ProxySQL 读写分离 ✅ ❌（使用 HAProxy） ✅（MySQL Router） ❌
单节点（开发用） ✅ ✅ ✅ ✅

3.2 高可用切换 RTO（实测）

测试方法统一：写入测试数据后 kubectl delete pod <primary> 强制删除主节点，脚本轮询其他节点角色，记录从指令发出到新主可写的时间。每款测了 2 次，取平均值。

Operator 拓扑 实测 RTO
KubeBlocks 半同步 ~4s
Percona ps-operator MGR ~4s
Oracle 官方 InnoDB Cluster（MGR） ~7s
Bitpoke 异步主从 + Orchestrator ~13s

KubeBlocks 和 Percona 并列最快，主要得益于共识机制内置，选举和高可用切换不依赖外部组件。Oracle 慢 3 秒是因为 MySQL Router 在 MGR 选出新主后还需要额外时间刷新路由表，从客户端视角看延迟更长。

Bitpoke 的 13 秒则是 Orchestrator 架构的固有成本：Orchestrator 需要等心跳超时才能确认主节点宕机，这个窗口默认是几秒到十几秒。Bitpoke 文档里对这个延迟没有特别说明，实际生产中要根据业务对 RPO/RTO 的要求仔细评估。

3.3 弹性扩缩容

KubeBlocks 用 OpsRequest 声明式触发，apply 后可以 watch OpsRequest 的 status 跟进进度：

yaml 复制代码 
apiVersion: operations.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: mysql-scale-out
  namespace: kb-mysql-test
spec:
  clusterName: kb-mysql
  type: HorizontalScaling
  horizontalScaling:
    - componentName: mysql
      scaleOut:
        replicaChanges: 1
bash 复制代码 
$ kubectl apply -f scale-out.yaml
$ kubectl get opsrequest mysql-scale-out -n kb-mysql-test -w
NAME             TYPE                STATUS     AGE
mysql-scale-out  HorizontalScaling   Running    8s
mysql-scale-out  HorizontalScaling   Succeed    42s

$ kubectl get pods -n kb-mysql-test
kb-mysql-mysql-0   3/3   Running   0   85m
kb-mysql-mysql-1   3/3   Running   0   3m
kb-mysql-mysql-2   3/3   Running   0   80m
kb-mysql-mysql-3   3/3   Running   0   38s   # 新副本

Oracle 直接 patch spec.instances，operator 自动处理 MGR 成员加入：

bash 复制代码 
$ kubectl patch innodbcluster oracle-mysql -n oracle-test \
    --type=merge -p '{"spec":{"instances":4}}'

$ kubectl get innodbcluster oracle-mysql -n oracle-test
NAME           STATUS   ONLINE   INSTANCES
oracle-mysql   ONLINE   4        4          # 约 3 分钟后 4 节点全部 ONLINE

Bitpoke 同样 patch CRD 即可，无需额外操作。

Percona 实测有问题：patch mysql.size=4 后命令无响应（no change），MGR 状态始终维持在 3 节点。可能与 MGR 成员管理机制有关，operator 在某些状态下会拒绝变更，但没有明确的错误提示，排查体验较差。

能力 KubeBlocks Percona ps-op Oracle 官方 Bitpoke
水平扩容 API OpsRequest PerconaServerMySQL patch InnoDBCluster patch MysqlCluster patch
实测扩容（3→4） ✅ 成功 ⚠️ 未生效（MGR 约束） ✅ 成功 ✅ 成功（3→4）
垂直扩容 ✅ OpsRequest ✅ patch resources ❌ 无原生支持 ✅ patch resources

3.4 动态参数调整

我们用修改 max_connections 作为标准测试用例。OpsRequest 在 12 秒内返回 Succeed，配置写入了 /etc/mysql/conf.d/my.cnf。

yaml 复制代码 
apiVersion: operations.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: kb-mysql-reconfig
  namespace: kb-mysql-test
spec:
  clusterName: kb-mysql
  type: Reconfiguring
  reconfigures:
    - componentName: mysql
      parameters:
        - key: max_connections
          value: "600"
bash 复制代码 
$ kubectl get opsrequest kb-mysql-reconfig -n kb-mysql-test
NAME              TYPE            STATUS    AGE
kb-mysql-reconfig Reconfiguring   Succeed   12s

Bitpoke 通过 spec.mysqlConf 写入。

bash 复制代码 
$ kubectl patch mysqlcluster bitpoke-mysql -n bitpoke-test \
    --type=merge -p '{"spec":{"mysqlConf":{"max_connections":"600"}}}'

# 等待滚动重启完成后验证
$ mysql -e "SHOW VARIABLES LIKE 'max_connections';"
max_connections  600   # ✅ 生效

Percona 将 my.cnf 片段写入 spec.mysql.configuration，需要 Pod 滚动重启才生效。Oracle 支持在 spec.mycnf 写入配置，同样需要重启，且无进度跟踪。

Operator 支持方式 实测结果
KubeBlocks Reconfiguring OpsRequest ✅ OpsRequest Succeed，配置写入文件
Percona ps-op spec.mysql.configuration（my.cnf 片段） ⚠️ 配置写入 spec，需滚动重启生效
Oracle 官方 InnoDBCluster spec.mycnf ⚠️ 支持，但无动态生效机制
Bitpoke MysqlCluster spec.mysqlConf ✅ spec 写入成功，重启后生效（实测 max_connections: 600 生效）

3.5 TLS 支持

四款 Operator 均内置 TLS，进 MySQL 验证：

bash 复制代码 
# 以 KubeBlocks 为例
$ kubectl exec -n kb-mysql-test kb-mysql-mysql-0 -c mysql -- \
    mysql -uroot -p"$PW" -e "SHOW VARIABLES LIKE 'have_ssl';"
Variable_name  Value
have_ssl       YES

# Percona 的证书挂载路径
$ mysql -e "SHOW VARIABLES LIKE 'ssl_ca';"
Variable_name  Value
ssl_ca         /etc/mysql/mysql-tls-secret/ca.crt

Oracle 在 InnoDBCluster spec 里指定 tlsUseSelfSigned: true，自动颁发自签名证书，无需手动管理 Secret。四款均通过 TLS 验证。

Operator TLS 状态
KubeBlocks ✅ have_ssl=YES，ssl_ca 自动挂载
Percona ps-op ✅ ssl_ca=/etc/mysql/mysql-tls-secret/ca.crt
Oracle 官方 ✅ tlsUseSelfSigned: true（spec 级别配置）
Bitpoke ✅ have_ssl=YES

3.6 备份与 PITR

备份能力通过查文档 + 验证 CRD 和容器配置完成（未逐一触发完整备份流程）。

Oracle 官方 Operator 是这里最明显的短板：不支持 XtraBackup，也没有 Binlog 流式归档，PITR 完全缺失。如果发生误删数据，只能恢复到最近一次全量备份时间点，RPO 取决于备份频率。其余三款均支持 XtraBackup 物理备份 + Binlog 归档 + 对象存储，PITR 能力完整。

能力 KubeBlocks Percona ps-op Oracle 官方 Bitpoke
物理备份（XtraBackup） ✅ ✅ ❌ ✅
逻辑备份（mysqldump） ✅ ✅ ✅ ❌
PITR（Binlog 流式归档） ✅ WAL-G ✅ ❌ ✅
备份到对象存储（S3/OSS） ✅ ✅ ❌ ✅
定时备份 ✅ ✅ ✅ ✅

3.7 Prometheus 监控

查各 Pod 的容器列表是最直接的方式：

bash 复制代码 
# KubeBlocks：mysql-exporter 自动注入
$ kubectl get pod kb-mysql-mysql-0 -n kb-mysql-test \
    -o jsonpath='{.spec.containers[*].name}'
mysql  mysql-exporter  kbagent

# Bitpoke：metrics-exporter 内置
$ kubectl get pod bitpoke-mysql-mysql-0 -n bitpoke-test \
    -o jsonpath='{.spec.containers[*].name}'
mysql  sidecar  metrics-exporter  pt-heartbeat

# Oracle：无 exporter sidecar
$ kubectl get pod oracle-mysql-0 -n oracle-test \
    -o jsonpath='{.spec.containers[*].name}'
mysql  sidecar    # 没有 metrics 容器
Operator Metrics 方案
KubeBlocks ✅ mysql-exporter sidecar 自动注入
Percona ps-op ✅ PMM（Percona Monitoring and Management）集成
Oracle 官方 ❌ 无内置 exporter，需手动配置
Bitpoke ✅ metrics-exporter sidecar 自动注入

Oracle 需要用户自行在 Pod 旁边部署 mysqld_exporter 并配置 ServiceMonitor，对于习惯开箱即用 Prometheus 集成的团队来说是额外工作。

3.8 Day-2 运维接口统一性

测完所有功能，感受最深的是各 Operator 操作界面的碎片化程度。

Percona 扩容改 spec.mysql.size，改参数改 spec.mysql.configuration，这两个动作 API 路径不一样，没有统一的状态跟踪。Oracle 的扩容和参数变更同样分散在不同字段。Bitpoke 情况类似。每个 Operator 都有自己的一套"方言"。

KubeBlocks 的 OpsRequest 是唯一一个把所有 Day-2 操作统一抽象的设计：

bash 复制代码 
# 水平扩容
kubectl apply -f ops-hscale.yaml    # type: HorizontalScaling

# 参数变更
kubectl apply -f ops-reconfig.yaml  # type: Reconfiguring

# 垂直扩容
kubectl apply -f ops-vscale.yaml    # type: VerticalScaling

# 统一查进度
kubectl get opsrequest -n kb-mysql-test
NAME              TYPE               STATUS    AGE
mysql-scale-out   HorizontalScaling  Succeed   5m
kb-mysql-reconfig Reconfiguring      Succeed   2m

所有操作都有明确的 STATUS 字段（Pending / Running / Succeed / Failed），可以在 CI/CD 流水线里直接 watch，不需要自己写轮询逻辑。而且同一套 OpsRequest 接口对所有数据库引擎都成立------MySQL 怎么扩容，PostgreSQL、Redis 就怎么扩容，API 格式完全一致。

四、综合对比

功能 KubeBlocks Percona ps-op Oracle 官方 Bitpoke
开源协议 AGPL 3.0 Apache 2.0 GPL 2.0 Apache 2.0
半同步主从 ✅ ❌ ❌ ✅
MGR ✅ ✅ ✅ ❌
Orchestrator HA ✅ ❌ ❌ ✅
ProxySQL 读写分离 ✅ ❌ ✅（Router） ❌
实测 HA RTO ~4s ~4s ~7s ~13s
PITR ✅ ✅ ❌ ✅
水平扩容 ✅ ⚠️ MGR 约束 ✅ ✅
动态参数 ✅ ⚠️ 需重启 ⚠️ 需重启 ⚠️ 需重启
TLS ✅ ✅ ✅ ✅
Prometheus ✅ ✅（PMM） ❌ ✅
多数据库统一 API ✅ ❌ ❌ ❌
社区活跃度 活跃 活跃 官方维护 2024 年后放缓

五、选型建议

选 Percona ps-operator，如果：

  • 仅部署 MySQL，且确定使用 MGR 拓扑
  • 团队深度依赖 Percona 技术栈（XtraBackup、PMM）
  • 需要与 Percona 官方商业支持绑定

选 Oracle 官方 Operator，如果：

  • 场景相对简单，只需 InnoDB Cluster（MGR）
  • 希望使用 Oracle 官方支持的技术栈
  • 不依赖 XtraBackup / PITR / Prometheus 等能力

选 Bitpoke，如果：

  • 已有 Orchestrator 运维经验
  • 不需要 MGR，只需传统异步主从
  • 注意：2024 年后社区更新明显放缓

选 KubeBlocks，如果：

  • 集群同时运行 MySQL、PostgreSQL、Redis 等多种数据库，希望统一运维接口
  • 需要灵活切换拓扑（半同步、MGR、Orchestrator）
  • 希望通过 OpsRequest 标准化 CI/CD 流水线中的数据库变更
  • 团队规模不大，希望降低多数据库的学习和维护成本

六、总结与推荐

测完四款 Operator，我们的整体结论是：如果你只能选一款，选 KubeBlocks。

理由很直接：

1. 拓扑最全。 半同步主从、MGR、Orchestrator 三种拓扑通过同一套 Cluster CRD 覆盖，其他三款都各有缺失------Percona ps-operator 只有 MGR，Oracle 只有 InnoDB Cluster，Bitpoke 没有 MGR。

2. HA 切换最快。 实测 RTO ~4s，与 Percona 并列最短，比 Oracle（7s）和 Bitpoke（13s）都快。

3. Day-2 运维体验最好。 扩缩容、参数变更、备份恢复全部通过 OpsRequest 这一个 CRD 完成，接口统一、可审计、天然适合 GitOps。其他 Operator 要么靠 patch CRD 字段，要么靠 annotation，没有统一的操作层。

4. 备份能力最完整。 XtraBackup 物理备份 + WAL-G binlog 流式归档 + S3/OSS 对象存储，PITR 开箱即用。Oracle 官方 Operator 完全不支持 XtraBackup 和 PITR，这一项直接出局。

5. 多数据库统一管理。 这是 KubeBlocks 相对其他三款最本质的差异。如果你的集群同时跑 MySQL、PostgreSQL、Redis，学会 KubeBlocks 操作 MySQL，其他数据库的运维接口完全一致，不需要再学三套 CRD。

当然，每款 Operator 都有其适用场景：

  • 只跑 MySQL，且确定用 MGR：Percona ps-operator 是成熟选择，但要做好 2Gi+ 内存规划和部署踩坑的准备
  • 追求零部署门槛：Bitpoke 最容易上手，适合规模小、需求简单的团队，但社区活跃度已明显下降
  • Oracle 官方 Operator：除非有特殊的合规或支持要求，否则备份能力的短板让它很难在生产环境中推荐

对于大多数在 Kubernetes 上认真运维数据库的团队，KubeBlocks 是目前综合能力最强、运维成本最低的选择。

详细文档和快速开始指南：kubeblocks.io/mysql-opera...

开源仓库：github.com/apecloud/ku...

相关推荐
倔强的石头_4 小时前
从 “存得下” 到 “算得快”：工业物联网需要新一代时序数据平台
数据库
TDengine （老段）5 小时前
TDengine IDMP 可视化 —— 分享
大数据·数据库·人工智能·时序数据库·tdengine·涛思数据·时序数据
GottdesKrieges5 小时前
OceanBase数据库备份配置
数据库·oceanbase
SPC的存折6 小时前
MySQL 8组复制完全指南
linux·运维·服务器·数据库·mysql
运维行者_6 小时前
OpManager MSP NetFlow Analyzer集成解决方案，应对多客户端网络流量监控挑战
大数据·运维·服务器·网络·数据库·自动化·运维开发
炸炸鱼.7 小时前
Python 操作 MySQL 数据库
android·数据库·python·adb
softshow10267 小时前
Etsy 把 1000 个 MySQL 分片迁进 Vitess
数据库·mysql
Ronaldinho Gaúch8 小时前
MySQL基础
数据库·mysql
不剪发的Tony老师8 小时前
Noir：一款键盘驱动的现代化数据库管理工具
数据库·sql
热门推荐
01GitHub 镜像站点022026年4月技术前沿：AI大模型爆发、智能体革命与量子安全新纪元03一周AI热点速览（2026.03.31-04.06）：GPT-6曝光、谷歌开源Gemma 4、资本狂飙与模型军备竞赛04基于 Docker 部署 Hermes Agent 并接入飞书机器人的完整指南05免费！不限量！用opencode接入英伟达（NVIDIA）大模型，轻松打造你的 AI 编程助手06Oh My Codex 快速使用指南07从限购到畅通：GLM-5.1 Coding Plan接入攻略08CodeBuddy与WorkBuddy深度对比：腾讯两款AI工具差异及实操指南09LLM Wiki：让大模型替你打理知识库的完整指南10AI Weekly | 2026年4月第二周 · GitHub热门项目与AI发展趋势深度解析