不定期更新,记录一些小知识

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

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

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

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

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

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

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

6)评估后,写流量切换至 TiDB

答:

如果使用 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 切换一次,对于历史日志需要通过定时任务清理下。

答:

DM 增量同步到 TiDB 太慢了

online-ddl-scheme: ‘pt’

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

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

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

答:

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

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

答:

空 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

答:

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

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

image

通过 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 本身才有这个问题

经测试符合预期:

image

调大 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 解决。

答:

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

升级时调大 max-index-length

2020年4月9日

目前 gc 是无法手动的

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

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 导入过程中如果需要 断电宕机等因素导致 loader 终止,再次执行 loader 即可,因为:tidb_loader.checkpoint 的更新时机是跟导入的 SQL 同一个事务内执行的

2020年4月10日

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

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

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

答:

基本达到线上升级标准。

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

问题:一台 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日

如果 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

答:

  1. mem-quota-query 可以根据目前服务器的内存进行设置
  2. 该参数也需要和 oom-action=cancel 配合使用,避免 tidb server 出现 oom。

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

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

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

注意:如果启用binlog,则此值应小于104857600(10M),因为这是Pumper可以处理的最大大小。

如果未启用binlog,则该值应小于10737418240(10G)。

txn-total-size-limit = 104857600

答:

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

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

2020年4月15日

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

new_collations_enabled_on_first_bootstrap

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

1

使用 tiup cluster import 将 ansible 转成 tiup 方式管理,为了防止 ansible 切换到 tiup 之后,tiup 和 ansible 交叉使用可能带来不可预期的行为,所以 ansible 迁移到 tiup 的过程中,ansible 的所有内容被备份到 tiup 的元信息目录了,并未删除。

2

答: 关于 dm 延迟,由于后台 Sync 单元并不会实时刷新保存点,synced 为 “false“ 并不一定代表发生了同步延迟。

3

答:

task 合并,详细请看链接,这边简而言之,原则就是使用更小的 checkpoint 点位,通过 safe-mode 为 true 来完成 task 任务合并,待点位比合并之前最大点位 大,将 safe-mode 设置为 false ,结束 replace into 操作。

4

答:

mydumper 设置了 -r 选项之后,mydumper 会忽略 --chunk-filesize 选项。

TiDB 对于没有主键或者主键为非 int 类型的表,会生成隐藏列 _tidb_rowid ,所以对于该类表,使用 -r 选项会更优效果。

5

答:

tidb 目前没有连接数没有上限。

tidb 有个启动参数是 token-limit 是 TiDB 中同时允许运行的 Session 数量,默认 1000,需要可自行修改,用于流量控制

6

答:

raft log apply 慢导致 tidb 写入慢排查思路:

image

  1. 监控发现 raft apply log 和 append log 以及 apply log 的 Duration 比较高,判断可能是磁盘负载比较高

可以从overview - system info - io until 印证下

这点可以通过 ssd 或者 扩容 tikv 增加 tikv 实例的办法来增加在集群的读写能力

  1. append log 表示写 raft log 的耗时,延迟过高通常是由于写盘慢了

可以检查 RocksDB - raft 的 WAL Sync Duration max 值来确认。

验证,确实很慢(disk latency 的延迟,通常应该在几十到几百 μs):

image

  1. 如果 Thread CPU - raftstore cpu(3.0 版本默认线程数为 2 )没有瓶颈(超过 160%)的话,可能是磁盘本身的延迟比较高

image

PS

  1. 关于云盘的点:

普通 SSD 盘通常是多块磁盘组成的虚拟云盘,在读写延迟上可能比本地普通磁盘要高;对于盘的性能请用 fio 命令进行基准测试,包括 iops 和读写延迟等指标,同样规格的机器由于后端硬件的差异,也可能存在误差,以实测结果为准,如与标称指标不符,可以向云厂商反馈问题;对延迟有要求的业务,TiDB 集群建议部署在本地 nvme 盘。

  1. 案例(2020-2月数据):

根据腾讯云上现有用户的生产环境部署经验,建议 TiKV 选择本地 SSD 的高 IO 型主机,如 IT3.4XLARGE64(高 IO 型 IT3,16 核 64GB,单盘 3.7TB)或者 I2.2XLARGE32(高 IO 型 I2,8 核 32GB,单盘最大 500GB)

7

答:

