GVKun编程网logo

轻松集成系列四：如何在 KubeBlocks 中更新参数｜以 Oracle MySQL 为例（kubectl 更新deployment）

1

本文将分享轻松集成系列四：如何在KubeBlocks中更新参数｜以OracleMySQL为例的详细内容，并且还将对kubectl更新deployment进行详尽解释，此外，我们还将为大家带来关于Kub

本文将分享轻松集成系列四：如何在 KubeBlocks 中更新参数｜以 Oracle MySQL 为例的详细内容，并且还将对kubectl 更新deployment进行详尽解释，此外，我们还将为大家带来关于KubeBlocks 0.6.0 发布！KubeBlocks支持Kafka、Pulsar、多款向量数据库、MySQL读写分离啦！、KubeBlocks v0.7.0 发布！支持引用外部组件，解耦备份 API，还支持了 Pika！、KubeBlocks v0.8.0 发布！Component API 让数据库引擎组装更简单！、KubeBlocks v0.9 解读｜最高可管理 10K 实例的 InstanceSet 是什么？的相关知识，希望对你有所帮助。

本文目录一览：

轻松集成系列四：如何在 KubeBlocks 中更新参数｜以 Oracle MySQL 为例（kubectl 更新deployment）

轻松集成系列四：如何在 KubeBlocks 中更新参数｜以 Oracle MySQL 为例（kubectl 更新deployment）

本文以 Oracle MySQL 为例，介绍如何在 KubeBlocks 中配置参数模板并更新参数（点击参考完整 PR）。

前提条件

  1. 了解 K8s 基本概念，例如 Pod，ConfigMap 等。
  2. 完成 Tutorial 3。
  3. 了解 Go Template (非必须)。
  4. 了解 CUE Lang (非必须)。

背景知识

KubeBlocks 通过“ConfgMap 挂载到卷”的方式来添加配置，而且秉持 Kubernetes
-Native 的理念，即：ConfigMap is the only source-of-truth，将参数变更的入口收敛到 ConfigMap，防止出现配置漂移（drifting）。所以 KubeBlocks 的参数变更遵从以下顺序：

  1. 先修改 ConfigMap 中的参数值；
  2. 根据 ConfigMap 的变更推导出参数变化（add/delete/update）；
  3. 将变更应用到引擎。

不同参数的更新方式不同，主要有以下两类：

  • 静态参数，需要重启集群生效（冷更新）；
  • 动态参数，需要动态刷参生效（热更新）。

Table 1. 枚举了 4 种常见的动态刷参方式，包括 UNIX Signal、SQL、Auto 等。目前我们对接的引擎都可以用其中一种或者多种方式来实现。例如，在Postgres中，要实现动态刷参，可以：

  • UNIX Signal：下发 SIGHUP 信号；
  • Tools：调用 pg_ctl 命令；
  • SQL：执行 SQL 语句，直接更新内存参数。

Table 1. 参数热更新方式总结

变更方式描述试用范围
unix signal例如 PostgresSQL，参数变更后，如果需要重新加载配置文件，可以给 PG 发送 SIGHUP 信号。适用于支持 UNIX Signal 变更的引擎。
SQL例如 MySQL，需要通过 SQL 语句发下变更内容 SET GLOBAL <var> =<value>。适用于大部分 RDBMS 引擎。注：需要适配 execSQL 接口。目前 KubeBlocks 只支持 MySQL 和 Postgres。
Tools例如 Redis 或者 Mongo，都提供了相关的 tools 工具来更新参数。通过自定义脚本或者本地工具实现，通用性高。
Auto引擎本身会 watch 配置文件的变化，检查到配置文件变更后，会主动更新。依赖引擎是否支持自动加载。

K8s 中通过卷挂载方式使用 ConfigMap 时，该 ConfigMap 的变更会被更新到 Pod。但这个变更不是实时的。因此，KuBeBlocks 不仅需要区分参数的更新方式，还要 watch 对应的变更是否已经同步到 Pod 上。

了解这些背景后，我们来看看 KubeBlocks 是怎么通过 ConfigConstraint API 管理参数变更的。

ConfigConstraint 参数约束

作为一个支持多引擎的平台，为了更好地支持配置变更，KubeBlocks 需要了解如下信息：

  1. 配置文件是什么格式

不同格式的配置文件，其结构不同。KubeBlocks 会根据结构解析配置文件，推导出每次变更的信息(增加/删除/更新的参数)。

  1. 哪些是动态参数，哪些是静态参数，哪些是不可变参数

指定参数的作用方式（effect scope），用于决策参数如何快速生效。

  1. 参数动态变更的方式是什么

如 Table 1 所示，参数动态变更的方式很多。不同引擎需要指定其动态变更方式。

  1. 定义参数校验规则

用于校验参数的有效值，防止误操作。

生产环境中，经常会有“手误”写错了参数值，导致数据库无法启动的情况。参数校验增加了一层保护，提前做校验，防止此类误操作。

KubeBlocks 会为配置了 ConfigConstraint 的 Component 创建一个 config-manager sidecar，用于感知配置文件的更新、下发 Signal、执行参数更新脚本等。

这些信息被抽象到 KubeBlocks 的 ConfigConstraint（参数约束）中，见 Figure 1. ConfigConstraint for Oracle-MySQL。一共有 4 个部分，对应前文提到的 4 个关键配置信息。

apiVersion: apps.kubeblocks.io/v1alpha1
kind: ConfigConstraint
metadata:
  name: oracle-mysql-config-constraints
spec:
  #1. 指定配置文件格式为 INI，且只关注其中 `mysqld` 小节(section)的内容
  formatterConfig:
    format: ini
    iniConfig:
      sectionName: mysqld

  #2. mysql 的动态刷参方式，通过 reload-script 执行 SQL 语句
  reloadOptions:
    tplScriptTrigger:
      sync: true
      # 指定用哪个脚本文件更新
      scriptConfigMapRef: oracle-mysql-reload-script
      namespace: {{ .Release.Namespace }}

  ##3.1 配置静态参数列表
  staticParameters:
    - open_files_limit
    - performance_schema
    - enforce_gtid_consistency

  ##3.2 配置动态参数列表
  dynamicParameters:
    - innodb_buffer_pool_size
    - max_connections
    - gtid_mode

  ##4. 通过 CUE 模板，定义参数校验规则 
  cfgSchemaTopLevelName: MysqlParameter
  configurationSchema:
    cue: |-
      {{- .Files.Get "config/oracle-mysql-config-constraint.cue" | nindent 6 }}

