作者： 东北大胖子原文来源：https://tidb.net/blog/c6e3a445

不定期更新，记录一些小知识，欢迎指正，本帖尽量使用文字描述，相关图片尽量粘贴，方便大家搜索~

Mysql 向 TiDB 迁移的方案讨论 数据迁移和数据同步

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。 【TiDB 版本】： v3.0.7, dm-v1.0.2 【问题描述】： 我有一个这样的迁移规划，但最后一部分不知道是否可行，希望能给我一点建议和帮助。 打开 DM 全量 + 增量同步数据到 TiDB 线上读流量切换到 TiDB，进行观察 没有问题后写流量切换到 TiDB，同时关闭 DM。 第三步中可能部分服务在写 Mysql 通…

答： DM + 完全业务双写 该方案是在应用端实现双写，并且在指定时间窗口上线双写功能，运行稳定后，可评估写流量切换到 TiDB。

1）使用 DM 完成业务数据的全量和增量同步

2）寻找时间窗口将线上以及 DM 的流量同时切断，并确认数据是否完全同步

3）应用程序端上线双写功能

4）DM 不再作为增量同步的介质，评估后可计划下线

5）应用端正常写入数据到 MySQL 以及 TiDB

6）评估后，写流量切换至 TiDB

tikv log 日志保存数量限制怎么限制 TiDB 系统架构与原理

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。 【TiDB 版本】：v3.0.8 【问题描述】：tikv 服务所在服务器的 tikv log 一直增加，旧日志并未减少

答：

如果使用 tidb-ansible 部署，默认编辑 conf/tikv.yml 模板文件，修改相关的参数并执行滚动重启生效就可以了，包括 info-log-max-size、 info-log-roll-time 和 info-log-keep-log-file-num info-log-keep-log-file-num：这个参数是 rocksdb 的日志保留策略，tikv 日志目前还没有相关的参数，需要定期清理一下

rocksdb 的日志位于 {deploy_dir}/data 下的 raft 和 db 目录下，文件名为 LOG 和 LOG.old.xxx； tikv 的日志目前有 log-rotation-timespan，默认 24h 切换一次，对于历史日志需要通过定时任务清理下。

上游 mysql ddl，dm 同步延迟近 7 个小时 数据迁移和数据同步

@qizheng-PingCAP 谢谢周末一直在支持 +1 此问题已经解决，问题是在配置 task 配置文件时没有加 online-ddl-scheme: “pt” 这个过滤条件，导致最终上游 mysql 大表 ddl 操作卡住。 文件添加位置： [image] 因为我这是中途加入这个参数，所以已经有部分操作不可逆了，只能选择跳过卡住的 binlog 位点。 在跳过 binlog 这个操作上使用 sql-ski…

答：

DM 增量同步到 TiDB 太慢了

online-ddl-scheme: ‘pt’

这里面正常上游执行 pt-osc ，dm 会跳过相关的拷贝表操作，但是不设置这个参数，dm 还会处理

上游几千万的表执行这个操作，产生了大量的 binlog 需要消费

但是 rename 那里会报错，需要处理下, 因为 tidb 不支持一个语句同时 rename 两个

关于 TIKV 缩容下线的一些细节疑问 数据迁移和数据同步

知道了，我选监控的时间段选择了，最近一小时，所以显示了，老的数据。 但是。 [image] 在 tidb-cluster-pd 视图中，下线成功，还显示 3 个 ，Tombstone 这个地方的显示是正常的吗？

答：

这个存在 PD 的 etcd 里面的数据，如果没有人为干预，这个是一直存在的。

3.0.5 使用 pd-ctl stores remove-tombstone 清理

从 3.0.8 滚动升级至 3.0.10，发现 empty-regin-count 突然增加很多，什么原因？有没有办法 Merge？ TiDB 系统架构与原理

看文档上说的是 “如果 TiKV 不与 TiDB 集群配合运行，建议配置为 ‘default’” 这个怎么理解？ 我们现在是 TIKV 和 TiDB 都在使用的，如果配置为’default‘，有没有什么影响？ 需要同时设置 split-region-on-table: false 吗？ 我的目的是合并空 Region，合并完以后，是否可以把 ‘namespace-classfier’ 改回到 …

答：

空 region

merge 默认情况下表之间是不会相互 merge 的，如果要开启，更改 PD 配置文件，加上 namespace-classifier = “default” (默认是 table)， 注：这个参数不能通过 pd-ctl 动态更改。