慢日志中无慢日志,但是监控中出现慢语句

  1. 请检查慢查询阈值 300ms 是否调大过;
  2. slow_query 表是对当前慢查询日志的解析,请检查监控这段时间的慢查询日志文件是否包含慢查询记录;
  3. 各 tidb server 的慢查询是分别记录的,请检查各个 tidb 节点是否都没有慢查询日志

8

答:

关于 tidb 各组件日志

  1. 常规的日志文件包括各个组件的服务日志如 tidb.log,以及错误日志如 tidb_stderr.log
  2. tidb 还包括慢查询日志 tidb_slow_query.log
  3. tikv 除了 tikv.log 和 tikv_stderr.log,还包括 rocksdb 的日志,位于 {deploy_dir}/data 下的 raft 和 db 目录下,文件名为 LOG 和 LOG.old.xxx,目前 tikv 没有参数控制日志的切换和保留期间,需要注意定期清理历史日志文件,避免占用过大空间

9

答:

关于 tidb 事务限制

  • 单个事务包含的 sql 语句不超过 5000 条(默认)
  • 单行数据不大于 6M
  • 总行数*(1 + 索引个数) < 30W
  • 一次性提交的全部数据小于 100M

解决办法

  1. SQL 数量的限制可以通过参数修改(参考 https://pingcap.com/docs-cn/stable/reference/configuration/tidb-server/configuration-file/#stmt-count-limit) 10
  2. (遇到这个问题基本就是鸽了,很少有遇到的,可以通过对一行数据量优化)单行数据不大于 6MB,出于性能的考虑,暂时不会放开;
  3. 默认单个事务 sql 条数 5000 可通过stmt-count-limit 进行配置,滚动 tidb 即可。
  4. 其他限制目前版本无法关掉,4.0 版本会支持大事务。

10

问题:2.0 升级 3.0GA 升级 3.0.7 出现 tidb cpu 持续升高。

答:

解决办法1:尝试关闭 feedback 可以通过设置下述参数值为 0.0

image

12

tiup 如果 topo 中出现 new_collations_enabled_on_first_bootstrap = “new” (此为错误配置,正确配置需要去掉双引号)等错误配置, v0.4.8 之前检测不出,deploy 部署没有问题,但是在 start 阶段会出现以下报错:

tidb 172.16.5.169:34000 failed to start: timed out waiting for port 34000 to be started after 1m0s

Error: failed to start: failed to start tidb: tidb 172.16.5.169:34000 failed to start: timed out waiting for port 34000 to be started after 1m0s: timed out waiting for port 34000 to be started after 1m0s

image

12

答:

关于 region merge 操作:

  1. 在大量删除数据后,会产生空 region ,在 2.1 版本 region merge 默认没有开启,从 2.1 升级至 3.0 (3.0 默认开启),需要手动开启
  2. 开启 region merge 后,可以看下 pd --> Cluster --> region health --> empty region,查看 region merge 的情况,检查 empty region 是否减少。

对系统的影响:

  1. 原则上会有 region checker 会对现存的 region 进行检查,查询是否有符合 merge 条件的 region,会消耗极少资源
  2. 开启 region merge 是为了降低海量 region 带来的性能下降

涉及参数:

region 大小,单位 M

pd-ctl -u http://pdhost:pdport config set max-merge-region-size 20

key range 限制

pd-ctl -u http://pdhost:pdport config set max-merge-region-keys 200000

合并线程数限制

pd-ctl -u http://pdhost:pdport config set merge-schedule-limit 8

2赞

1

答:

dm 同步,上游表结构、索引类型(fulltext index)不兼容,可以在 task 文件中添加 ignore-checking-items: [“table_schema”] 跳过表结构检查,建议该行为需要评估,保证数据解决符合预期即可。

目前官网没有太多关于 ignore-checking-items 的说明。

1

(思路自我发散下,从当前监控可以进行如下分析,由于 raftstore cpu 已在 3.0 调成多线程,所以成为瓶颈的几率降低,但是也是有可能的,如果服务器资源够用,那需要放大一些参数,将集群上限提高)

通过 loader 将数据导入 tidb,tikv 日志出现 tikv server is busy

答:

image

  1. 过目前监控, coprocessor wait duration 峰值 200+ms,tikv 这边建议低于 50ms, 可以通过调整 readpool.coprocessor.max-tasks-per-worker-normal, max-tasks-per-worker-high, max-tasks-per-worker-low 缓解

调整参数建议慢慢调整,逐渐放大,通过控制变量的方式来确定负责系统的参数配置!

image

  1. raftstore cpu 也是超过 80%,建议调整 raftstore.store-pool-size=2 增加调度线程

image

1

问:将 b 服务器 ansible 迁移至 a 服务器,使用 a 服务器的 tiup 来管理

答:

可以,前提是 A 中控机上该用户也能 SSH 登录到部署服务器(在 A 上也能正常使用 ansible 操作集群)

因为导入过程中需要登录到部署服务器上解析配置信息,导入之后的管理也是以执行导入命令的用户通过 SSH 执行的

1

关于 tikv 侧事务冲突检测

tikv 默认参数侧:

  • scheduler-concurrency
    • scheduler 内置一个内存锁机制,防止同时对一个 Key 进行操作。每个 Key hash 到不同的槽。
    • 默认值:2048000

监控侧:

  • scheduler latency wait duration 值很高时,说明大量时间消耗在锁等待上面,如果不存在底层写入问题,那就可以判断在该时间段冲突比较多。

建议:

  • 在实际应用时,如果业务场景能够预判断写入不存在冲突(如导入数据操作),建议关闭冲突检测。

2

关于 tidb 事务重试

步骤:

  1. 重新获取 start timestamp
  2. 重新执行包含写操作 sql 语句
  3. 再次进行两阶段提交

条件:

  1. select for update 无法进行事务重试
  2. 事务只重试数据写操作,读操作不重试

1

答:

关于 feedback-probability,概率自动更新直方图和 Count-Min Sketch,老版本默认值为 0.05,新版本已经优化为 0.0,如果从老版本升级上来出现慢语句或者性能问题,可以将其调整下来。

1

答:

tiup destroy 时会检测端口是否关闭,如果该端口一直被占用,将会失败,及时该端口运行着与 tidb 无关的服务。

1

dm 在 Dump 阶段报错:

“errors”: [ { “Type”: “UnknownError”, “msg”: “[code=32001:class=dump-unit:scope=internal:level=high] mydumper runs with error: exit status 1. \n\n”, “error”: null } ],

答:

在 dump 阶段出现问题,可以从 权限 问题入手,检查上游执行 mydumper 用户是否有响应的权限,一般情况,大都缺少 reload,本问题就是其中一种报错,通过在 task 任务文件中 添加如下配置即可,通过扩展 mydumper 参数的方式,跳过锁表操作。


mysqdumpers:
  global:
    extra-args: “--no-locks”

2

4.0 版本 tikv 参数中多了一个 storage.reserver-space 参数,默认是 2G,作为预留空间,会在 {tikv_data} 目录下创建一个 space_placeholder_file 文件,用于提前占用空间,磁盘使用满的时候可以用于释放空间。

1

答:

  • 如果您对于大小写不敏感的排序规则有强需求,可以打开 TiDB 4.0 的 CI Collation 选项,使用 utf8_general_ci collation
  • 如果没有上述需求,请直接使用 utf8_bin,这也是除 TiDB 4.0 CI Collation 之外,唯一支持的排序规则。

2

答:

tiup v0.5.0 在 deploy 阶段存在 bug,远程创建目录会失败,大家可以注意下,想和版本会修复,使用 tiup update cluster --force 升级即可

1

答:

0.6.0 默认使用 home 下的密钥,如果要使用密码模式传 -p 或者 --password;

–password 的情况下各个服务器的密码得一样

2

【tiup 启动集群后 pd tikv tidb 显示 down ,实际服务正常。】

答:

排查方向现在可以延伸至防火墙,deploy、start 阶段并没有报错,但是监控节点状态却出现问题。

1

SHARD_ROW_ID_BITS 使用条件(或者说 _tidb_rowid 的存在条件)

  1. 没有 primary key 关键字
  2. primary key 非整数类型(不能是 int,bigint 等)

使用方法:

  1. alter table t SHARD_ROW_ID_BITS = 4(2^4 个分片)
  2. create table t (id int) shard_row_id = 4;

2

开启 alter-primary-key,

  1. 需要开启 alter-primary-key: true
  2. 如果你的主键类型为 int,需要进行数据迁移,重新建表,将数据导入新表才 ok ,因为著名的 pkishandle
1赞

1

问:pump 报错,参数设置,【no available space】

答:

思路:

空间不足,但查看可剩余空间是超过 10GB ,怀疑有参数限制去获取空间大小。

so:

stop-write-at-available-space

  • 可用存储空间低于指定值时不再接收 binlog 写入请求。可以用例如 900 MB、5 GB、12 GiB 的格式指定空间大小。如果集群中 Pump 节点多于一个,那么在某个 Pump 节点因为空间不足而拒绝写入时,TiDB 端会自动写入到其他 Pump 节点。
  • 默认:10 GiB

1

目前 tiup 下载 tar 中如果出现错误将会推出,再次下载将会跳过,目前没有校验一步,此时需要删除对应安装包完成下载 .tiup/storage/cluster/packages/

2

答:

在使用 DM 进行迁移时,以下是写流量的切换建议,请根据实际场景进行评估:

DM + 完全业务双写

该方案是在应用端实现双写,并且在指定时间窗口上线双写功能,运行稳定后,可评估写流量切换到 TiDB。

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

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

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

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

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

6)评估后,写流量切换至 TiDB

