MatrixOne实战系列回顾 | MatrixOne 集群运维

1.

我们基于当前安装的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.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 资源的控制器会编排这些子资源，并依赖这些子资源的控制器来完成它们的编排。

在进行MatrixOne集群升降级之前我们先给大家演示一下MatrixOne Operator的升降级。我们通过helm的方式来部署一个1.0.0-alpha.1版本的operator，基于它完成后续的升级：

1. 首先通过wget命令下载operator安装包。

2. 下载完成解压安装包。进入到解压后的路径，然后执行helm命令安装operator，指定命名空间。

3. 安装完成以后我们可以通过helm list 命令查看安装信息。也可以通过kubectl命令查询operator对应的pod状态。

4. Operator的升级也是基于helm方式的，同样我们需要下载并解压需要升级至的版本安装包，

5. 然后采用helm命令，区别于安装这里使用的是upgrade 参数。

6. 升级完成以后我们可以通过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客户端连接验证一下。

2.

演示完服务的升级与回滚，接下来我们一起看下集群版本的扩缩容。首先我们来看下operator的扩缩容。

通常情况下，Operator 是单副本的，我们可以通过扩展副本数来实现 Operator 的高可用性。这对于 MatrixOne 集群的部署和运维管理操作非常重要。

这里使用helm的方式进行扩缩容。可以看到使用set replicaCount参数指定需要扩容或缩容后的数量就可以完成扩缩容。扩容成功后可以通过kubectl命令查询operator对应的pod实例数量变化。缩容同理。

在演示扩缩容MatrixOne集群之前我们分析一下什么情况下进行缩容比较合适。

一般情况下，如果发现节点或者 Pod 的资源使用率超过了 60% 并且持续一段时间，可能需要考虑进行扩容以应对负载高峰。此外，如果根据业务指标观察到高的 TPS 请求量，也需要考虑进行扩容操作。

节点和实例监控：为了确定是否需要对 MatrixOne 服务进行扩缩容，用户需要监控 MatrixOne 集群所在的节点和相关组件对应的 Pod 所使用的资源。你可以使用 kubectl top 命令来完成此操作。

kubectl top 工具需要我们额外安装。可以先执行下kubectl top命令验证下机器是否已经存在。这里为大家演示一下top工具的安装：

1. 首先需要下载安装资源清单，也就是yaml配置文件。
   

2. 然后修改下载好的components.yaml。
   

3. 分别修改镜像仓库为国内镜像，然后修改不认证CA证书。

4. 修改完成后使用apply方式部署。
   

5. 查看pod启动情况，这个pod名称是metric-server开头。

6. 成功以后我们就可以通过kubectl top命令检测集群资源情况了。这里可以检测某一个pod也可以检测k8s节点情况。

当发现集群资源不足时，我们应当进行扩容。

扩容和升级一样，我们通过kubectl edit命令修改crd，找到需要缩容服务的位置和实例数关键字replica进行修改。这里我们将计算节点tp从3个扩展至5个。执行成功后通过--watch观察扩容全过程。

当发现集群资源比较空闲，为了节约资源我们可以进行缩容。同理我们演示一下缩容过程为大家加深印象。

通过kubectl edit命令修改crd，找到需要缩容服务的位置和实例数关键字replica进行修改。需要注意cn节点的关键字是tp，不要修改错误了。这里我们将计算节点tp从5个缩容至3个，提升集群的查询计算能力。执行成功后通过--watch观察扩容全过程

 ▶ 1.1 索引优化 

即通过创建索引的方式来提升查询效率，但是也会存在有空间的额外开销，即用空间换时间的一种方式。因此需要注意使用正确的索引类型、选择正确的索引列、避免使用过多的索引以及定期重新构建索引等方法，可以最大化地利用索引来提高性能。

 ▶ 1.2 建表优化 

优化表结构，如选择正确的数据类型、避免 NULL 值、使用合适的约束和默认值、归一化和反归一化等方法，可以减少表的存储空间和减少查询的时间。

 ▶ 1.3 查询优化 

就是对我们编写的SQL进行调优，避免使用不必要的子查询、使用更有效的 JOIN 语句、避免使用 OR 操作符等方法，可以减少查询所需的时间和资源。

 ▶ 1.4 控制数据量 

即裁剪数据集。通过限制返回的数据量、分页、缓存、使用存储过程等方法，可以减少查询所需的时间和资源。

 ▶ 1.5 服务器调优和监控 

通过增加服务器的内存、调整数据库参数、定期清理日志和缓存等方法，可以提高数据库的性能和响应时间。使用数据库性能监控工具、调试 SQL 查询语句、查看数据库的日志和错误信息等方法，可以帮助发现并解决性能问题。

下面我来看几个常用的调优方式。

我们可以通过explain分析查询计划，语法就是在编写的sql前面加上这个关键字。

我先给大家演示一个案例。创建一个test库，在这个库下面创建一个a表有一字段，新增8条数据。我们编写了一个查询语句，有筛选条件a大于等于2小于等8。执行后如果我们想要拿到执行计划，需要在sql前面加上explain关键字。执行成功后会打印一个完整的执行树。

以上是该查询的执行计划结果。从 Filter Cond 算子开始向上看，查询的执行过程如下：

1. 先执行过滤条件 Filter Cond：即过滤出数据类型为 BIGINT 且大于等于 2，小于等于 8 的整数，按照计算推理，应该为 (2),(3),(4),(5),(6),(7),(8)。

2. 扫描数据库 aab 中的表 a。

3. 聚合计算满足条件整数的个数，为 7 个。

4. 最终，得到查询结果为 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 语句的详细执行计划。

下面给大家分享一种排错的方案---错误日志。在开启了慢查询的情况下，可以开启错误日志，检查日志，定位错误信息。

通过执行这个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进行查看。

通过设置MO_PATH配置二进制包的路径，就可以使用mo_ctl进行管理了。

当前还不支持，后续会支持。

operator是用来管理matrixOne集群的，所以operator版本尽量与集群的版本保持一致，比如我们安装了1.0.0-rc2这个版本的集群，对应提前安装的operator版本也应该为1.0.0-rc2。

通过helm uninstall命令指定名称和命名空间进行卸载。

当0.7版本无法直接升级至1.0，建议备份数据，进行重装后导入。

通过upgrade命令可以指定对应的版本或者commitid进行细粒度升级，需要注意的设置当前版本MO_PATH，以及编译环境。

当前dn节点还不支持扩容。

当前还不支持，后续考虑加入集群部署和管理。