同时，需要将 tikv 的按 table 分裂配置关闭：

[coprocessor]

split-region-on-table = false

操作：

1. PD 参数 namespace-classifier = “default”

2. TiKV 参数 split-region-on-table: false

3. pd-ctl -i -u http://172.16.5.83:62479 config set max-merge-region-size 16 M config set max-merge-region-keys 50000

4. ansible-playbook rolling_update.yml -t=pd,tikv

mydumper runs with error: fork/exec bin/mydumper: argument list too long 数据迁移和数据同步

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。 【TiDB 版本】：3.0 【问题描述】：使用 dm 迁移数据时，在 dump 数据时出错。问题原因可能是上游 mysql 数据中有 3700 多张表，在 dm 启动 task 时，自动生成 table-list 的参数太长了。 是否有什么方式可以通过指定正则表达式的方式来状态这个参数？ 若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务…

答：

如果自动生成的 table-list 参数太长。

你可以为 mydumper 在 extra-args 手动用原始的 -x 来指定正则试试（[https://pingcap.com/docs-cn/stable/reference/tools/data-migration/configure/task-configuration-file-full/# 完整配置文件示例 2]

通过 information_schema.processlist 表和 information_schema.cluster_processlist 表查询连接，同一个连接，processlist 表中 txnstart 为空，cluster_processlist 表中 txnstart 字段是有值的，这个是正常的么？

版本:v4.0.0-beta-412-g6e2cbc025

答：这个只是对当前 select processlist / cluster processlist 本身的语句才有这个问题， 因为 select processlist 是查 memtable 那个算子不需要起事务，所以空，而 cluster 那个用的用的正常 tablereader 上层没感知下面表是真实表还是虚拟表都会启动事务所以有值…只有查 processlist/cluster process 本身才有这个问题

经测试符合预期：

调大 region size 的风险

答：

（1）热点调度不及时

（2）snapshot io 压力

（3）cop scan 时间长不利于并发

业务调研：分布式存储项目计划测试悲观锁，建议 v3.0.9 以上版本

sql 中出现 order by limit 1，索引选择可能走 order by 后面的索引

答：执行计划不稳定，limit 老问题，无论 limit 多少

解决方案：

1. 绑定 hints

2. force index

3.0.13 预计修复执行带视图的 sql 连接直接断开

答：在 SQL 里把 View 写在 PartitionTable 前面，例如之前是 select * from partition_table, view where …; 改成 select * from view, parition_table where …。应该可以规避掉这个问题，但还是建议升级 TiDB 解决。

tidb2.1 升级 3.0 问题 安装部署与监控

+1 推荐下《TiDB in Action》：https://book.tidb.io/session1/chapter1/tidb-architecture.html

答：

2.x 升级 3.x max-index-length 问题

升级时调大 max-index-length

2020 年 4 月 9 日

目前 gc 是无法手动的

drainer.toml 更新后需要重启 drainer 进程

tiKV 缩容 TiDB 运维手册

按照你提供的建议，我这边试了一下，发现没有什么变化，还是老样子，我的一个很大的疑问是，所有的节点的网络流量没有一个超过 10MiB 的，这个不合理，无论我怎么调整参数，网络流量，CPU 使用都保证稳定，不会有太多变化，我怀疑是否 tiKV 底层针对 region 的 snapshot 有单独的处理队列（或者线程），而这个队列限制了这种迁移的速率。 如果调度的限制成倍的增大，但是监控上看没有引起什么变化的话，我有理由…

1 pd-ctl -u {pd_ip}:{pd_port} store limit {storeid} 32 (storeid 应该为不需要下线的节点的 storeid , 可以通过 pd-ctl -u {pd_ip}:{pd_port} store 查询)

2 region-schedule-limit 以及 replica-schedule-limit 调整到 64

3 注意线上节点的压力。如果压力升高的话可以把参数调整回来。

Mydumper 和 dm 需要 reload 权限，但由于各种原因不能赋权，可以指定 dm 指定 nolock 参数

loader 导入中断造成数据一致性问题 数据迁移和数据同步

这边 tidb_loader.checkpoint 的更新时机是跟导入的 SQL 同一个事务内执行的。所以不会出现你说的问题。

答：

loader 导入过程中如果需要 断电宕机等因素导致 loader 终止，再次执行 loader 即可，因为：tidb_loader.checkpoint 的更新时机是跟导入的 SQL 同一个事务内执行的

2020 年 4 月 10 日

tidb 数据同步到 hadoop：可以用 kettle、sqoop 等用于异构数据源之间数据同步，增量同步到其他异构数据源可以开启 tidb binlog 同步到 kafka，也可以 select … into outfile 导出为 csv 格式的文本

建立索引客户端不立即返回 应用适配和性能优化

我这边不会立马返回成功呢，要完全建完索引，才会返回成功，建了 5 个索引，都要 1 个多小时才能建完，返回 sucess 同时 admin show ddl job 也会建完

添加索引不会立马返回成功是符合预期的，刚才确认了下 4.0 以及之前的版本都是这个行为，执行操作的命令返回 sucess，表示建索引完成。

慢查询日志里出现一条很早的 txnStartTS TiDB 系统架构与原理

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。 【TiDB 版本】：TiDB-v3.1.0-rc 【问题描述】：查看 tidb 日志时，发现很多报错日志，有一个很早的 txnStartTS [1586491363(1)].png”) [1586490993] 若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

