TiDB 数据库故障应急操作手册

IT那活儿 2023-12-04

469

点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！

前言

1.1 概述

本文档介绍TiDB产品应急操作相关内容。

1.2 应用范围

本文档描述生产环境TiDB服务不可用情况下应急手段。

当TiDB服务不可用时，应第一时间联系TiDB支持人员，当支持人员不能及时到达时，可按此文档操作。
按此文档操作服务恢复后，也需要联系支持人员定位原因以及回滚应急操作。

名词解释

TiDB Server
SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。
TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。
TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。
PD Server
整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界面，并为分布式事务分配事务 ID。
PD 不仅存储元信息，同时还会根据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是整个集群的“大脑”。
此外，PD 本身也是由至少 3 个节点构成，拥有高可用的能力。建议部署奇数个 PD 节点。
TiKV
负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。
存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。
TiKV 的 API 在 KV 键值对层面提供对分布式事务的原生支持，默认提供了 SI (Snapshot Isolation) 的隔离级别，这也是 TiDB 在 SQL 层面支持分布式事务的核心。
TiDB 的 SQL 层做完 SQL 解析后，会将 SQL 的执行计划转换为对 TiKV API 的实际调用。所以，数据都存储在 TiKV 中。另外，TiKV 中的数据都会自动维护多副本（默认为三副本），天然支持高可用和自动故障转移。
TiFlash
TiFlash 是一类特殊的存储节点。
和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。

命令执行

3.1 系统命令

通过ssh登陆到中控机（已经安装TiUP的机器），使用TiUP client连接 TiDB。

3.2 SQL语句

通过MySQL Client命令行登陆到TiDB Server。在MySQL client中执行的命令，登陆方式如下：

mysql --host 127.0.0.1 --port 4000 -u root

复制

常见错误码

Error Number: 8003
ADMIN CHECK TABLE 命令在遇到行数据跟索引不一致的时候返回该错误，在检查表中数据是否有损坏时常出现。出现该错误时，请向 PingCAP 工程师或通过官方论坛寻求帮助。
Error Number: 8223
检测出数据与索引不一致的错误，如果遇到该报错请向 PingCAP 工程师或通过官方论坛寻求帮助。
Error Number: 8027
表结构版本过期。TiDB 采用在线变更表结构的方法。当 TiDB server 表结构版本落后于整个系统的时，执行 SQL 将遇到该错误。遇到该错误，请检查该 TiDB server 与 PD leader 之间的网络。
Error Number: 8120
获取不到事务的 start tso，请检查 PD Server 状态/监控/日志以及 TiDB Server 与 PD Server 之间的网络。
Error Number: 9001
请求 PD 超时，请检查 PD Server 状态/监控/日志以及 TiDB Server 与 PD Server 之间的网络。
Error Number: 9002
请求 TiKV 超时，请检查 TiKV Server 状态/监控/日志以及 TiDB Server 与 TiKV Server 之间的网络。
Error Number: 9005
某个 Raft Group 不可用，如副本数目不足，出现在 TiKV 比较繁忙或者是 TiKV 节点停机的时候，请检查 TiKV Server 状态/监控/日志。
Error Number: 9003
TiKV 操作繁忙，一般出现在数据库负载比较高时，请检查 TiKV Server 状态/监控/日志。
Error Number: 9012
请求 TiFlash 超时。请检查 TiFlash Server 状态/监控/日志以及 TiDB Server 与 TiFlash Server 之间的网络。
Error Number: 9013
TiFlash 操作繁忙。该错误一般出现在数据库负载比较高时。请检查 TiFlash Server 的状态/监控/日志。

TiDB服务器宕机

场景描述：TiDB服务器宕机
业务影响：多个TiDB无影响，宕机影响SQL执行。
启动条件：
序号	步骤名称	应急处置流程
T1	场景识别	Ping TiDB服务器的ip地址，无法ping通。 ping <ipadress> 检查当前集群状态，TiDB状态显示down tiup cluster dipslay <cluster_name>
T2	现场保护	目录：<deploy_dir>/log 目录下tidb.log日志
T3	操作步骤	检查当前集群状态，TiDB状态显示down tiup cluster dipslay <cluster_name> 启动TiDB节点 tiup cluster start <cluster_name> -N <ipadress>:<port>
T4	验证步骤	再次确认是否正常，检查当前集群状态，TiDB状态显示up tiup cluster dipslay <cluster_name>

