作者： db_user 原文来源：https://tidb.net/blog/632757c2

一、前言

经过一段时间的测试，对 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 等相关操作，但如果能够定义初始化的配置文件，集群名称等，能够检测真实的集群各个组件的数量，有详细的集群界面扩缩容的报错，有备份恢复的方式会更好一些。