Figure 1. ConfigConstraint for Oracle-MySQL

下面我们来逐个说明每个 API 的使用。

2.1 FormatterConfig

FormatterConfig 描述了配置文件的格式，常见的格式有 ini、yaml、json、xml、properties 等。配置文件本身只是一个文本信息，不同格式的文件都需要不同的解析器。

当 KubeBlocks 感知到配置文件变更时，会根据已知的格式推导出参数的变更(增/删/改)，并通知 Pod 去更新。

例如，MySQL 的可调整的参数来自 ini 格式的，且只解析其中的 mysqld 字段信息。

  formatterConfig:
    format: ini               # 配置文件格式，目前支持 ini、xml、yaml、json、hcl 等格式
    iniConfig:
      sectionName: mysqld     # 如果是 ini 格式，可能包含多个 section，需要指定 section 名称

Figure 2. FormatterConfig

2.2 ReloadOptions

ReloadOptions 描述了动态刷参的方式。

在 Table 1. 中我们总结了常见的 4 种动态刷参方式。相应的，KubeBlocks 也支持多种刷参方式的配置：

  • tplScriptTrigger：通过模板文件刷参数；
  • shellTrigger：通过执行脚本刷参；
  • unixSignalTrigger：通过 UNIX Signal 刷参；

  • 不配置：即 AutoLoad 模式，交由数据库引擎自动更新。

    reloadOptions:
  tplScriptTrigger:                                 # 通过模板文件刷参
    sync: true                                      # 同步更新
    scriptConfigMapRef: oracle-mysql-reload-script  # 引用的模板文件
    namespace: {{ .Release.Namespace }}

    Figure 3. ReloadOptions using tplScript

Figure 3. 选择了第一种方式，通过定义在模板文件中进行内容更新。

  reloadOptions:
    shellTrigger:
      sync: true
      command:
        - "update-dynamic-config.sh"

Figure 4. ReloadOptions using shell script

Figure 4. 提供了一个更通用的方案，通过 shell 脚本动态刷参。大部分数据库都支持通过客户端更新参数。

这些 ReloadOptions 中的脚本，会被加载到 Pod 上，通过前文提到的 config-manager sidecar 执行。

2.3 Static/Dynamic Parameters

KubeBlocks 支持配置动态参数（dynamic）、静态参数（static）和不可变参数（immutable）的配置。这种区分是为了识别变更的参数类型，来决策参数的生效方式。

KubeBlocks 内置了多种刷参策略，会根据变更内容智能选择最合适的变更策略。

  ##3.1 配置静态参数列表
  staticParameters:
    - open_files_limit
    - performance_schema
    - enforce_gtid_consistency

  ##3.2 配置动态参数列表
  dynamicParameters:
    - innodb_buffer_pool_size
    - max_connections
    - gtid_mode

Figure 5. Static and Dynamic Parameters

Figure 5. 中枚举了几个常见的 MySQL 参数。比如 performance_schema 为静态参数，max_connection 为动态参数。如果参数列表过长，推荐使用 .Files.Get 函数处理。

2.4 ConfigurationSchema

在变更时，有时会因为写入了无效参数值，导致集群启动失败。KubeBlocks 提供了 ConfigurationSchema 用于参数值有效性校验。

KubeBlocks 使用 CUE 语言来做校验。通过描述每个参数的类型、默认值、取值范围等，我们可以防止因为参数值错误导致的问题。

#MysqlParameter: {

    // Sets the autocommit mode
    autocommit?: string & "0" | "1" | "OFF" | "ON"

    open_files_limit: int | *5000

    // Enables or disables the Performance Schema
    performance_schema: string & "0" | "1" | "OFF" | "ON" | *"0"
    
    // The number of simultaneous client connections allowed.
    max_connections?: int & >=1 & <=100000    
    ...
 }

Figure 6. Parameters Constraints

Figure 6. 提供了一个简短的 MySQL 参数值校验配置。
例如：

    // Enables or disables the Performance Schema
    performance_schema: string & "0" | "1" | "OFF" | "ON" | *"0"

它定义了 mysql 中参数 performance_schema 的几个约束：

  • 参数值类型为 string；
  • 参数取值可以为 ON，OFF，或者 0，1；
  • 参数默认值为 0。

3. 如何更新参数

为了提供更好的使用体验，KubeBlocks 通过命令行 kbcli 提供了更便捷的参数管理方式。

3.1 创建集群

helm install oracle-mysql path-to-your-helm-chart/oracle-mysql
kbcli cluster create mycluster --cluster-definition=''oracle-mysql'' --cluster-version oracle-mysql-8.0.32

3.2 查看参数配置

 kbcli cluster describe-config mycluster

ConfigSpecs Meta:
CONFIG-SPEC-NAME   FILE     ENABLED   TEMPLATE                       CONSTRAINT                        RENDERED                            COMPONENT    CLUSTER
mysql-config       my.cnf   true      oracle-mysql-config-template   oracle-mysql-config-constraints   mycluster-mysql-comp-mysql-config   mysql-comp   mycluster

History modifications:
OPS-NAME   CLUSTER   COMPONENT   CONFIG-SPEC-NAME   FILE   STATUS   POLICY   PROGRESS   CREATED-TIME   VALID-UPDATED

可以看到详细的配置信息，包括可用配置模板名和配置约束名等。

3.3 更新参数

例如，如果要修改 mysql 的 max_connection 参数，根据前文配置，我们知道：

  • 它是动态参数，见 Figure 5. line 10；
  • 它的取值范围是 [1, 10000]，见Figure 6. line 12。

kbcli 0.6.0 之后的版本，支持了 interactive 参数修改方式。我们可通过 kbcli 的 edit-config 命令直接修改参数。

kbcli cluster edit-config mycluster

然后会看到一个交互的编辑界面，我们直接将 max_connection 修改为 1000。

Figure 7. Interactive Config Editor

保存变更后再次确认变更信息（如 Figure 8 所示）即可实现参数的更新。

Figure 8. Confirm Config Changes

3.5 查看变更历史

再次查看参数配置。可以看到，除了参数模板之外，还记录了参数的历史修改信息和变更的具体内容。

