直播间介绍
为大家带来本次MatrixOne 实战直播系列第四部分集群运维。本次将从四个方向为大家演示MatrixOne的功能。分别是版本升降、集群扩缩、集群调优以及最后的QA环节。
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客户端连接验证一下。
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观察扩容全过程
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进行查看。
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协议,并与合作伙伴打造了多个端到端解决方案,大幅降低用户的迁移和使用成本,也帮助用户避免了供应商锁定风险。 关键词:超融合数据库、多模数据库、云原生数据库、国产数据库