PD服务器宕机

场景描述：PD服务器宕机
业务影响： PD服务器宕机
启动条件：
序号	步骤名称	应急处置流程
T1	场景识别	Ping PD服务器的ip地址，无法ping通。 ping <ipadress> 检查当前集群状态，PD状态显示down tiup cluster dipslay <cluster_name> 观察宕机的PD节点是否为leader curl <PD_IP>:<PD_PORT>/pd/api/v1/member
T2	现场保护	目录：<deploy_dir>/log 目录下tidb.log日志
T3	操作步骤	检查当前集群状态，PD状态显示down tiup cluster dipslay <cluster_name> 非leader节点宕机对集群无影响，恢复后可直接启动 tiup cluster start <cluster_name> -N <ipadress>:<port> leader 节点宕机后，PD 需要选举 leader ，在这期间可能会导致集群不可用，最长时间在 10s 内。此时需要确认业务是否受影响，QPS 是否下降。观察监控 TiDB 栏 Failed query OPM 监控面板，确认执行失败的 SQL 语句。等服务器恢复后使用如下命令启动 PD 。 tiup cluster start <cluster_name> -N <ipadress>:<port>
T4	验证步骤	再次确认是否正常，检查当前集群状态，PD状态显示up tiup cluster dipslay <cluster_name>

TiKV服务器宕机

场景描述： TiKV服务器宕机
业务影响： TiKV服务器宕机
启动条件：
序号	步骤名称	应急处置流程
T1	场景识别	Ping TiKV服务器的ip地址，无法ping通。 ping <ipadress> 检查当前集群状态，显示TiKV组件显示Down tiup cluster dipslay <cluster_name>
T2	现场保护	目录：<deploy_dir>/log 目录下tidb.log日志
T3	操作步骤	检查当前集群状态，TiKV状态显示down tiup cluster dipslay <cluster_name> 两台（含）TiKV 服务器的 down 机不会影响集群提供服务的能力。如有 down 机，观察监控 TiDB 栏Failed query OPM 监控面板，确认执行失败的 SQL 语句可用如下命令启动TiKV节点 tiup cluster start <cluster_name> -N <ipadress>:<port>
T4	验证步骤	再次确认是否正常，检查当前集群状态，TiKV状态显示up tiup cluster dipslay <cluster_name>

TiFlash 异常处理办法

8.1 Block schema mismatch

场景描述：Block schema mismatch
业务影响：执行sql语句报错
启动条件：
序号	步骤名称	应急处置流程
T1	场景识别	执行SQL语句的时候报错： other error for mpp stream: DB::Exception: Block schema mismatch in TiRemoteBlockInputStream(ExchangeReceiver): different types: expected Nullable(String), got String.
T2	现场保护	目录：<deploy_dir>/log 目录下tidb.log日志目录：<deploy_dir>/log tiflash目录下所有日志
T3	操作步骤	如果用户环境出现，立刻联系PingCAP工程师。
T4	验证步骤	再次确认SQL执行是否会报错

8.2 3rd argument must be constant

场景描述：3rd argument must be constant
业务影响：执行sql语句报错
启动条件：
序号	步骤名称	应急处置流程
T1	场景识别	执行SQL语句的时候报错： DB::Exception: 3rd arguments of function substringUTF8 must be constants.
T2	现场保护	目录：<deploy_dir>/log 目录下tidb.log日志目录：<deploy_dir>/log tiflash目录下所有日志
T3	操作步骤	如果用户环境出现，立刻联系PingCAP工程师。
T4	验证步骤	再次确认SQL执行是否会报错

8.3 Memory limit (total) exceeded

场景描述：Memory limit (total) exceeded: would use 276.06 GiB
业务影响：执行sql语句报错
启动条件：
序号	步骤名称	应急处置流程
T1	场景识别	执行SQL语句的时候报错： DB::Exception: 3rd arguments of function substringUTF8 must be constants.
T2	现场保护	目录：<deploy_dir>/log 目录下tidb.log日志目录：<deploy_dir>/log tiflash目录下所有日志
T3	操作步骤	TiFlash 内部占用的内存达到配置中预设的限制，可以通过监控 TiFlash Summary 中的 Server/Memory 面板确认。首先观察报表 SQL 是否能够正常执行，然后从 Dashboard 中观察是否是执行了非预期的 SQL：可能是由直接执行底板 SQL 导致（少了若干筛选条件导致 Join 过程中数据膨胀），也可能是自由报表导致。如果是测试过的报表出现此问题，立刻联系产研团队。
T4	验证步骤	再次确认SQL执行是否会报错