kbcli cluster describe-config mycluster                                                                  57s

ConfigSpecs Meta:
CONFIG-SPEC-NAME   FILE     ENABLED   TEMPLATE                       CONSTRAINT                        RENDERED                            COMPONENT    CLUSTER
mysql-config       my.cnf   true      oracle-mysql-config-template   oracle-mysql-config-constraints   mycluster-mysql-comp-mysql-config   mysql-comp   mycluster

History modifications:
OPS-NAME                        CLUSTER     COMPONENT    CONFIG-SPEC-NAME   FILE     STATUS    POLICY   PROGRESS   CREATED-TIME                 VALID-UPDATED
mycluster-reconfiguring-7p442   mycluster   mysql-comp   mysql-config       my.cnf   Succeed            1/1        Aug 25,2023 18:27 UTC+0800   {"my.cnf":"{\"mysqld\":{\"max_connections\":\"1000\"}}"}

Appendix

A.1 如何查看变更流程

参数变更是一种 KubeBlocks 的 operations，简称 ops。

我们通过 kbcli 下发变更后，可以看到 KubeBlocks 中产生了一个 Reconfigration 类型的 ops。

如 Section 3.5 中所示，我们可以看到有一个名为 mycluster-reconfiguring-7p442 的 ops。

可以通过下面的命令查看参数变更的详细信息，包括变更内容、变更策略、变更时间等。

kbcli cluster describe-op <your-reconfig-ops-name>

A.2 比较变更的差异

也可以通过 diff-config 比较两次配置的差异。

kbcli cluster diff-config <your-reconfig-ops1> <your-reconfig-ops2>

参考资料

  1. Kubernetes 挂载的 ConfigMap 自动更新: https://kubernetes.io/zh-cn/docs/tasks/configure-pod-containe...
  2. CUE Lang 介绍: https://cuetorials.com/zh/overview/

  3. KubeBlocks ApeCloud MySQL Configuration: https://kubeblocks.io/docs/preview/user_docs/kubeblocks-for-m...

KubeBlocks 0.6.0 发布！KubeBlocks支持Kafka、Pulsar、多款向量数据库、MySQL读写分离啦！

KubeBlocks 0.6.0 发布！KubeBlocks支持Kafka、Pulsar、多款向量数据库、MySQL读写分离啦！

KubeBlocks v0.6.0 版本正式发布了！

此版本引入了流计算引擎 Kafka、Pulsar 和向量数据库 Qdrant、Weaviate、Milvus，支持了 MySQL 读写分离，提升了交互式的参数管理体验。

Highlights

  • KubeBlocks 支持了 Kafka v3.3

    Kafka 是一款开源的分布式事件存储和流计算系统，为数据管道、流式分析、数据集成提供了极高的可靠性、吞吐量和极低的延迟，被广泛应用于日志收集和指标监控场景。KubeBlocks 支持了 Kafka v3.3，该版本宣布 KRaft 已经满足生产环境要求，能够提供更好的分区可拓展性和弹性，节省了 ZooKeeper 带来的额外成本。除此之外，KubeBlocks 还支持将 MySQL 和 PostgreSQL 的数据变更推送至 Kafka，方便用户进一步加工处理。

  • KubeBlocks 支持了 Pulsar v2.11

    Apache Pulsar 是一个开源的分布式消息传递和流处理平台。它旨在提供可扩展性、高性能和可靠性，以满足现代数据处理和实时消息传递的需求。KubeBlocks 支持了 Apache Pulsar v2.11，相对于传统部署方式，KubeBlocks 可自动化完成故障转移、扩缩容等 day2 运维操作。

  • KubeBlocks 支持了 MySQL 读写分离

    读写分离旨在提高 MySQL 数据库集群的只读处理能力，将所有写入查询都将发送到主节点上，不修改数据的只读查询分散到多个从节点上。读写分离与 MySQL Raft Group 集群一起使用，它会自动检测主节点的变化，并使用集群当前的主节点来实现故障转移。通过设置 read_write_splitting_policy ，在 global 或 session 级别打开读写分离特性，默认策略为 LEAST_CURRENT_OPERATIONS，将只读查询路由到读查询活跃操作最少的从节点。MySQL Raft Group 集群最大支持 5 个节点。

  • KubeBlocks支持了流行的向量数据库管理

    生成式 AI 的火爆彻底点燃了向量数据库（Vector Database）市场，KubeBlocks 支持对向量数据库的一键拉起和管理控制。目前支持 Qdrant（v1.1.0），Weaviate（v1.18.0），以及 Milvus 的管理。

新功能

Pulsar

  • 集群生命周期管理和运维管理，支持创建 Pulsar 集群，删除集群、重启集群、横向扩容、纵向扩容、存储扩容、参数变更
  • 监控，支持 ZooKeeper、 BookKeeper、Broker 的 CPU、内存、网络读写流量等性能监控

Kafka

  • 集群生命周期管理和运维管理，支持集群创建、删除、横向扩容、纵向扩容、存储扩容、参数变更

    • 横向扩容：combined 模式下 broker replica 支持 1,3,5 个副本；seperated 模式下, broker 支持 1 到 100，controller 支持 1,3,5
  • 监控，支持 Broker 的 CPU、内存、网络读写流量等性能监控

MySQL

  • 三节点集群支持 Switchover
  • 数据恢复，非覆盖性的按时间点恢复
  • 三节点集群支持 MySQL 读写分离

  • 创建集群开启代理（Beta）

    • Vitess 代理默认规格可以满足用户绝大部分应用场景，Vitess 代理根据数据库节点以及节点规格的变化自动触发增加或减少资源，无需用户选择。Vitess 代理的 CPU 为集群中节点 CPU 总核数（三个节点）的 1/6 并向上取整，以 0.5c 为粒度，最小 0.5c，最大 64c。副本数量默认为 1，当前不支持修改副本数量
    • 连接地址：代理有一个默认连接地址，支持读写分离。expose 命令支持为代理连接地址生成 VPC 地址和公网地址
    • 支持设置 Vitess 代理读写分离策略

PostgreSQL

  • 主备集群支持 Switchover
  • 支持 pgBouncer

MongoDB

  • MongoDB 副本集支持 Switchover
  • 数据恢复，非覆盖性的按时间点恢复

