数据库 TiDB 试用实践——部署&运维

网友投稿 687 2023-04-04

一、前言

经过一段时间的测试,对tidb的***计算巢服务有了一定的了解,整体服务架构官网已经给出,如下图所示,接下来说说整体的体验感受

云数据库 TiDB 试用实践——部署&运维

二、实际试用

1.部署

首先来说说部署方面,整体的部署流程非常简单。填写所需的服务实例名称(这里要注意,服务实例名称不是真实的cluster name,真实的cluster name是写死的tidb-prod,官方之后应该会有改进),地域,配置等,但是多可用区只有高可用版本才有,试用版是没有的,所以也就意味着在试用版试用labels的功能对可用性没有太大的意义

整体的搭建速度很快,只需要接近八分钟的时间即可,省去了自己搭建的时候创建用户,下载tiup,编辑配置文件等时间,但同时,初始化的配置文件信息不能配置也有些影响(比如new_collations_enabled_on_first_bootstrap之类的参数,只能在集群创建的时候指定,不能更改,如这种就比较不好操作了)。搭建好的集群信息如下图所示,会有节点数量,创建时间,dashboard,grafana地址等信息。

2.运维

tidb常用的运维操作,也是非常好的一个功能就是在线横向扩展,这里面把弹性扩缩容集成起来了,只需要点点点就可以了,针对tiflash,tidb,tikv有不同的模版,在扩缩容的时候可以指定对应的组件和要扩缩容的数量,不过可惜的一点是,缩容的时候不能指定ip,也就是说缩容是随机的,这可能在高可用性能上产生非预期的情况,而且当前界面上的操作详情是没有办法查看的,这一点对扩缩容失败的排查带来了一些困难。

因为扩缩容是最常见的运维操作,所以这里做了一些测试

2.1 缩容一个tikv

单个store180个region缩容情况下迁移leader和region的时间为10分钟(这个时候查看display已经实际缩容完成) 平台界面实际的时间为35分钟。缩容完成之后,pd监控会有个tombstone stores的问题,需要手动调用pd-tcl来进行操作,消除监控里的tombstone stores的问题,感觉这个加入到缩容的步骤里更好,这样可以简化人工调用调用pd-ctl的步骤

2.2 命令行界面混用缩容操作

在使用过程中发现一个问题,手动缩容的时候,集群真实的实例变少了,但是***平台界面的数量并没有变化,这就导致了下面两个场景的产生

场景一:比如初始有4个tikv,扩容之后变成5个tikv,此时在命令行中缩容一个tikv,这时集群有4个tikv,此时界面上本不应该允许继续缩容tikv,但是此时界面上记录的tikv数量为5个,所以还能继续缩容tikv,这样就导致了集群真实的tikv变成了3个。

场景二:如场景一中的例子,假如初始情况是3个tikv,最后一步缩容就会一直不成功,因为是三副本,所以tikv会一直处于pendding offline状态,这就导致了界面一直卡死的情况,等到很长一段时间后界面才会显示缩容失败,之后即使手动强制缩容,界面上的缩容也不会显示成功,而界面上缩容tikv失败之后,就无法再通过界面来对集群的tikv进行扩缩容操作,报错是因为上一个缩容操作没有正常完成

2.3 缩容tiflash

第一次想测试界面的缩容是否检测了tiflash副本,答案是肯定的,replica为1的情况下,一个tiflash不能正常缩容,界面显示缩容失败,然后又将replica设置为0,通过界面进行缩容,依旧显示缩容失败,这里比较难以理解,最后只能手动缩容,不过手动缩容就会出现上面所提到的问题,界面以为tiflash还存在着,数量并没有变更

3.删除服务实例

基本功能测完之后,对整体集群进行了回收操作,删除集群是非常方便的,只需要点击删除服务实例,8分钟整个服务实例删除完成

总结:

整体来说使用是非常方便的,包括部署和运维都能够快速上手,极大简化了基础运维操作,稍微有点基础就能上手操作,而且权限放的很开,能够在集群上做labels等相关操作,但如果能够定义初始化的配置文件,集群名称等,能够检测真实的集群各个组件的数量,有详细的集群界面扩缩容的报错,有备份恢复的方式会更好一些。

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:【SOP】新扩容节点与集群版本不一致处理
下一篇:云数据库 TiDB试用
相关文章