专栏 - 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的时候添加一个逻辑判断，减少前端显示的时间。