数据迁移

  • 增加 kbcli migration 命令，包括创建迁移任务、查看迁移任务列表、查看迁移任务详情、终止迁移任务、查看日志、查看迁移模板等功能。支持全量迁移和增量同步
  • 支持 MySQL 数据迁移，从 MySQL8.0 到 MySQL8.0
  • 支持 PostgreSQL 数据迁移，从 PostgreSQL14 到 PostgreSQL14
  • 支持 MongoDB 数据迁移，从 mongo5.x/6.0.x 到 mongo5.x/6.0.x

兼容性

  • 通过 Prometheus v2.41 - 2.45 兼容性测试，支持 Remote write 到 Prometheus server
  • kbcli 适配 Ubuntu 和 Amazon Linux 2 的包管理器
  • kbcli 适配 Windows PowerShell 和包管理器
  • kbcli playground 支持 Ubuntu 和 Amazon Linux 2 本地环境运行
  • kbcli playground 支持 Windows 本地环境运行

易用性

  • kbcli 支持用户通过操作系统本地编辑工具来修改 KubeBlocks 的参数
  • kbcli 支持故障注入 faultinject addon，支持多种故障模拟
  • kbcli 支持 report 命令打包集群上下文信息到压缩文件中用于问题辅助排查
  • kbcli 支持对 DB cluster 的配置信息进行交互式编辑。kbcli cluster create 命令支持使用 --edit 交互式编辑 YAML 文件，展示已创建集群内容
  • 支持取消运行中的 Hscale/Vscale OpsRequest
  • 增加 kbcli playground Grafana 概览页面
  • Kbcli alert 设置邮件服务器
  • 支持初始化创建数据库和用户 相关文档
  • KB 安装时可指定配置文件，
  • MySQL、PostgreSQL、MongoDB 支持磁盘满锁：数据库存储空间即将满时（磁盘使用率超过 90%），将数据库设置为只读状态

备份恢复

  • 备份存储仓库（backupRepo）是指备份文件存放的目标路径，KB 支持公共云对象存储以及S3兼容的对象存储
  • 恢复新集群时支持修改集群配置
  • 查看备份详情 describe-backup

可观测性

  • 支持与 Promtheus, VictorialMetrics, AMP 外部监控系统的数据集成，集群性能监控指标通过 remote write 方式输出到目标监控系统
  • K8s / KB 集群的操作日志实时转储至对象存储，按照时间和大小两个条件进行切分，并提供只读地址
  • K8s / KB 集群的异常日志实时转储至对象存储，按照时间和大小两个条件进行切分，并提供只读地址

有没有你觉得还不错的功能呢？快来尝试下吧。

当然，研发同学很用力，这些变化仍然不是全部，本文只摘取部分功能更新，欢迎大家到 GitHub 查看全部更新内容。

同时，小猿姐也诚邀各位体验 KubeBlocks，欢迎您成为产品的使用者和项目的贡献者。跟我们一起构建云原生数据基础设施吧！

官网：www.kubeblocks.io

GitHub: https://github.com/apecloud/kubeblocks

关注小猿姐，一起学习更多云原生技术干货。

KubeBlocks v0.7.0 发布！支持引用外部组件，解耦备份 API，还支持了 Pika！

KubeBlocks v0.7.0 发布！支持引用外部组件，解耦备份 API，还支持了 Pika！

【直播预告】程序员逆袭 CEO 分几步？

我们很高兴地宣布 KubeBlocks v0.7.0 正式发布！

在此版本中，KubeBlocks 已支持 31 个开源数据库引擎，包括 MariaDB、Elasticsearch、Pulsar 和 Pika 等新的 add-ons，为 K8s 用户提供了更广泛选择的同时，也延续了相同的用户体验。

Highlights

支持引用外部组件

一些数据库集群依赖元数据库进行分布式协调和动态配置。然而，随着数据库集群数量的增加，元数据库本身会消耗大量资源，例如 Pulsar 中的 Zookeeper。为了降低成本，用户现在可使用 KubeBlocks 外部组件引用功能，在多个数据库集群中引用相同的外部组件。

备份 API

数据库集群的部分生命周期管理功能依赖于备份恢复功能，而备份恢复功能又依赖于对象存储。但是，如果缺少对象存储，KubeBlocks 的某些生命周期管理功能可能无法正常工作。例如，创建新副本或将数据恢复到另一个节点可能会受到影响。

为了解决这个问题，我们计划将集群的生命周期管理功能与备份恢复功能解耦。第一步就是解耦 API。通过新的备份 API，抽象备份恢复操作，允许用户自定义备份方法。此外，该 API 现已支持 GCS、OBS 和 COS 对象存储。

支持 Pika v3.5

Pika 是一款由奇虎研发并开源的 NoSQL 数据库，支持 Redis 协议，在处理 100 GB 级别以上的数据量时有较强的成本优势，Pika 保留了与 Redis 相同的操作和使用模式，用户可实现 Redis 到 Pika 的丝滑切换。目前 KubeBlocks 已支持部署 Pika v3.5 的分片集群模式。

已集成的引擎概览

KubeBlocks 已集成 31 个引擎，详细功能支持情况如下。