误删除恢复场景

drop database 误删除库
truncate table 清空表
drop table 误删除表
delete、update 误删除数据

9.1 drop database 误删除库场景

TiDB 事务的实现采用了 MVCC（多版本并发控制）机制，当更新/删除数据时，不会做真正的数据删除，只会添加一个新版本数据，并以时间戳来区分版本。当然历史数据不会永久保留，超过一定时间的历史数据将会被彻底删除，以减小空间占用，同时避免因历史版本过多引起的性能开销。

TiDB 使用周期性运行的 GC（Garbage Collection，垃圾回收）来进行清理，默认情况下每 10 分钟一次。每次 GC 时，TiDB 会计算一个称为 safe point 的时间戳（默认为上次运行 GC 的时间减去 10 分钟），接下来 TiDB 会在保证在 safe point 之后的快照都能够读取到正确数据的前提下，删除更早的过期数据。

SQL
mysql> select VARIABLE_NAME, VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME like 'tikv_gc_life_time';
+-------------------+----------------+
| VARIABLE_NAME | VARIABLE_VALUE |
+-------------------+----------------+
| tikv_gc_life_time | 10m0s |
+-------------------+----------------+
1 row in set (0.01 sec)

mysql> show databases;
+--------------------+
| Database |
+--------------------+
| INFORMATION_SCHEMA |
| METRICS_SCHEMA |
| PERFORMANCE_SCHEMA |
| bbc |
| employees |
| mysql |
| sbtest |
| test |
+--------------------+
8 rows in set (0.00 sec)

mysql> select now();
+---------------------+
| now() |
+---------------------+
| 2021-10-29 15:38:08 |
+---------------------+
1 row in set (0.00 sec)

mysql> drop database sbtest;
Query OK, 0 rows affected (0.61 sec)

mysql> select count(*) from sbtest.sbtest1;
ERROR 1146 (42S02): Table 'sbtest.sbtest1' doesn't exist
复制

确认删除时间：

删库这种操作权限一般只有管理员才会有，当然也不排除有部分开发人员申请了超级权限，如果这个事情发生了那么我们肯定是希望能精确找到删库的时间点这样可以减少数据丢失,好在Tidb记录了所以DDL操作，可以通过 admin show ddl jobs; 查看，找到删库的具体时间点。

SQL
mysql> admin show ddl jobs;
+--------+---------+------------+-------------------------------+--------------+-----------+----------+-----------+---------------------+---------------------+--------+
| JOB_ID | DB_NAME | TABLE_NAME | JOB_TYPE | SCHEMA_STATE | SCHEMA_ID | TABLE_ID | ROW_COUNT | START_TIME | END_TIME | STATE |
+--------+---------+------------+-------------------------------+--------------+-----------+----------+-----------+---------------------+---------------------+--------+
| 196 | sbtest | | drop schema | none |        84 | 0 |         0 | 2021-10-29 15:39:03 | 2021-10-29 15:39:03 | synced |
| 195 | sbtest | sbtest1 | create table | public |        84 | 194 |         0 | 2021-10-28 10:13:17 | 2021-10-28 10:13:17 | synced |
| 193 | sbtest | sbtest1 | drop table | none |        84 | 110 |         0 | 2021-10-28 10:11:24 | 2021-10-28 10:11:24 | synced |
| 192 | sbtest | sbtest1 | rename table | public |        84 | 110 |         0 | 2021-10-28 09:51:04 | 2021-10-28 09:51:04 | synced |
| 191 | sbtest | sbtest1 | drop table | none |        84 | 187 |         0 | 2021-10-28 09:50:53 | 2021-10-28 09:50:53 | synced |
| 190 | sbtest | test1 | recover table | public |        84 | 110 |         0 | 2021-10-28 09:50:04 | 2021-10-28 09:50:05 | synced |
| 189 | sbtest | sbtest1 | update tiflash replica status | public |        84 | 187 |         0 | 2021-10-28 09:49:49 | 2021-10-28 09:49:49 | synced |
| 188 | sbtest | sbtest1 | truncate table | public |        84 | 110 |         0 | 2021-10-28 09:49:43 | 2021-10-28 09:49:43 | synced |
| 186 | bbc | | create schema | public |       185 | 0 |         0 | 2021-10-27 17:37:53 | 2021-10-27 17:37:53 | synced |
| 184 | bba | | drop schema | none |       180 | 0 |         0 | 2021-10-27 17:35:02 | 2021-10-27 17:35:02 | synced |
+--------+---------+------------+-------------------------------+--------------+-----------+----------+-----------+---------------------+---------------------+--------+
10 rows in set (0.02 sec)
复制