txnStartTS 转成 北京时间

[tidb\@node5169 qihang.li]$ ./tools/bin/pd-ctl -u http://172.16.5.169:42379 tso 415888143313272835

system: 2020-04-10 10:56:03.103 +0800 CST

logic: 3

tiup 升级连接丢失 安装部署与监控

目前无缝升级需要 LB 和应用配合实现，在滚动升级前将要操作的 TiDB 节点从 LB 上摘除，等会话执行完成后再对该 TiDB 做升级操作，升级完成后将 TiDB 节点添加回 LB，并确认有流量进来。

答：

基本达到线上升级标准。

目前无缝升级需要 LB 和应用配合实现，在滚动升级前将要操作的 TiDB 节点从 LB 上摘除，等会话执行完成后再对该 TiDB 做升级操作，升级完成后将 TiDB 节点添加回 LB，并确认有流量进来。

一台 TiKV 机器宕机后连接 TiDB 特别慢 / 查询也特别慢 TiDB 系统架构与原理

TIDB 3.0.2 以及以后的版本修复了一系列 TiDB 与 TiKV 之间网络连接出现异常的 bug，包括但不限于： region cache 相关：https://github.com/pingcap/tidb/pull/11344 tikvclient 相关：https://github.com/pingcap/tidb/pull/11531 https://github.com/p…

问题：一台 TiKV 机器挂掉后，连接 TiDB 要 hang 10 几秒，查询 1000 多条记录的表都没有返回结果

报错：

[2020/04/09 15:16:00.830 +08:00] [ERROR] [client.go:197] [“batchRecvLoop error when receive”] [target=down_tikv_ip:20164] [error=“rpc error: code = Unavailable desc = transport is closing”] [stack=“github.com/pingcap/tidb/store/tikv.(*batchCommandsClient).batchRecvLoop\“n\“t/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/store/tikv/client.go:197”]

[2020/04/09 15:16:01.854 +08:00] [ERROR] [client.go:169] [“batchRecvLoop re-create streaming fail”] [target=down_tikv_ip:20164] [error=“rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = “transport: Error while dialing dial tcp down_tikv_ip:20164: i/o timeout””] [stack=“github.com/pingcap/tidb/store/tikv.(*batchCommandsClient).reCreateStreamingClient\“n\“t/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/store/tikv/client.go:169\“ngithub.com/pingcap/tidb/store/tikv.(*batchCommandsClient).batchRecvLoop\“n\“t/home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/store/tikv/client.go:203”]

答：

TIDB 3.0.2 以及以后的版本修复了一系列 TiDB 与 TiKV 之间网络连接出现异常的 bug，包括但不限于：

1. region cache 相关：https://github.com/pingcap/tidb/pull/11344 2
   

2. tikvclient 相关：https://github.com/pingcap/tidb/pull/11531
   

3. https://github.com/pingcap/tidb/pull/11370
   

建议可以的话升级到 3.0 的最新 release 版本再进行观察。

2020 年 4 月 11 日

github.com/pingcap/tidb