v0.7.0 Vscale Hscale Volumeexpand Stop/Start Restart Backup/Restore Logs Config Upgrade (内核小版本) Account Failover Switchover Monitor
apecloud-mysql ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ N/A ✔️ ✔️ ✔️ ✔️
postgresql ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️
redis ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ N/A ✔️ ✔️ N/A ✔️
mongodb ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ N/A N/A ✔️ ✔️ ✔️
kafka ✔️ ✔️ ✔️ ✔️ ✔️ N/A N/A ✔️ N/A N/A N/A N/A ✔️
pulsar ✔️ ✔️ ✔️ ✔️ ✔️ N/A N/A ✔️ N/A N/A N/A N/A ✔️
weaviate ✔️ ✔️ ✔️ ✔️ ✔️ N/A N/A ✔️ N/A N/A N/A N/A ✔️
qdrant ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ N/A N/A N/A N/A N/A N/A ✔️
greptimedb ✔️ ✔️ ✔️ ✔️ ✔️ N/A N/A N/A N/A N/A N/A N/A N/A
nebula ✔️ ✔️ ✔️ ✔️ ✔️ N/A N/A N/A N/A N/A N/A N/A N/A
risingwave ✔️ ✔️ ✔️ ✔️ ✔️ N/A N/A N/A N/A N/A N/A N/A N/A
starrocks ✔️ ✔️ ✔️ ✔️ ✔️ N/A N/A N/A N/A N/A N/A N/A N/A
etcd ✔️ ✔️ ✔️ ✔️ ✔️ N/A N/A N/A N/A N/A N/A N/A N/A
oceanbase
✔️ ✔️ N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
foxlake ✔️ ✔️ ✔️ ✔️ ✔️ N/A N/A N/A N/A N/A N/A N/A N/A
orioledb ✔️ ✔️ ✔️ ✔️ ✔️ N/A N/A N/A N/A N/A N/A N/A N/A
oracle-mysql ✔️ N/A ✔️ ✔️ ✔️ ✔️ N/A ✔️ N/A N/A N/A N/A N/A
official-postgresql ✔️ ✔️ ✔️ ✔️ ✔️ N/A N/A N/A N/A N/A N/A N/A N/A
mysql (主备) ✔️ ✔️ ✔️ ✔️ ✔️ N/A N/A N/A N/A N/A N/A N/A ✔️
openldap ✔️ ✔️ ✔️ ✔️ ✔️ N/A N/A N/A N/A N/A N/A N/A N/A
neon ✔️ N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
opensearch ✔️ N/A ✔️ ✔️ ✔️ N/A N/A N/A N/A N/A N/A N/A N/A
vllm N/A N/A N/A ✔️ ✔️ N/A N/A N/A N/A N/A N/A N/A N/A
ggml
N/A N/A ✔️ ✔️ N/A N/A N/A N/A N/A N/A N/A N/A
milvus ✔️ N/A ✔️ ✔️ ✔️ N/A N/A N/A N/A N/A N/A N/A N/A
elasticsearch ✔️ ✔️ ✔️ ✔️ ✔️ N/A N/A N/A N/A N/A N/A N/A N/A
tdengine ✔️ ✔️ ✔️ ✔️ ✔️ N/A N/A N/A N/A N/A N/A N/A N/A
clickhouse ✔️ ✔️ ✔️ ✔️ ✔️ N/A N/A N/A N/A N/A N/A N/A N/A
polardb-x ✔️ ✔️ N/A ✔️ N/A N/A N/A N/A N/A N/A N/A N/A ✔️
zookeeper ✔️ ✔️ ✔️ ✔️ ✔️ N/A ✔️ ✔️ N/A N/A N/A N/A N/A
mariadb ✔️ N/A ✔️ ✔️ ✔️ N/A N/A N/A N/A N/A N/A N/A N/A
END

小猿姐诚邀各位体验 KubeBlocks，也欢迎您成为产品的使用者和项目的贡献者。 跟我们一起构建云原生数据基础设施吧！ 官网: www.kubeblocks.io GitHub: https://github.com/apecloud/kubeblocks Get started: https://kubeblocks.io/docs/release-0.6/user_docs/try-out-on-playground/try-kubeblocks-on-your-laptop 关注小猿姐，一起学习更多云原生技术干货。

戳「阅读原文」 Star KubeBlocks

KubeBlocks v0.8.0 发布！Component API 让数据库引擎组装更简单！

KubeBlocks v0.8.0 发布！Component API 让数据库引擎组装更简单！

【直播预告】程序员逆袭 CEO 分几步？

KubeBlocks v0.8.0 版本发布了！

KubeBlocks v0.8.0 推出了 Component API，让数据库引擎的组装变得更加简单。举个例子，我们可以将 etcd 和 zookeeper 这两种数据库做成了标准组件，开发者在定义 Kafka 或者 Pulsar 等复杂引擎时可以直接引用；再举个例子，我们还可以将 Proxy 做成了标准组件，开发者在定义各种发行版的 MySQL 或 PostgreSQL 引擎读写分离拓扑时无需重复劳动（heavy lifting）。Addon 机制也有了重大改进，数据库引擎的 helm chart 从 KubeBlocks repo 中拆分出去，从此数据库引擎或者版本的变动已与 KubeBlocks 发版解绑。

Highlights

  • 独立的 Component API

    在集成新数据库引擎的过程中，我们发现了 KubeBlocks 抽象设计上的不足。v0.8.0 将 Component 从 Cluster 定义中拆分出来，更好地支持含有多个组件的数据库类型。支持了 Component 之间的变量引用，包括 ConfigMap, Secret, Service, ServiceReference 等几种变量引用类型，可以更好的串联组件间的关系，为构建不同拓扑形态的集群奠定基础。

  • Addon helm chart 移出 KubeBlocks repo

    在 v0.8.0 之前，数据库引擎的 Helm Chart 都是放在 deploy 目录下，与 KubeBlocks Operator 耦合在一起。这样存在两个问题，一是 KubeBlocks 升级时会同步升级数据库引擎，二是数据库引擎升级时会覆盖已有的 CD/CV，导致 Cluster 全部重启。为了解决这两个问题，在 0.8 中我们将数据库引擎拆分到了 kubeblocks-addon 这个独立的代码仓库下，同时数据库引擎和所有资源均加上了版本号，安装时不会覆盖原有资源导致 Cluster 重启。 配套提供了 kbcli addon 相关命令，用户可以进行下载、安装、使用、卸载对应版本的 addon，非常方便。

  • 支持多版本的数据库引擎定义

    在 v0.8.0 之前，KubeBlocks 升级可能会触发数据库集群的重启。在 v0.8.0 上，结合新的 Component API 和 Addon helm chart 存储机制，这个问题得到了一定程度的解决。后面我们还会继续优化多版本的设计，最终实现毫无负担地升级。

What''s Changed

新功能

Pika

  • 支持分片集群，允许用户通过调整组件的方式，增加存量集群的分片

Clickhouse

  • 集成监控、scale out、高可用

Oceanbase

  • 新增主备集群模式，支持完整生命周期，并集成了备份恢复、监控和切换

MySQL

  • 社区版 MySQL 5.7 和 8.0 支持了完整的生命周期，并集成了备份恢复、监控和 HA
  • ApeCloud MySQL 新增日志审计功能

PostgreSQL

  • Postgresql 支持 wal-g 全量备份和按时间点恢复

支持 NodePort

  • Redis 支持 nodePort 访问方式

OpsRequest

  • 支持自定义 OpsRequest，可用于创建和删除 Kafka Topic

备份恢复

  • 新增 FTP 和 NFS 作为备份存储

