写点什么

TiDB Operator 常见问题和解决步骤(一)

  • 2023-03-31
    北京
  • 本文字数:2821 字

    阅读完需:约 9 分钟

作者: lqbyz 原文来源:https://tidb.net/blog/8b92c1ce


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

出现问题

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。



发布于: 刚刚阅读数: 2
用户头像

TiDB 社区官网:https://tidb.net/ 2021-12-15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目,旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

评论

发布
暂无评论
TiDB Operator常见问题和解决步骤(一)_实践案例_TiDB 社区干货传送门_InfoQ写作社区