固定写死的硬编码啊？只读取 /etc/security/limits.conf

这种在/etc/security/limits.d/ 目录中独立设置用户资源限制，是 linux 系统中的标准。/etc/security/limits.conf 中描述如下： [root@idc1-sjcredit-tiup ~]# cat /etc/security/limits.conf # /etc/security/limits.conf # #This file sets the resource limits for the users logged in via PAM. #It does not affect resource limits of the syst…

将资源限制设置到 /etc/security/limits.d/tidb.conf 中，对 tidb 用户是生效的。但是，无法被 tiup 部署工具读取。必须要全局设置（/etc/security/limits.conf），才可被 tiup 读取。但是，在部署oracle时，无论全局设置，还是 /etc/security/limits.d/ 目录中设置，均可被 oracle 安装程序读取到。 [tidb@h200 ~]$ id uid=1001(tidb) gid=1001(tidb) groups=1001(tidb),10(wheel) [tidb@h200 ~]$ cat /etc/s…

这4个步骤都检查过了。

limit限制到50了，timeout没试过。

md5校验了测试环境与生产环境备份集中的每个sst文件，文件未损坏。检查生产环境的备份日志，备份结束时有 2 个报错 [pd] fetch pending tso requests error]。但，最后提示 Full backup success summary。用这些备份集做 br 恢复，都是在恢复至 75% 左右，立即提示找不到sst 文件

这里的推荐 1 和 tispark 没有关系，直接通过 jdbc connector 完成与 tidb 的交互吧？而并非直接读写 TiKV。

加了-L debug，提示找不到sst文件。初步判断是备份集文件拷贝过程中的损坏问题。但备份集是打了压缩包的，解压过程未报错。过些天，试试直接挂载nfs看看是否还报错。

加了 --ratelimit 64 仍然报同样的错。我再多分配些资源试下。

没有任何限制。全新的环境，官方的基础配置模板部署的测试环境。

我初步也判断是测试环境资源不足的问题。重新执行了一次恢复，加入了 --ratelimit 64 参数，限制速率。不知是否有效。

全新部署的与生产一致的软件版本及各节点角色的数量。 唯一的几点区别：测试环境硬件资源差一些，操作系统为openEuler 22.03（已通过tiup的OS检查）。生产环境的OS为Centos 7.9。

我用 tiup mirror clone 方式，重新打包了。没用官网提供的 server 和 toolkit 包。

TiDB 在各种参数的配置上，相对其他数据库来说有些混乱。

开发规范里建议日期时间比较大小，不用显式增加转换函数么？

看一下 txn-entry-size-limit 这个参数是多少？ 此参数从 v5.0 版本开始引入，默认为 6291456（单位bytes），最大值不超过 125829120 （表示 120MB）。更详细的介绍，详见官网：txn-entry-size-limit