易用性

  • 允许用户一次性提交多个 opsRequest，并做了一定程度的并发控制
  • 安装 KubeBlocks 时支持指定镜像仓库地址，加快镜像拉取速度

可观测性

  • 统一日志和 mertrics 采集的配置管理 Kubeblocks monitor specification

API

  • 新增 ComponentDefinition 接口定义
  • 新增 OpsDefinition API
  • ActionSet 新增 PreDelete Action，可以在删除备份之前执行此动作

kbcli

  • 增强 addon 子命令，支持从 addon 索引仓库检索和安装 addon

不兼容的改动

  • 在 KubeBlocks v0.8 我们对 Oceanbase 做了非常多的改进 (支持创建主备集群，支持主机网络和动态端口，支持备份 / 恢复，监控，日志等能力)，0.7 版本创建的集群和 0.8 版本创建的集群不兼容，如果您正在使用 0.7 版本的 Oceanbase，建议您升级到 0.8 的 KubeBlocks 之后，升级 Oceanbase Addon，再将 0.7 版本的 Oceanbase cluster 迁移至 0.8 版本的 Oceanbase cluster 使用，以体验更丰富的功能。推荐使用 OceanBase 官方数据导入导出工具 (OBLOADER 和 OBDUMPER) 来迁移数据.
  • KubeBlocks v0.8.0 精简了部署 KubeBlocks 时默认安装的数据引擎，删除 greptime，influxdb，neon，oracle-mysql，orioledb，tdengine，mariadb，nebula，risingwave，starrocks，tidb，zookeeper。用户可以通过 kbcli addon 子命令或者 kubectl apply 命令从 addon 索引仓库中按需安装；如果用户从低版本升级至该版本，请按照升级手册操作，避免正在使用的 addon 被删除从而影响正在运行的集群。
  • KubeBlocks 0.8 的 Helm Chart 中不再包含依赖的 CRD，在使用 helm 命令安装或升级 KubeBlocks 时需要先安装对应的 CRD，然后再安装或升级 KubeBlocks，请参照升级手册进行操作。

End

小猿姐诚邀各位体验 KubeBlocks，也欢迎您成为产品的使用者和项目的贡献者。跟我们一起构建云原生数据基础设施吧！

官网: www.kubeblocks.io

GitHub: https://github.com/apecloud/kubeblocks

Get started: https://kubeblocks.io/docs/release-0.7/user_docs/try-out-on-playground/try-kubeblocks-on-your-laptop

关注小猿姐，一起学习更多云原生技术干货。

KubeBlocks v0.9 解读｜最高可管理 10K 实例的 InstanceSet 是什么？

KubeBlocks v0.9 解读｜最高可管理 10K 实例的 InstanceSet 是什么？

实例（Instance）是 KubeBlocks 中的基本单元，它由一个 Pod 和若干其它辅助对象组成。为了容易理解，你可以先把它简化为一个 Pod，下文中将统一使用实例这个名字。

InstanceSet 是一个通用 Workload API，负责管理一组实例。KubeBlocks 中所有的 Workload 最终都通过 InstanceSet 进行管理。

相比于 K8s 原生的 StatefulSet、Deployment 等 Workload API，InstanceSet 加入了更多数据库领域相关特性的考虑和设计，比如角色、高可用等，使得其在支持数据库等有复杂状态的 Workload 上，具备更强的能力。

使用 InstanceSet

InstanceSet 为其管理的每一个实例生成一个固定的名字，并会生成一个 Headless Service，从而使得每一个实例都有一个固定的网络标识。基于该标识，属于同一个 InstanceSet 的实例可以相互发现对方，属于同一个 Kubernetes 集群中的其它系统也可以发现该 InstanceSet 下的每个实例。

InstanceSet 通过 VolumeClaimTemplates 为每个实例生成固定标识的存储卷（Volume），其它实例或系统可以通过实例的固定标识找到实例，进而进一步访问到存储卷里的数据。

在进行更新时，InstanceSet 支持按照确定性顺序对所有实例进行滚动更新（RollingUpdate），并且可配置滚动更新的多种行为。

类似的，在进行水平扩缩容时，InstanceSet 会按照确定性的顺序进行添加或删除实例操作。

在这些基础特性之上，InstanceSet 针对数据库高可用等需求，进一步支持了原地更新、实例模板、指定实例下线、基于角色的服务、基于角色的更新策略等特性。

下面对这些特性做进一步说明。

实例名称如何生成

InstanceSet 通过实例模板渲染实例对象，渲染的实例数量通过 Replicas 字段进行控制。

apiVersion: workloads.kubeblocks.io/v1alpha1
kind: InstanceSet
metadata:
  name: mydb
spec:
  replicas: 3
  template:
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: mydb
        image: registry.kubeblocks.io/mydb:15.1
        ports:
        - containerPort: 5123
          name: db
        volumeMounts:
        - name: data
          mountPath: /var/mydb/
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "my-storage-class"
      resources:
        requests:
          storage: 10Gi

上面这个例子，声明了一个名叫 mydb 的 InstanceSet，它由 3 个实例（replicas=3）构成。每个实例由 template 和 volumeClaimTemplates 组成的实例模板渲染生成。其中 template 用来渲染实例中的 Pod，volumeClaimTemplates 用来渲染实例中的 PVC。

实例名称生成的模式（Pattern）是 $(instanceSet.name)-$(instanceID)。默认情况下，instanceID 为 ordinal，在该示例中，instanceSet.name 为 mydb，ordinal 从 0 开始递增，最终生成的实例名称为：mydb-0，mydb-1，mydb-2。当使用了多实例模板特性时，instanceID 的生成规则将进一步扩展为 $(template.name)-$(ordinal)，详细说明可参考实例模板说明文档。

为了提供固定的网络标识，每个 InstanceSet 会生成一个 Headless Service 对象，该 Service 名字的生成模式（Pattern）为 $(instanceSet.name)-headless。在该示例中，最终生成的 Headless Service 的名字为：mydb-headless。通过这样的方式，该 InstanceSet 下的 3 个实例获得了三个固定的网络标识，即：mydb-0.mydb-headless.default.local，mydb-1.mydb-headless.default.local，mydb-2.mydb-headless.default.local。

因为 InstanceSet 名字会成为固定网络标识的组成部分，所以要求该名字必须符合 DNS Label 规范。

