导读

在过去的一个月里，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/docs/zh/