MatrixOne 实战系列回顾 | MatrixOne 集群运维
为大家带来本次 MatrixOne 实战直播系列第四部分集群运维。本次将从四个方向为大家演示 MatrixOne 的功能。分别是版本升降、集群扩缩、集群调优以及最后的 QA 环节。
Part 1 版本升降
首先我们采用替换二进制文件进行单机版 MatrixOne 版本的升降。从 0.8.0 版本开始，MatrixOne 所有后续版本都将与 0.8.0 版本的底层数据存储格式保持兼容，各个版本间可以平滑升降级（低于 0.8.0 版本无法使用这种方式进行升降级）。MatrixOne 只有一个二进制程序包，对于单机版本我们可以非常方便的通过手动替换 mo-service 文件进行版本升降。
#1 mo_ctl 工具
我们基于当前安装的 1.0.0-rc2 版本进行升级，升级至最新的 1.0.0 版本。这里我们先使用 mo_ctl 工具将当前服务进行停止，然后将旧的 mo-service 服务进行备份，拷贝新版的 mo-service 服务进来，通过 mo_ctl 工具进行启动和连接。后面我们介绍一下 mo_ctl 工具。
mo_ctl 是一款帮助单机版 MatrixOne 进行部署安装、启停控制以及数据库连接等操作的命令行工具。mo_ctl 工具提供了比较丰富的参数使用。包含了常用的部署卸载、启停、状态查看、参数修改等功能。从安装方式上来看可以采用一键安装，如果网络问题或者您使用的是离线环境，可以采用离线安装的方式。基于 mo_ctl 工具我们可以对单机版的 MatrixOne 进行升级和降级。
我们只需要执行一条命令指定版本即可完成升级和降级，这里除了指定版本还可以指定 commit id 和分支来进行更细粒度的升级。
#2 使用 K8S 管理集群
▶ 2.1 MatrixOne Operator
MatrixOne Operator 是用来定义和管理 MatrixOne 集群在 K8S 的资源需求，由一组 K8S 自定义资源（CustomResourceDefinitions, CRD），一组 K8S 控制器和一组 WebHook 服务组成。
▶ 2.2 CRD
有了用来管理集群资源的组件，接下来我们一起来看下什么是自定义资源，也就是 CRD。
在 K8S 中，CRD 是一个对象，用于注册新的自定义资源类型到 K8S APIServer 中。MatrixOne Operator 中包含的 CRDs 注册了多种自定义资源，包括用于描述 MatrixOne 集群的 MatrixOneCluster 资源、以及描述集群内组件的 CNSet、TNSet、LogSet 等资源。注册完成后，客户端就能够在 K8S APIServer 上读写这些资源。
▶ 2.3 控制器
接下来是控制器，它是一个长期运行的自动化程序，负责监控 Kubernetes 中资源的期望状态和收集这些资源的实际状态，并自动运维，驱动实际状态向期望状态转移。matrixone-operator 中的控制器会监视 MatrixOneCluster、CNSet、TNSet、LogSet 等资源，并负责实现用户通过这些资源声明的期望状态。
▶ 2.4 Webhook 服务
Webhook 服务是一个长期运行的 HTTP 服务。当 Kubernetes APIServer 收到用户读写 MatrixOneCluster、CNSet、TNSet、LogSet 等资源的请求时，会将请求转发给 Webhook 服务，由 Webhook 服务执行请求校验、默认值填充等逻辑。
▶ 2.5 MatrixOneCluster
MatrixOne Operator 通过 MatrixOneCluster 资源为用户提供了声明式的集群管理能力。具体而言，在 Kubernetes 上部署 MatrixOne 集群时，用户可以使用 YAML 格式声明一个 MatrixOneCluster 对象来描述集群，该 operator 的控制器会根据该描述实现集群的编排，并将集群状态更新到 MatrixOneCluster 对象的 .status 字段中。
MatrixOneCluster 集群由多个组件（如 Compute Node（CN）、Transaction Node（TN）和 Log Service）构成，这些组件对应于 CNSet、TNSet 和 LogSet 等子资源。因此，MatrixOneCluster 资源的控制器会编排这些子资源，并依赖这些子资源的控制器来完成它们的编排。
#3 MatrixOne 集群升降级
在进行 MatrixOne 集群升降级之前我们先给大家演示一下 MatrixOne Operator 的升降级。我们通过 helm 的方式来部署一个 1.0.0-alpha.1 版本的 operator，基于它完成后续的升级：
首先通过 wget 命令下载 operator 安装包。
下载完成解压安装包。进入到解压后的路径，然后执行 helm 命令安装 operator，指定命名空间。
安装完成以后我们可以通过 helm list 命令查看安装信息。也可以通过 kubectl 命令查询 operator 对应的 pod 状态。
Operator 的升级也是基于 helm 方式的，同样我们需要下载并解压需要升级至的版本安装包，
然后采用 helm 命令，区别于安装这里使用的是 upgrade 参数。
升级完成以后我们可以通过 helm list 命令查看安装信息。也可以通过 kubectl 命令查询 operator 对应的 pod 状态。
接下来给大家演示一下 MatrixOne 集群的升降级。
先来介绍一下滚动升级。它是一种在线升级方式，即 MatrixOne 集群在保证部分或全部服务可用的情况下完成软件的升级。
基于滚动升级的方式来完成 MatrixOne 就是通过动态修改 MatrixOne Operator 中的 MatrixOne 镜像版本号来实现自动的版本更新。通过 kubectl edit 命令我们可以直接对已经加载到内存的 crd 进行修改，修改集群的镜像版本，这里需要找到 version 关键字。我们这里演示的小版本的升级，从 1.0.0-rc1 升级至 git 上最近的一次更新版本。这里需要注意的：mo 是 matrixone 的集群名称，一般为 mo，根据部署时 matrixonecluster 对象的 yaml 文件中的 name 指定，我们这里没有修改所以为默认。通过 kubectl 命令增加--watch 参数我们可以观察滚动升级的全过程。全部升级成功以后，我们使用 mysql 客户端连接验证升级成功。
接下来我们再来演示一下降级过程，加深一下印象。同理通过 kubectl edit 命令修改镜像版本，这里我们将刚才的升级进行回滚，回滚至 1.0.0-rc1 版本。通过 kubectl 命令增加--watch 参数我们可以观察滚动回滚的全过程。全部回滚成功以后，我们使用 mysql 客户端连接验证一下。
Part 2 集群扩缩
#1 operator 扩缩容
演示完服务的升级与回滚，接下来我们一起看下集群版本的扩缩容。首先我们来看下 operator 的扩缩容。
通常情况下，Operator 是单副本的，我们可以通过扩展副本数来实现 Operator 的高可用性。这对于 MatrixOne 集群的部署和运维管理操作非常重要。
这里使用 helm 的方式进行扩缩容。可以看到使用 set replicaCount 参数指定需要扩容或缩容后的数量就可以完成扩缩容。扩容成功后可以通过 kubectl 命令查询 operator 对应的 pod 实例数量变化。缩容同理。
在演示扩缩容 MatrixOne 集群之前我们分析一下什么情况下进行缩容比较合适。
一般情况下，如果发现节点或者 Pod 的资源使用率超过了 60% 并且持续一段时间，可能需要考虑进行扩容以应对负载高峰。此外，如果根据业务指标观察到高的 TPS 请求量，也需要考虑进行扩容操作。
节点和实例监控：为了确定是否需要对 MatrixOne 服务进行扩缩容，用户需要监控 MatrixOne 集群所在的节点和相关组件对应的 Pod 所使用的资源。你可以使用 kubectl top 命令来完成此操作。
#2 kubectl top 命令
kubectl top 工具需要我们额外安装。可以先执行下 kubectl top 命令验证下机器是否已经存在。这里为大家演示一下 top 工具的安装：
首先需要下载安装资源清单，也就是 yaml 配置文件。
然后修改下载好的 components.yaml。
分别修改镜像仓库为国内镜像，然后修改不认证 CA 证书。
修改完成后使用 apply 方式部署。
查看 pod 启动情况，这个 pod 名称是 metric-server 开头。
成功以后我们就可以通过 kubectl top 命令检测集群资源情况了。这里可以检测某一个 pod 也可以检测 k8s 节点情况。
#3 kubectl edit 命令
当发现集群资源不足时，我们应当进行扩容。
扩容和升级一样，我们通过 kubectl edit 命令修改 crd，找到需要缩容服务的位置和实例数关键字 replica 进行修改。这里我们将计算节点 tp 从 3 个扩展至 5 个。执行成功后通过--watch 观察扩容全过程。
当发现集群资源比较空闲，为了节约资源我们可以进行缩容。同理我们演示一下缩容过程为大家加深印象。
通过 kubectl edit 命令修改 crd，找到需要缩容服务的位置和实例数关键字 replica 进行修改。需要注意 cn 节点的关键字是 tp，不要修改错误了。这里我们将计算节点 tp 从 5 个缩容至 3 个，提升集群的查询计算能力。执行成功后通过--watch 观察扩容全过程。
Part 3 集群调优
服务部署成功以后调优和排错也是大家比较关心的。我这里给大家总结几个调优的思路，也是来源于咱们官网性能调优那一部分。
#1 性能调优
▶ 1.1 索引优化
即通过创建索引的方式来提升查询效率，但是也会存在有空间的额外开销，即用空间换时间的一种方式。因此需要注意使用正确的索引类型、选择正确的索引列、避免使用过多的索引以及定期重新构建索引等方法，可以最大化地利用索引来提高性能。
▶ 1.2 建表优化
优化表结构，如选择正确的数据类型、避免 NULL 值、使用合适的约束和默认值、归一化和反归一化等方法，可以减少表的存储空间和减少查询的时间。
▶ 1.3 查询优化
就是对我们编写的 SQL 进行调优，避免使用不必要的子查询、使用更有效的 JOIN 语句、避免使用 OR 操作符等方法，可以减少查询所需的时间和资源。
▶ 1.4 控制数据量
即裁剪数据集。通过限制返回的数据量、分页、缓存、使用存储过程等方法，可以减少查询所需的时间和资源。
▶ 1.5 服务器调优和监控
通过增加服务器的内存、调整数据库参数、定期清理日志和缓存等方法，可以提高数据库的性能和响应时间。使用数据库性能监控工具、调试 SQL 查询语句、查看数据库的日志和错误信息等方法，可以帮助发现并解决性能问题。
#2 调优方式
下面我来看几个常用的调优方式。
我们可以通过 explain 分析查询计划，语法就是在编写的 sql 前面加上这个关键字。
我先给大家演示一个案例。创建一个 test 库，在这个库下面创建一个 a 表有一字段，新增 8 条数据。我们编写了一个查询语句，有筛选条件 a 大于等于 2 小于等 8。执行后如果我们想要拿到执行计划，需要在 sql 前面加上 explain 关键字。执行成功后会打印一个完整的执行树。
以上是该查询的执行计划结果。从 Filter Cond 算子开始向上看，查询的执行过程如下：
先执行过滤条件 Filter Cond：即过滤出数据类型为 BIGINT 且大于等于 2，小于等于 8 的整数，按照计算推理，应该为 (2),(3),(4),(5),(6),(7),(8)。
扫描数据库 aab 中的表 a。
聚合计算满足条件整数的个数，为 7 个。
最终，得到查询结果为 7，即 count(*) = 7。
如果你想看一下每一个过程的花费的时间和内存，就可以使用 explain analyze。
这里还是继续使用之前的案例，你可以在查询语句前增加 explain analyze 关键字。
可以关注这几个参数：
timeConsumed 耗时
inputRow 读取的行数
inputSize 读取的容量大小
memorySize 所耗费内存大小
通过这个分析我们可以了解到这次查询每一个过程的耗时，进而可以定位具体哪一部分慢了，哪里一部分吃内存多等等。当我们发现查询变慢的时候，我们可以开启慢来查看细节。当前 MatrixOne 的慢查询是超过 1000 毫秒的查询。
慢查询日志默认关闭，要使用慢查询日志功能，首先要开启慢查询日志功能。
我们可以通过 2 中方式开启慢查询，一种是不带执行计划的方式，使用关键字 create view slow_query 后续跟上需要定位的 sql。第二种是 create view slow_query_with_plan，这种方式可以看到执行计划。
然后分别使用 select * from mo_ts.slow_query 和 select * from mo_ts.slow_query_with_plan 查看 2 种方式的慢查询对应的结果，如果没有记录表示当前查询非慢查询。
慢查询结果会返回下面几个字段：
statement：即 SQL 文本，用于提供完整的 SQL 语句。
request_at：SQL 语句的的起始时间。
duration_second：SQL 语句的实际执行时间。
exec_plan：SQL 语句的详细执行计划。
#3 错误日志
下面给大家分享一种排错的方案---错误日志。在开启了慢查询的情况下，可以开启错误日志，检查日志，定位错误信息。
通过执行这个 sql（create view error_message as select timestamp,message from system.log_info where level in ('error','panic','faltal');）我们可以开启错误信息抓取。timestamp 和 message 分别查看错误发生的时间和错误信息。Level 表示抓取错误的级别。当前有 3 个级别 error,panic'falta'
开启后查询方式 select * from mo_ts.error_message 进行查看。
同理如果我们查询要发生错误的 sql，可以使用这个 sql（create view error_sql as select si.request_at time_stamp,si.statement,si.error as SQL from system.statement_info si where si.user<>'internal' and si.status='Failed' ;） time_stamp 是发生错误的时间，statement 是发生错误的 SQL 语句。开启成功后使用 select * from mo_ts.error_sql 进行查看。
Part 4 Q&A 环节
感谢大家和我一起学习 MatrixOne 集群运维的相关知识，下面进入 Q&A 环节。
Q: 二进制包安装可以通过 mo_ctl 管理吗？
A: 通过设置 MO_PATH 配置二进制包的路径，就可以使用 mo_ctl 进行管理了。
Q: 当前非 k8s 版本是否支持主从配置？
A: 当前还不支持，后续会支持。
Q: operator 的版本在部署的是否有要求？
A: operator 是用来管理 MatrixOne 集群的，所以 operator 版本尽量与集群的版本保持一致，比如我们安装了 1.0.0-rc2 这个版本的集群，对应提前安装的 operator 版本也应该为 1.0.0-rc2。
Q: helm 方式部署的 operator 如何进行卸载？
A: 通过 helm uninstall 命令指定名称和命名空间进行卸载。
Q: 请问 0.7 版本能否升级到最新的 1.0 版本?
A: 当 0.7 版本无法直接升级至 1.0，建议备份数据，进行重装后导入。
Q: mo_ctl 工具是否支持源码部署升级？
A: 通过 upgrade 命令可以指定对应的版本或者 commitid 进行细粒度升级，需要注意的设置当前版本 MO_PATH，以及编译环境。
Q: k8s 集群节点当前 dn（也叫 tn）节点是否支持扩容？
A: 当前 dn 节点还不支持扩容。
Q: mo_ctl 工具是否支持部署 matrixOne 集群？
A: 当前还不支持，后续考虑加入集群部署和管理。
关于 MatrixOne
MatrixOne 是一款基于云原生技术，可同时在公有云和私有云部署的多模数据库。该产品使用存算分离、读写分离、冷热分离的原创技术架构，能够在一套存储和计算系统下同时支持事务、分析、流、时序和向量等多种负载，并能够实时、按需的隔离或共享存储和计算资源。云原生数据库 MatrixOne 能够帮助用户大幅简化日益复杂的 IT 架构，提供极简、极灵活、高性价比和高性能的数据服务。
MatrixOne 企业版和 MatrixOne 云服务自发布以来，已经在互联网、金融、能源、制造、教育、医疗等多个行业得到应用。得益于其独特的架构设计，用户可以降低多达 70%的硬件和运维成本，增加 3-5 倍的开发效率，同时更加灵活的响应市场需求变化和更加高效的抓住创新机会。在相同硬件投入时，MatrixOne 可获得数倍以上的性能提升。
MatrixOne 秉持开源开放、生态共建的理念，核心代码全部开源，全面兼容 MySQL 协议，并与合作伙伴打造了多个端到端解决方案，大幅降低用户的迁移和使用成本，也帮助用户避免了供应商锁定风险。
MatrixOrigin 官网：新一代超融合异构开源数据库-矩阵起源（深圳）信息科技有限公司 MatrixOne
Github 仓库：GitHub - matrixorigin/matrixone: Hyperconverged cloud-edge native database
关键词：超融合数据库、多模数据库、云原生数据库、国产数据库
版权声明: 本文为 InfoQ 作者【MatrixOrigin】的原创文章。
原文链接:【http://xie.infoq.cn/article/a924a7b800df80c57c938ed23】。文章转载请联系作者。
还未添加个人签名 2021-12-06 加入
一个以技术创新和用户价值为核心的基础软件技术公司。
评论