确认数据的有效性：

通过上面方法我们可以确认drop 库的操作是在 2021-10-29 15:39:03 分，那么我们需要这个时间点的前几秒的快照应该就有被我们删除的库,通过 set @@tidb_snapshot="xx-xx-xx xx:xx:xx"; 设置当前session查询该历史快照数据。

SQL
mysql> set @@tidb_snapshot="2021-10-29 15:39:01";
Query OK, 0 rows affected (0.02 sec)


mysql> select count(*) from sbtest.sbtest1;
+----------+
| count(*) |
+----------+
| 999995 |
+----------+
1 row in set (0.52 sec)
复制

确认数据有效之后，我们可以使用dumpling指定 tidb_snapshot 把数据库导出来。

SQL
./dumpling -u root -P 4000 -h 172.16.7.122 -o /tmp/test1 -t 32 -F 64MiB -B sbtest --snapshot "2021-10-29 15:39:02"
复制

导出来的数据，我们在使用./tidb-lightning进行恢复，编辑tidb-lightning_sbtest.yoml文件。

Makefile
[lightning]
#日志
level = "info"
file = "tidb-lightning_sbtest.log"

region-concurrency = 16

[mydumper]
数据源目录
data-source-dir = "/tmp/test1"

[tidb]
目标集群的信息。tidb-server 的地址，填一个即可
host = "172.16.7.122"
port = 4000
user = "root"
password = ""

[tikv-importer]
backend = "tidb"
复制

注意：

如果选用 Local-backend 来导入数据，导入期间集群无法提供正常的服务，速度更快，适用于导入大量的数据（TB 以上级别）。
如果选用 TiDB-backend 来导入数据，导入期间集群可以正常提供服务，但相对导入速度较慢。二者的具体差别参见 TiDB Lightning Backend。

验证数据库和表已经恢复：

SQL
mysql> use sbtest;
Database changed
mysql> show tables;
+------------------+
| Tables_in_sbtest |
+------------------+
| sbtest1 |
| sbtest10 |
| sbtest2 |
| sbtest3 |
| sbtest4 |
| sbtest5 |
| sbtest6 |
| sbtest7 |
| sbtest8 |
| sbtest9 |
+------------------+
10 rows in set (0.00 sec)

mysql> select count(1) from sbtest1;
+----------+
| count(1) |
+----------+
| 999995 |
+----------+
1 row in set (0.65 sec)
复制

9.2 truncate table 清空表

在 TiDB 4.0 中，引入了 FLASHBACK TABLE 语法，其功能是在 Garbage Collection (GC) life time 时间内，可以用 FLASHBACK TABLE 语句来恢复被 DROP 或 TRUNCATE 删除的表以及数据。

可以使用系统变量 tidb_gc_life_time 配置数据的历史版本的保留时间（默认值是 10m0s）。可以使用以下 SQL 语句查询当前的 safePoint，即 GC 已经清理到的时间点：

SQL
mysql> SELECT * FROM mysql.tidb WHERE variable_name = 'tikv_gc_safe_point' \G
*************************** 1. row ***************************
VARIABLE_NAME: tikv_gc_safe_point
VARIABLE_VALUE: 20211027-17:11:12 +0800
COMMENT: All versions after safe point can be accessed. (DO NOT EDIT)
1 row in set (0.00 sec)
复制