如何获取 InstanceSet 下的实例

InstanceSet 在生成二级资源时，会为它们添加两个 Label：workloads.kubeblocks.io/managed-by=InstanceSet 和 workloads.kubeblocks.io/instance=<instanceSet.name>。可通过这两个 label 获取某个 InstanceSet 下的所有二级资源，包括 Pod 和 PVC。

在上面的示例中，获取相应 Pod 的 Label 为：

workloads.kubeblocks.io/managed-by=InstanceSet

workloads.kubeblocks.io/instance=mydb

如果想自定义获取 InstanceSet 下的 Pod 的 Label，可通过设置 spec.selector 字段实现。例如：

apiVersion: workloads.kubeblocks.io/v1alpha1
kind: InstanceSet
metadata:
  name: mydb
spec:
  selector:
    matchLabels:
      db: mydb

通过 spec.selector 设置的 MatchLabels 将被自动添加到 InstanceSet 所生成的 Pod 上。

实例创建与销毁

默认情况下，InstanceSet 会按照 Ordinal 从小到大的顺序依次生成实例。在创建一个新的实例时，会先等前一个实例中的 Pod 处于 Ready 状态。

实例销毁时，会按照相反的顺序进行。在销毁一个实例前，会先等该实例中的 Pod 处于 Ready 状态，这里主要的考虑是，如果一个 Pod 没有处于 Ready 状态，其所挂载的 PVC 中的数据可能已经存在问题，在确保数据修复前，InstanceSet 不会做进一步动作。

InstanceSet 新建和水平扩容时，会采用上述实例创建逻辑，水平缩容时，会采用上述实例销毁逻辑。