[](https://github.com/kolbe)

Issue: tidb-server refuses to start if no pump is registered with pd

opened by kolbe on 2019-04-23

Bug ReportPlease answer these questions before submitting your issue. Thanks!
What did you do?When trying to restart all TiDB cluster components simultaneously,...

如果 enable-binlog 为真，则 pump 实例必须可用。

如果我们使用配置 TiD​​B enable-binlog = true，建议的启动顺序为：PD -> TiKV -> Pump -> TiDB -> Drainer

2020 年 4 月 12 日

选择存储引擎

EXPLAIN SELECT /*+ read_from_storage(tikv[t]) */ count(SUBSTR(name FROM 1 FOR 3) )FROM t;

SELECT /*+ read_from_storage(tiflash[t]) */ count(SUBSTR(name FROM 1 FOR 3) )FROM t;

2020 年 4 月 14 日 10:15:30

tidb-server 对于 sql 的内存占用限制 应用适配和性能优化

Hi @rongyilong-PingCAP，TiDB 4.0 RC 版本已经发布了，可以试试。我们在这个版本中默认支持了部分算子（比如 Hash Join）的中间结果落盘，这时候可以在不杀掉 SQL，也不过多使用系统内存的情况下执行完该 SQL 了。不过因为中间结果落盘了，执行性能会有所损失。

答：

1. mem-quota-query 可以根据目前服务器的内存进行设置

2. 该参数也需要和 oom-action=cancel 配合使用，避免 tidb server 出现 oom。

TiDB 4.0 RC 版本已经发布了，可以试试。我们在这个版本中默认支持了部分算子（比如 Hash Join）的中间结果落盘，这时候可以在不杀掉 SQL，也不过多使用系统内存的情况下执行完该 SQL 了。不过因为中间结果落盘了，执行性能会有所损失。

SQL 执行出现 reading initial communication packet’, system error: 0 “Internal error/check 应用适配和性能优化

你好， 抱歉，暂时可从以下链接查看，我们会持续更新官网： https://github.com/pingcap/tidb/blob/c02e92c02f31d67da0c7c2e02031c920eb264313/config/config.toml.example#L234https://pingcap.com/docs/dev/reference/configuration/tidb-se…

一个事务中条目大小的限制（以字节为单位）。

如果使用 TiKV 作为存储，则该条目表示键 / 值对。

注意：如果启用 binlog，则此值应小于 104857600（10M），因为这是 Pumper 可以处理的最大大小。

如果未启用 binlog，则该值应小于 10737418240（10G）。

txn-total-size-limit = 104857600

【SOP 系列 01】 Release-2.1 升级到 Release-3.0 线上集群升级 TiDB 运维手册

01 Release-2.1 升级到 Release-3.0 线上集群升级 李仲舒 2020 年 2 月 10 日 一、背景 / 目的 分布式数据库集群运维过程有一定的复杂性和繁琐性，3.0 版本是目前被广泛使用的版本，相比 2.1 有大幅度增加性能，以及很多新增的功能和特性，整体架构、配置也有较大的优化。该篇根据广大用户的升级经验，尽可能将 Release-2.1 升级到 Release-…

答：

关于新增的 excessive_rolling_update.yml 和 rolling_update.yml 的关系：

如果部署采用 （默认）systemd 模式 ，使用 excessive_rolling_update.yml 来进行滚动升级操作，原因是涉及到 PD 滚动升级 1（以 v3.0.9 为例）的代码变动，该脚本仅本次升级使用一次，以后再次升级到后续版本均由 rolling_update.yml 来完成。

2020 年 4 月 15 日

DM load 报错 数据迁移和数据同步

[%E5%9B%BE%E7%89%87]

context canceled 是被中斷的意思，可能是 Ctrl+C 也可能是別的錯誤

如何让某一列的排序规则为大小写不敏感 应用适配和性能优化

【系统版本 & kernel 版本】 CentOS Linux release 7.6.1810 (Core) 4.20.10-1.el7.elrepo.x86_64 【TiDB 版本】 3.0.5 【问题描述（我做了什么）】 TiDB 列的排序规则 [image] 已有的数据 [image] 执行的 sql 语句 [image] 【我期望的】 MySQL 列的排序规则 […

new_collations_enabled_on_first_bootstrap

• 用于开启新的 collation 支持

• 默认值：false

• 注意：该配置项只有在初次初始化集群时生效，初始化集群后，无法通过更改该配置项打开或关闭新的 collation 框架；4.0 版本之前的 TiDB 集群升级到 4.0 时，由于集群已经初始化过，该参数无论如何配置，都作为 false 处理。