只要被 DROP 或 TRUNCATE 删除的表是在 tikv_gc_safe_point 时间之后，都能用 FLASHBACK TABLE 语法来恢复。

SQL
mysql> select count(1) from sbtest1;
+----------+
| count(1) |
+----------+
| 1000000 |
+----------+
1 row in set (0.05 sec)

mysql> truncate table sbtest1;
Query OK, 0 rows affected (0.42 sec)

mysql> flashback table sbtest1 to test1;
Query OK, 0 rows affected (1.80 sec)

mysql> select count(1) from sbtest1;
+----------+
| count(1) |
+----------+
| 0 |
+----------+
1 row in set (0.01 sec)

mysql> select count(1) from test1;
+----------+
| count(1) |
+----------+
| 1000000 |
+----------+
1 row in set (0.05 sec)

mysql> drop table sbtest1;
Query OK, 0 rows affected (0.70 sec)

mysql> alter table test1 rename to sbtest1;
Query OK, 0 rows affected (0.30 sec)
复制

9.3 drop table 误删除表

恢复的原理同Truncate table。只要被 DROP 或 TRUNCATE 删除的表是在 tikv_gc_safe_point 时间之后，都能用 FLASHBACK TABLE 语法来恢复。

SQL
mysql> drop table sbtest1;
Query OK, 0 rows affected (0.59 sec)

mysql> FLASHBACK TABLE sbtest1;
Query OK, 0 rows affected (1.68 sec)

mysql> select count(1) from sbtest1;
+----------+
| count(1) |
+----------+
| 1000000 |
+----------+
1 row in set (0.03 sec)
复制

9.4 delete、update 误删除数据

原理和drop database相同。唯一不同的是需要确认操作时间，操作时间的确认略微麻烦。

确认操作时间：

对于DML的误操作,如图Tidb集群没开启全日志，基本没办法从集群层面确认误操作时间了，需要从误操作发起端介入排查了。如果是管理员命令行误操作，可以通过堡垒机的操作记录去人；如果是程序bug可以通过排查程序的日志确认执行误操作的时间

确认数据的有效性：

通过上面方法我们可以确认误操作是在 2021-10-28 10:31:26 ，那么我们需要这个时间点的前几秒的快照应该就有被我们删除的库,通过set @@tidb_snapshot=“xx-xx-xx xx:xx:xx”; 设置当前session查询该历史快照数据

SQL
mysql> select VARIABLE_NAME, VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME like 'tikv_gc_life_time';
+-------------------+----------------+
| VARIABLE_NAME | VARIABLE_VALUE |
+-------------------+----------------+
| tikv_gc_life_time | 10m0s |
+-------------------+----------------+
1 row in set (0.01 sec)


mysql> select id,k from sbtest1 where id in (1,2,3,4,5,6,7);
+----+--------+
| id | k |
+----+--------+
|  1 | 504616 |
| 2 | 503857 |
|  3 | 459563 |
| 4 | 499299 |
|  5 | 350856 |
| 6 | 498938 |
|  7 | 499050 |
+----+--------+
7 rows in set (0.00 sec)

mysql> select now();
+---------------------+
| now() |
+---------------------+
| 2021-10-28 10:31:26 |
+---------------------+
1 row in set (0.00 sec)

mysql> delete from sbtest1 where id in (1,2,3,4,5);
Query OK, 5 rows affected (0.03 sec)

mysql> select id,k from sbtest1 where id in (1,2,3,4,5,6,7);
+----+--------+
| id | k |
+----+--------+
|  6 | 498938 |
| 7 | 499050 |
+----+--------+
2 rows in set (0.00 sec)

mysql> set@@tidb_snapshot="2021-10-28 10:31:26";
Query OK, 0 rows affected (0.03 sec)

mysql> select id,k from sbtest1 where id in (1,2,3,4,5,6,7);
+----+--------+
| id | k |
+----+--------+
| 1 | 504616 |
|  2 | 503857 |
| 3 | 459563 |
|  4 | 499299 |
| 5 | 350856 |
|  6 | 498938 |
| 7 | 499050 |
+----+--------+
7 rows in set (0.00 sec)
复制

在实际的工作中，上面步骤确认操作时间可能并不是那么容易，所以我们可能需要不断的通过从大到小范围的set @@tidb_snapshot=“xx-xx-xx xx:xx:xx”; 来尝试，最终确认一个最靠近的时间点。