同时 InstanceSet 支持通过 spec.podManagementPolicy 设置实例创建和销毁策略，目前支持 Ordered (即默认策略）和 Parallel 两种策略。Parallel 是指会采取并行的方式进行实例创建或销毁。

指定实例缩容

有些场景下，需要在缩容时销毁特定实例。

比如，某个 Node 因所在物理机故障需要下线，该 Node 上所有的实例（Pod）需要销毁。此时可通过指定实例缩容特性，实现销毁该 Node 上的实例的目的。

以前面名字为 mydb 的 InstanceSet 为例，可通过如下方式，实现缩容 Ordinal 为 1 的实例，并保留 Ordinal 为 0 和 2 的实例：

apiVersion: workloads.kubeblocks.io/v1alpha1
kind: InstanceSet
metadata:
  name: mydb
spec:
  replicas: 2
  offlineInstances: ["mydb-1"]
# ...

详细介绍可参考指定实例缩容特性介绍章节。

实例更新

当对实例模板中的字段进行了更新后，InstanceSet 下的所有实例会进行更新操作。

默认情况下，InstanceSet 会按照 Ordinal 从大到小的顺序依次更新每个实例，在更新一个实例前，会先等前序实例已经更新并达到 Ready 状态。

如果是有角色（下面章节会讲）的实例，InstanceSet 会按照角色权重从低到高进行更新，如果实例角色权重相同，则进一步按照 Ordinal 从大到小顺序进行更新。

InstanceSet 支持通过 spec.updateStrategy 配置更多的更新行为，比如通过 spec.UpdateStrategy.rollingUpdate.partition 控制更新的实例总数量，通过 spec.UpdateStrategy.rollingUpdate.maxUnavailable 控制更新期间最大不可用实例数量。详细说明可参考 spec.updateStrategy API 描述。

原地更新（In-place update）

应用系统通常对数据库有很高的可用性要求，通常情况下，Pod 更新实际采取的动作是重建（Recreate），重建 Pod 需要一定的时间，这会导致数据库服务有一段时间不可用。

为了降低更新对数据库服务可用性的影响，InstanceSet 支持了实例原地更新能力，在实例模板中部分字段更新时，InstanceSet 会采用原地更新 Pod 或扩容 PVC 的方式，实现实例更新。

哪些字段支持原地更新

从原理上来讲，InstanceSet 原地更新复用了 Kubernetes Pod API 原地更新能力。所以具体支持的字段如下：

  • spec.template.metadata.annotations
  • spec.template.metadata.labels
  • spec.template.spec.activeDeadlineSeconds
  • spec.template.spec.initContainers[*].image
  • spec.template.spec.containers[*].image
  • spec.template.spec.tolerations (只支持新增 Toleration)
  • spec.instances[*].annotations
  • spec.instances[*].labels
  • spec.instances[*].image

Kubernetes 从 1.27 版本开始，通过 PodInPlaceVerticalScaling 特性开关可进一步开启对 CPU 和 Memory 的原地更新支持。InstanceSet 会自动探测 Kubernetes 版本和特性开关，并进一步支持如下能力：

对于大于等于 1.27 且 PodInPlaceVerticalScaling 已开启的 Kubernetes，支持如下字段的原地更新：

  • spec.template.spec.containers[*].resources.requests["cpu"]
  • spec.template.spec.containers[*].resources.requests["memory"]
  • spec.template.spec.containers[*].resources.limits["cpu"]
  • spec.template.spec.containers[*].resources.limits["memory"]
  • spec.instances[*].resources.requests["cpu"]
  • spec.instances[*].resources.requests["memory"]
  • spec.instances[*].resources.limits["cpu"]
  • spec.instances[*].resources.limits["memory"]

对于 PVC，InstanceSet 同样复用 PVC API 的能力，仅支持 Volume 的扩容。
详细介绍可以参考原地更新特性介绍章节。

实例模板

默认情况下，InstanceSet 通过同一个模板生成所有的实例。

部分场景下，同一个 InstanceSet 中，需要有不同设置的实例，比如不同的资源配置或环境变量。InstanceSet 支持在默认实例模板基础上，定义更多实例模板，以便满足此类需求。

仍以前文中名称为 mydb 的 InstanceSet 为例，如果要将其配置为一个大规格主实例、两个小规格从实例，可通过如下方式实现：

apiVersion: workloads.kubeblocks.io/v1alpha1
kind: InstanceSet
metadata:
  name: mydb
spec:
  replicas: 3
  template:
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: mydb
        image: registry.kubeblocks.io/mydb:15.1
        ports:
        - containerPort: 5123
          name: db
        volumeMounts:
        - name: data
          mountPath: /var/mydb/
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "my-storage-class"
      resources:
        requests:
          storage: 10Gi
  instances:
  - name: primary
    replicas: 1
    resources:
      limits:
        cpu: 8
        memory: 16Gi
  - name: secondary
    replicas: 2
      resources:
        limits:
          cpu: 4
          memory: 8Gi

详细介绍可以参考实例模板特性介绍章节。

角色

大部分数据库系统都支持多实例部署，同时每个实例承担不同的角色，这个角色通常由它们内在的数据复制关系决定。比如 PostgreSQL 中有 Primary、Secondary 角色，etcd 中有 leader、follower、learner等角色。

在一个数据库系统中，不同角色的实例会存在差异。比如在对外提供的服务能力上，通常主节点可以提供读写能力，其它节点提供只读能力。在运维时，按照数据库运维最佳实践，通常先逐个升级备实例，最后升级主实例，在升级主实例前，需要先做一次 switchover，以保证数据的完整性并降低服务不可用时间。

针对这些特点，InstanceSet 中设计了若干与数据库角色相关的特性。

围绕角色相关的功能特性包括角色定义、角色探测、基于角色的服务、基于角色的更新策略等。

角色定义用来描述系统中有几个角色、分别有哪些属性。

角色探测根据配置的探测方法去周期性探测每个实例中的角色，并及时更新到对应实例的 Label 上。

基于每个实例的角色 Label，在 Service 中可以筛选出特定的角色，以便提供相应的服务能力，同时基于实例的角色，在做实例更新时，可基于角色优先级确定实例更新顺序。

角色定义

InstanceSet 可通过 spec.roles 定义所有的角色信息，包括角色名称、读写能力、是否参与选举、是否 Leader 等。

比如 PostgreSQL 数据库可配置如下：

spec:
  roles:
  - name: "primary"
    accessMode: ReadWrite
    isLeader: true
  - name: "secondary"
    accessMode: Readonly

角色探测

InstanceSet 中会预制一个角色探测 Sidecar，该 Sidecar 会根据周期性的执行配置的角色探测脚本，并配合 InstanceSet Controller 最终将角色名称更新到对应的实例 Label 上。

角色探测脚本可通过如下方式配置：

spec:
  roleProbe:
    customHandler:
    - image: probe.kubeblocks.io/sample-probe:1.0
      cmd: ["probe"]
      args: ["redis"]
    periodSeconds: 5
    roleUpdateMechanism: DirectAPIServerEventUpdate

该示例中，通过这配置，角色探测 Sidecar 会每隔 5 秒执行一次 sample-probe 镜像中的 probe 命令，并将探测结果封装在 K8s Event 中发给 InstanceSet Controller。InstanceSet Controller 在收到该事件后，会解析出每个实例的角色信息，并更新到到每个实例的角色 Label 上。角色 Label 的格式为：kubeblocks.io/role=<role.name>。同时 InstanceSet Controller 会进一步将角色读写能力也更新到实例 Label 上，格式为：workloads.kubeblocks.io/access-mode=<role.accessMode>。

基于角色的服务

通过配置 Service 中的 Selector，以匹配实例上不同的角色 Label 和读写能力 Label，可以使得该 Service 具备不同的服务能力。

比如 PostgreSQL 的读写服务可配置如下：

apiVersion: v1
kind: Service
metadata:
  name: pg-readwrite-svc
spec:
  selector:
    workloads.kubeblocks.io/managed-by: InstanceSet
    workloads.kubeblocks.io/instance: mydb
    kubeblocks.io/role: primary

基于角色的更新策略

前文中讲述实例更新时提到，当配置了角色后，InstanceSet 在做更新时会进一步考虑角色的优先级。

具体来说，InstanceSet 通过 spec.memberUpdateStrategy 支持三种角色更新策略：Serial，Parallel，BestEffortParallel。

Serial 即按照角色优先级从低到高依次更新实例。如果两个实例角色优先级相同，则进一步按照 Ordinal 从大到小进行更新。

Parallel 即所有实例并行进行更新，同时遵循 spec.updateStrategy 中的更新策略。

BestEffortParallel 即在保证系统可用的前提下，按照角色优先级从小到大分批进行。更新时同时遵循 spec.updateStrategy 中的更新策略。

大规模实例管理

InstanceSet 最高可管理 10,000 实例，当管理实例数量较多时，可通过 KUBEBLOCKS_RECONCILE_WORKERS 环境变量配置 InstanceSet Controller 的并发工作节点数量，以提高处理速度。

End

KubeBlocks 已发布 v0.9.0！KubeBlocks v0.9.0 全面升级了 API，构建一个 Cluster 更像是在用 Component “搭积木”！新增 topologies 字段，支持多种部署形态。InstanceSet 代替了 StatefulSet 来管理 Pods，支持将指定的 Pod 下线、Pod 原地更新，同时也支持数据库主从架构里主库和从库采用不同的 Pod spec。v0.9.0 还新增了 Reids 集群模式（分片模式），系统的容量、性能以及可用性显著提升！还支持了 MySQL 主备，资源的要求更少，数据复制的开销也更小！快来试试看！

小猿姐诚邀各位体验 KubeBlocks，也欢迎您成为产品的使用者和项目的贡献者。跟我们一起构建云原生数据基础设施吧！

官网: www.kubeblocks.io

GitHub: https://github.com/apecloud/kubeblocks

Get started: https://cn.kubeblocks.io/docs/preview/user-docs/try-out-on-pl...

关注小猿姐，一起学习更多云原生技术干货。

我们今天的关于轻松集成系列四：如何在 KubeBlocks 中更新参数｜以 Oracle MySQL 为例和kubectl 更新deployment的分享已经告一段落，感谢您的关注，如果您想了解更多关于KubeBlocks 0.6.0 发布！KubeBlocks支持Kafka、Pulsar、多款向量数据库、MySQL读写分离啦！、KubeBlocks v0.7.0 发布！支持引用外部组件，解耦备份 API，还支持了 Pika！、KubeBlocks v0.8.0 发布！Component API 让数据库引擎组装更简单！、KubeBlocks v0.9 解读｜最高可管理 10K 实例的 InstanceSet 是什么？的相关信息，请在本站查询。

本文标签：

上一篇MySQL 数据脱敏方式盘点（mysql数据脱敏处理方法）

下一篇为何在中国 MySQL 远比 PostgreSQL 流行（mysql为什么很受大家青睐）

相关文章