【已解决】已经修改了max-txn-time-use: 3590和tikv_gc_run_interval和tikv_gc_life_time,还是600秒后中断

问题出在了阿里云SLB上。如果不通过SLB链接数据库,直接连接TIDB,则问题消失。

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

  • 【TiDB 版本】:3.0.3
  • 【问题描述】:我需要做一些长的select,已经按照指引修改了 conf/tikv.yml中 max-txn-time-use: 3590 和 |tikv_gc_run_interval|50m| |tikv_gc_life_time|1h| %E5%BE%AE%E4%BF%A1%E6%88%AA%E5%9B%BE_20191219154826

但是执行操作的时候,还是600s准时断。请问还应该做哪些操作才能执行长链接?

在修改完成之后有没有 执行 rolling_update.yml 进行滚动更新? 如果已经重启过 TiDB 具体信息可以看下 tidb.log ,在启动的时候会带上具体的配置值,确认一下 max-txn-time-use 具体的值。

应该已经拿到3590这个参数了。但是还是不行。

[2019/12/19 15:28:23.119 +08:00] [INFO] [printer.go:54] [“loaded config”] [config="{“host”:“0.0.0.0”,“advertise-address”:“172.18.25.83”,“port”:4000,“cors”:"",“store”:“tikv”,“path”:“172.18.25.83:2379”,“socket”:"",“lease”:“45s”,“run-ddl”:true,“split-table”:true,“token-limit”:1000,“oom-action”:“log”,“mem-quota-query”:34359738368,“enable-streaming”:false,“txn-local-latches”:{“enabled”:true,“capacity”:2048000},“lower-case-table-names”:2,“log”:{“level”:“info”,“format”:“text”,“disable-timestamp”:false,“file”:{“filename”:"/data1/log/tidb.log",“log-rotate”:true,“max-size”:300,“max-days”:0,“max-backups”:0},“slow-query-file”:"/data1/log/tidb_slow_query.log",“slow-threshold”:300,“expensive-threshold”:10000,“query-log-max-len”:2048},“security”:{“skip-grant-table”:false,“ssl-ca”:"",“ssl-cert”:"",“ssl-key”:"",“cluster-ssl-ca”:"",“cluster-ssl-cert”:"",“cluster-ssl-key”:""},“status”:{“report-status”:true,“status-host”:“0.0.0.0”,“status-port”:10080,“metrics-addr”:"",“metrics-interval”:15,“record-db-qps”:false},“performance”:{“max-procs”:0,“max-memory”:0,“tcp-keep-alive”:true,“cross-join”:true,“stats-lease”:“3s”,“run-auto-analyze”:true,“stmt-count-limit”:5000,“feedback-probability”:0.05,“query-feedback-limit”:1024,“pseudo-estimate-ratio”:0.8,“force-priority”:“NO_PRIORITY”,“bind-info-lease”:“3s”},“prepared-plan-cache”:{“enabled”:false,“capacity”:100,“memory-guard-ratio”:0.1},“opentracing”:{“enable”:false,“sampler”:{“type”:“const”,“param”:1,“sampling-server-url”:"",“max-operations”:0,“sampling-refresh-interval”:0},“reporter”:{“queue-size”:0,“buffer-flush-interval”:0,“log-spans”:false,“local-agent-host-port”:""},“rpc-metrics”:false},“proxy-protocol”:{“networks”:"",“header-timeout”:5},“tikv-client”:{“grpc-connection-count”:16,“grpc-keepalive-time”:10,“grpc-keepalive-timeout”:3,“commit-timeout”:“41s”,“max-txn-time-use”:3590,“max-batch-size”:128,“overload-threshold”:200,“max-batch-wait-time”:0,“batch-wait-size”:8},“binlog”:{“enable”:true,“write-timeout”:“15s”,“ignore-error”:false,“binlog-socket”:"",“strategy”:“range”},“compatible-kill-query”:false,“plugin”:{“dir”:"",“load”:""},“pessimistic-txn”:{“enable”:false,“default”:false,“max-retry-count”:256,“ttl”:“30s”},“check-mb4-value-in-utf8”:true,“treat-old-version-utf8-as-utf8mb4”:true}"]

再详细看了一下截图,也有可能是工具的原因断开导致的。

  1. 检查下 show global variables like '%max_execution_time%'; 看下有没有相关设置
  2. 更换查询的 client 进行尝试。

换了一个client,好像还是不行,不过报的错不一样了。但是这个看上去不像是我网络问题造成的吧? %E5%BE%AE%E4%BF%A1%E6%88%AA%E5%9B%BE_20191219171429 %E5%BE%AE%E4%BF%A1%E6%88%AA%E5%9B%BE_20191219174615

麻烦检查下 {deploy_path}/log/tidb.log 里面有没有相关的错误输出?

1.我怎么判断这个日志会在哪个tidb上输出?我是3 tidb 2.这个错误大概长什么样?我怎么找到

麻烦直接连接到具体的一台 TiDB 进行测试。然后看下那台执行 SQL 的 TiDB 有没有相关的错误日志,或者直接上传该 TiDB 的日志进行分析。

tidb.zip (1.1 MB) 我导出了日志。请问能看出原因吗?

正常若是超过tikv_gc 时间限制报错理论是 gc lift time short 之类得,报错是丢失链接,可以查看下是不是 tidb 链接是不是长时间没用被 kill 了,或者 oom 被kill 之类得