备份数据：

通过dumpling把上面确定的时间点的快照数据备份出来。

Apache
dumpling -h 172.21.xx.xx -P 4000 -uroot -p xxx -t 32 -F 64MiB -B xxx_ods -T xxx_ods.xxx_comment --snapshot "2020-11-17 09:55:00" -o ./da

复制

TiKV或TiDB服务器或磁盘不可用处理

服务器或磁盘不可用，节点实例无法正常运行，为防止对现有集群造成影响，需踢掉相关节点。

10.1 检查集群状态

tiup cluster display tidb-test
复制

10.2 检查服务器日志、tidb日志、tikv日志、pd日志，确定故障信息

tail -1000 /var/log/messages
tail -1000 <deploy_dir>/log
复制

10.3 如故障节点为tikv节点，通过grafana监控各个节点运行状态，包括pd节点 region health状态，leader分布，region ops，region 分数，leader分数等

10.4 对故障节点进行缩容操作

tiup cluster scale-in tidb-test -N XXX.XXX.XX.15:20160
复制

若操作系统无法访问或kv节点为3节点，可选择执行强制下线，3节点kv无法彻底删除，建议先扩容存活kv节点为3或以上，在缩容故障kv节点，可在原节点上选择其他端口扩容。

tiup cluster scale-in tidb-test -N XXX.XXX.XX.15:20160 --force
复制

缩容后tikv状态是offline，直接扩容会失败，等待region-count变为0后，tikv状态变为tombstone，然后可以正常扩容，此时store查看不到tombstone节点，而store+id可以查看到，如果想彻底删除，可在pd-ctl 执行store remove-tombstone。

服务器或磁盘修复后根据现有集群配置编写扩容配置文件将故障节点重新加入集群：

tiup cluster edit-config tidb-test
vi scale-out-tikv.yaml
复制

10.5 执行扩容操作

tiup cluster scale-out tidb-test scale-out-tikv.yaml -uroot -p
复制

扩容完毕后通过grafana检查各个集群状态，包括pd节点 region health状态，leader分布，region ops，region 分数，leader分数等。

9.1.12.31:3000
复制

TiKV 启动报错：duplicated store address

启动参数中的地址已经被其他的 TiKV 注册在 PD 集群中了。造成该错误的常见情况：TiKV--data-dir 指定的路径下没有数据文件夹（删除或移动后没有更新 --data-dir），用之前参数重新启动该 TiKV。请尝试用 pd-ctl 的 store delete 功能，删除之前的 store，然后重新启动 TiKV 即可。

tiup ctl:<cluster-version> pd -u http://<pd_ip>:<pd_port> [-i]
查看store
store
删除指定store
store delete 1
删除所有tombstone
store remove-tombstone
复制

drainer同步异常问题处理

日常巡检发现grafana 显示一个drainer 状态异常,根据drainer日志定位至如下信息:

11.1 报错信息

["add ddl item to syncer, you can add this commit ts to `ignore-txn-commit-ts` to skip this ddl if needed"] 
[sql="create index idx_usercode_updatedate_realpay on mesorderuser.mes_order_infos(user_code,update_date,real_pay)"] 
["commit ts"=428853636475125794]
复制

11.2 原因分析

源表字段类型是varchar，mysql字段类型是text，created index 时支持不了这么大字段，导致报错。

11.3 处理方案

以下为跳过该ddl具体步骤：

该信息代表该DDL tso

428853636475125794

配置集群在对应drainer配置参数下，添加以下内容：

config:
syncer.ignore-txn-commit-ts: [428853636475125794]
复制

reload 该组件,如果edit-config chongqi失败,需要手工编辑该文件:

/home/tidb/.tiup/storage/cluster/clusters/gsc-tczy/meta.yaml
复制

然后再reload:

tiup cluster reload gsc-tczy -N 9.1.12.33:8349  -R drainer
复制

END

本文作者：白炀斌(上海新炬中北团队）

本文来源：“IT那活儿”公众号

mysql集群数据库集群 tidb sql优化 mysql

文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

TiDB 数据库故障应急操作手册

本文作者：白炀斌(上海新炬中北团队）

本文来源：“IT那活儿”公众号

评论

相关阅读