如果采用您之前提供的方案,业务 A 和业务 B 同时使用表 1 ,并且使用 DM 同步表 1 到 TiDB。DM 同步的粒度是 table,此时,切业务 A 到 TiDB,业务 B 会持续写入数据到 MySQL ,并同步到 TiDB。

1

关于统计信息和执行计划学习

基础概念:

INL_JOIN() 中的参数是建立查询计划时内表的候选表,通过执行计划可以看出当前执行计划的驱动表是谁(outer 为小表,为驱动表):inner key outer key

mysql 执行计划:上面的为驱动表

分析,

第一次通过 mysql 和 tidb 的执行计划看出,mysql tidb 驱动表选择不一致,

方向:使用 hint 将 tidb sql 驱动表保持和 mysql 一致,并使用驱动表索引。

由于开启 tiflash,对 sql 进行了加速,但这不是问题的原因,通过 hint 使用 tikv 存储引擎看查询时间是否接近 mysql。

2

答:

单线程下一个事务在多条 sql 和单条 sql 执行效率基本无差,都进行 1 次 2pc。

1

tidb oom 问题:

通过设置参数以下两个参数控制。目前可能出现设置参数后还是出现 oom 情况,可能是没有 trace 到,这种情况可以联系 pingcap,或者在 tidb github 上提个 issue。


