TiDB Operator常见问题和解决步骤（一）

作者： lqbyz

以下是实际环境中的问题，以及相关的解决步骤和想法。请结合实际环境进行调查。如果图片有任何问题，请进一步处理私人聊天。

出现问题

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 COMMENTuuid，数据库账号，`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安装默认没有密码，最初怀疑句子有问题，在测试环境中初始化句子后，可以正常创建数据库和表格，以消除句子的问题。

2.查看operator相关日志后，未发现相应问题。初步怀疑是删除集群中的pv和数据，下次创建时直接绑定，导致使用原集群。

三、因为tidb-initializer-xpod是job类型，只能在初始化时重置密码，在整个tidb生命周期中只能执行一次，更坚信执行失败是由于之前的数据，导致执行句失败，为了验证猜测，需要创建初始执行集群，初始化失败后，创建pod，用tidb的pvc查看pv中的文件，或者用原始重置的密码访问tidb。后来发现失败的pv中有tidb数据，导致定位问题。

4.与客户确认修改pv和pvc绑定策略，解决问题，经多次验证未发现故障。

5.后来客户反馈init的时间很长，经调查发现pd、tikv、tidb还没有启动，只有启动才能初始化，需要等一会儿。同时，建议开发商在实施初始化job时增加逻辑判断，以减少前端显示的时间。

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

现象

当集群初始化时，整个tidb集群被删除，集群中的所有pod都处于termiatng状态，pod不能通过后端删除tidb。

排查步骤：

1.起初，客户怀疑是否删除operator。通过删除他们对operator的理解没有想到的逻辑，应该有上层业务逻辑来管理和删除tidb集群的tc，而不是operator。此外，我们通过operator管理集群 tidbcluster不建议通过sts管理

2.与开发商沟通后，定制CRD管理tidb集群的资源ticluster后，发现tidb集群初始化失败，直接删除整个集群，然后与开发商正常创建逻辑注释。这个问题得到了解决。

3.poddd的后续管理通过开发商的ticluster资源进行.

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初始化和monitorpod正常创建，其他组件没有正常创建

排查步骤：

1、通过前端页面重新创建tidb集群，发现很长一段时间都没有成功创建，检查集群是否没有pod创建。

2、查看tidb-controller-manager日志发现没有pv绑定，一直在等待pdpod创建:

3、查看命名空间下的PVC，发现PVC没有正常生成，基本断定了失败的原因:tidb 每个组件的pod之所以没有成功创建，是因为相应组件的pod没有找到PV绑定，PVC也没有与PV绑定。后来，在与客户沟通后，他们的新权限功能可能无法正常绑定PV。