导读

在过去的一个月里,OpenMLDB 快速迭代了多个小版本 (v0.6.4-v0.6.6),在增强功能的同时,也提高了运维效率。在运维方面,进行了对易用性、可观测性、自动化等方面的改进。本文将介绍 OpenMLDB 在 v0.6 版本迭代过程中运维方面所做的优化。

增强的集群状态查询

1

针对数据库的异常状态展示,OpenMLDB 增强了 SHOW TABLE STATUS 命令,更有利于排查数据库可能存在的问题。相比之前,增加了更多的逻辑检查,还增加了一列 Warnings ,用于显示当前数据库表格的异常状态。目前可以查询到的异常状态包括:

  • Nameserver 上记录的 leader/follower 信息和 tablet 上面的实际分布不一致。可能的原因为 tablet 或者 nameserver 访问 ZooKeeper 出现异常。
  • 分片状态异常。包括分片不存在、未成功加载和正在加载中(稍等可用)。造成分片不存在或者未成功加载的原因可能为 tablet 重启后,未成功恢复出表中数据,比如 auto_failover 设置为 false 或者多副本表所在 tablet 异常退出,造成处于不可自动恢复状态。
  • 副本数目和配置的 replicanum 不匹配。可能的原因为 tablet 启动后,部分副本恢复异常。
  • follower 和 leader 未连接(通常和上述的副本数目不匹配问题同时出现)。其可能的原因为添加新副本后,由于网络原因,tablets 和 nameserver 同步异常。

详情请参考 SHOW TABLE STATUS 命令,地址:https://openmldb.ai/docs/zh/main/reference/sql/ddl/SHOW_TABLE_STATUS.html

异常状态下数据快速恢复

2

一般情况,当您重启服务时,表中数据会自动恢复,并不需要干预。但是如果出现上述的集群异常状态,一般需要进行手动数据恢复。在以前的 OpenMLDB 版本中,手动数据恢复需要登录 ns client 后手动运行一系列命令,相当复杂繁琐。为此,OpenMLDB 新增了一个运维工具,拥有一键数据恢复功能,运行以下命令实现:

python tools/openmldb_ops.py --openmldb_bin_path=./bin/openmldb --zk_cluster=172.24.4.40:30481 --zk_root_path=/openmldb --cmd=recoverdata

详情请参考 运维 FAQ,地址:

https://openmldb.ai/docs/zh/main/maintain/faq.html#id3

扩缩容自动化分片迁移

3

为了实现扩缩容,在新节点加入或者移除以后,需要进行分片的迁移。在以往的版本中,分片迁移需要通过手动方式进行(详情请参考 阔缩容文档,地址:

https://openmldb.ai/docs/zh/main/maintain/scale.html)。手动方式可以提供精准的按需迁移,但是也增加了运维门槛。v0.6 版本引入了分片自动迁移机制,通过运维工具的 scaleout 和 scalein 命令,可以实现分片自动迁移,如:

python tools/openmldb_ops.py --openmldb_bin_path=./bin/openmldb --zk_cluster=172.24.4.40:30481 --zk_root_path=/openmldb --cmd=scaleout

详情请参考 运维工具说明,地址:

https://openmldb.ai/docs/zh/main/maintain/openmldb_ops.html

目前,自动化迁移策略会分别对每个数据库下面的所有表进行分片的均衡,目标为分片数目在所有 tablets 上尽量平均。算法基于启发式算法,基本思路如下:

  • 从拥有分片最多的 tablet 里,随机选择某一个分片,迁移到拥有分片最少的 tablet 上。
  • 所有 tablets 的分片数目基本一致,即:当拥有最多分片的 tablet 比拥有最少分片的 tablet 的分片数目不大于 1 时,算法终止。

我们将持续改进分片自动迁移算法,以满足不同场景下的负载自动平衡。

了解更多:

OpenMLDB GitHub:

https://github.com/4paradigm/OpenMLDB

OpenMLDB 官网:

https://openmldb.ai/

OpenMLDB 文档:

https://openmldb.ai/docs/zh/