oom-action = “cancel” #指定当单个SQL语句超出 mem-quota-query 指定的内存配额且无法溢出到磁盘时,TiDB执行的操作。有效选项:[“ log”,“ cancel”]

2

tiflash 相关:

  1. 当 tikv peer > tikv store ,tiflash 将不同步副本

  2. placement rules 规则为全局规则需要通过对应 api 来修改。

  3. https://pingcap.com/docs-cn/stable/how-to/configure/placement-rules/

1

关于 tidb 的 session 连接限制:

先看下相关参数,在使用过程中如果发现,tidb 连接数不能满足业务需求,可以调整 a 参数:

a.

–token-limit

  • TiDB 中同时允许运行的 Session 数量,用于流量控制
  • 默认:1000
  • 如果当前运行的连接多于该 token-limit,那么请求会阻塞,等待已经完成的操作释放 Token

b.

max-server-connections

  • TiDB 中同时允许的最大客户端连接数,用于资源控制。
  • 默认值:0
  • 默认情况下,TiDB 不限制客户端连接数。当本配置项的值大于 0 且客户端连接数到达此值时,TiDB 服务端将会拒绝新的客户端连接。

1

tiup edit-config 中配置生成

答:

editconfig 的值和 config 里面的 config 做 merge

可能原因:

  1. 他这个是不是因为配置项的位置变化了啊?这样的话把 ~/.tiup/storage/cluster/clusters/{cluster-name}/config 这里面 ansible 导入的配置文件里面对应那一项删掉(或者注释掉)就不会再被自动添加进去了
  2. config 下面 所有 tidb*.toml 里配置项删掉
  3. 是的,这些文件是从 ansible 导入的时候备份的各个组件实际使用的文件,在 reload 的时候会自动跟 edit-config 的那份配置合并,然后这里应该是因为这个配置项出现在了两个不同的位置所以没有被覆盖掉而是变成了两项

2

tiup display 状态展示 pd 节点的获取是通过 pd-ctl member 获取的,如果 /home/tidb/.tiup/storage/cluster/clusters/qh/meta.yaml 文件的 pd name 与 pd-ctl 获取不一致 display 状态显示可能为 N/A