TiDB Operator 常见问题与解决方案（一）

以下均为在实际环境中出现的问题，及相关的解决步骤和思路，请结合实际环境进行排查，图片如有任何不妥的地方，请私聊会做进一步的处理。

出现问题

1.TiDB数据初始化的时候出现如下报错

初始化语句

initSql: |- use mysql;CREATE TABLE`databaseaccount`(`uuid` varchar(32)NOT NULL COMMENT账号uuid,`name` varchar(255)NOT NULL COMMENT数据库账号,`description` varchar(2048)DEFAULT NULL COMMENT数据库账号名称,`comments` varchar(255)DEFAULT NULL COMMENT数据库账号 备注,`password` varchar(255)DEFAULT NULL COMMENT数据库密码,`status` varchar(255)NOT NULL COMMENT账号状态,是否可用[available / unavailable],`clusterUuid` varchar(32)NOT NULL COMMENT数据库账号所属集群uuid,`deleted` timestamp NULL DEFAULT NULL COMMENT是否已删除,`createDate`timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT账号创建时间,`lastOpDate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT账号上次修改时间,`level` varchar(50)NOT NULL,PRIMARY KEY(`uuid`),UNIQUE KEY`name`(`name`,`clusterUuid`))ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;CREATE TABLE`databaseprivilege`(`uuid` varchar(32)NOT NULL COMMENT数据库权限uuid,`databaseSchemaUuid` varchar(32)DEFAULT NULL COMMENT数据库schema uuid,`databaseAccountUuid` varchar(32)DEFAULT NULL COMMENT数据库账号uuid,`privilege` varchar(255)DEFAULT NULL COMMENT数据库账号权限,`createDate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,`lastOpDate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,PRIMARY KEY(`uuid`))ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT=数据库权限表; CREATE TABLE`databaseschema`(`uuid` varchar(32)NOT NULL COMMENT数据库uuid,`name` varchar(255)NOT NULL COMMENT数据库名称,`description` varchar(2048)DEFAULT NULL COMMENT数据库描述,`characterSet` varchar(255)NOT NULL COMMENT数据库字符集,`clusterUuid` varchar(32)NOT NULL COMMENT数据库所属集群uuid,`status` varchar(32)NOT NULL COMMENT数据库状态,是否可用[available / unavailable],`deleted` timestamp NULL DEFAULT NULL COMMENT是否已删除,`createDate`timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,`lastOpDate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,PRIMARY KEY(`uuid`),UNIQUE KEY`name`(`name`,`clusterUuid`))ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT=数据库管理表; CREATE ALGORITHM=UNDEFINED DEFINER=`root` @`localhost`SQL SECURITY DEFINER VIEW`privilegeview`(`clusterUuid`,`accountName`,`schemaName`,`privilege`)AS SELECT`a` .`clusterUuid` AS`clusterUuid`,`a` .`name` AS`accountName`,`s` .`name` AS`schemaName`,`databaseprivilege` .`privilege` AS`privilege` FROM(`mysql` .`databaseprivilege` LEFT JOIN`mysql` .`databaseaccount` AS`a` ON((`databaseprivilege` .`databaseAccountUuid`=`a` .`uuid`)))LEFT JOIN`mysql` .`databaseschema` AS`s` ON((`databaseprivilege` .`databaseSchemaUuid`=`s` .`uuid`)); passwordSecret: tidb-pwd-root-suffix

排查步骤：

1.由于通过operator安装默认是没有密码的，最初怀疑语句有问题，后经把该初始化语句在测试环境，是ok的数据库和表是可以正常创建的，排除该语句的问题。

2.经过查看operator相关的日志也没发现对应的问题，初步怀疑是删除集群里的pv还有数据，下次创建的时候又直接绑定的，造成使用原先集群的。

3.由于tidb-initializer-x的pod是job类型，只有初始化的时候重置密码才能被执行，在整个tidb的生命周期内只能执行一次，更加坚信执行失败是由于挂载的pv有以前的数据，造成执行该语句失败，为了验证该猜测，需要重新创建执行初始化的集群，等初始化失败后创建pod用tidb的pvc进pv查看里边的文件，或者使用原先重置的密码进行tidb访问，后来发现失败的pv里有tidb数据,该问题定位出现。

4.同客户确认修改pv和pvc绑定的策略，该问题解决，后经多次验证暂未发现失败的情况。

5.后来客户反馈init的时候时间很长，经排查发现pd、tikv、tidb都还没有启动完成，只有都启动完成才能做初始化来，需要稍等一下。同时建议开发商在执行初始化job的时候添加一个逻辑判断，减少前端显示的时间。

2.初始化失败tidb集群被删除。

现象

当集群出现初始化的时候整个tidb集群被删除，集群的所有pod处于termiatng状态，而且通过后端删除tidb的时候pod无法删除。

排查步骤：

1.开始客户怀疑是否operator来删除，通过对operator的了解没有想过的逻辑进行删除，应该有上层的业务逻辑对tidb集群的tc进行管理删除的，不是operator删除的。而且，我们通过operator管理集群的都是通过CRD tidbcluster进行管理的，不建议通过sts进行管理

2.后经和开发商进行沟通他们，自定义了CRD用于管理tidb集群的资源ticluster后经排查发现tidb集群初始化失败，直接删除了整个集群，后和开发商把该逻辑注释可以正常创建集群。该问题解决。

3.后续通过开发商的ticluster的资源来管理pod.

3.出现发布过程中ticluster一直处于更新中

现象

排查步骤：

1.排查tidbcluster的集群状态是true,说明tidb集群是没有没问题的。

2.客户排查由于镜像名称没处理好，所去的状态不对，修改下，问题解决。

4.新创建的集群创建很久没有成功

现象：

新创建的集群创建了很久没有成功，前端显示一直处于创建中

排查步骤

1.经过后台在K8S集群中看下tc的状态发现是flase，tidb的pod期望是2目前是1，需要查看该命名空间下的pod。

2.后经describe查看该pod的属性，发现cpu的计算资源不够了，可以断定该集群的资源不够了，需要扩充，后来扩充tidb正常创建。

5.权限问题造成集群无法正常创建

现象：

客户通过前端页面创建新的集群，只有discovery、init初始化和monitor的pod正常创建，其他的组件没有正常创建

排查步骤：

1、重新通过前端页面创建tidb的集群，发现很长时间都没有创建成功，查看集群还是没有pod被创建。

2、查看tidb-controller-manager日志发现，没有pv进行绑定，一直等待pd的pod创建：

3、查看该命名空间下的pvc,发现该PVC没有正常生成，失败的原因基本断定位：tidb 各个组件的pod都没创建成功的原因是因为对应组件的pod没有找到PV绑定，pvc没有和pv进行绑定。后来和客户沟通了下，有可能是他们新上的权限功能造成的无法正常绑定pv。