tikv经常被剔除,导致报错

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】
3tikv+2tidb+3pd+3ticdc+1tiflash

【概述】 场景 + 问题概述
tikv节点在业务量高峰时会被异常踢掉,但tikv所在服务器的网络,磁盘和cpu虽有上升,但并未达到使用上限。
【背景】 做过哪些操作

【现象】 业务和数据库现象
数据库突然响应慢,单个tikv节点被踢掉,应用程序中正在执行的事务报错。
【问题】 当前遇到的问题,参考 AskTUG 的 Troubleshooting https://asktug.com/t/topic/68049

【统计信息是否最新】

    【执行计划内容】

    【 SQL 文本、schema 以及 数据分布】

【业务影响】

【TiDB 版本】
v4.0.13
【附件】 相关日志及监控(https://metricstool.pingcap.com/)

  • TiUP Cluster Display 信息
    image
  • TiUP CLuster Edit config 信息
    global:
    user: tidb
    ssh_port: 22
    ssh_type: builtin
    deploy_dir: /data/tidb-deploy
    data_dir: /data/tidb-data
    os: linux
    arch: amd64
    monitored:
    node_exporter_port: 9100
    blackbox_exporter_port: 9115
    deploy_dir: /data/tidb-deploy/monitor-9100
    data_dir: /data/tidb-data/monitor-9100
    log_dir: /data/tidb-deploy/monitor-9100/log
    server_configs:
    tidb:
    lower-case-table-names: 1
    performance.max-txn-ttl: 7200000
    performance.txn-total-size-limit: 10737418240
    tikv: {}
    pd:
    replication.enable-placement-rules: true
    tiflash: {}
    tiflash-learner: {}
    pump: {}
    drainer: {}
    cdc: {}
    tidb_servers:
  • host: xx.xxx.45.5
    ssh_port: 22
    port: 4000
    status_port: 10080
    deploy_dir: /data/tidb-deploy/tidb-4000
    log_dir: /data/tidb-deploy/tidb-4000/log
    arch: amd64
    os: linux
  • host: xx.xx.46.5
    ssh_port: 22
    port: 4000
    status_port: 10080
    deploy_dir: /data/tidb-deploy/tidb-4000
    log_dir: /data/tidb-deploy/tidb-4000/log
    arch: amd64
    os: linux
    tikv_servers:
  • host: xx.xx.45.10
    ssh_port: 22
    port: 20160
    status_port: 20180
    deploy_dir: /data/tidb-deploy/tikv-20160
    data_dir: /data/tidb-data/tikv-20160
    log_dir: /data/tidb-deploy/tikv-20160/log
    arch: amd64
    os: linux
  • host: xx.xx.46.10
    ssh_port: 22
    port: 20160
    status_port: 20180
    deploy_dir: /data/tidb-deploy/tikv-20160
    data_dir: /data/tidb-data/tikv-20160
    log_dir: /data/tidb-deploy/tikv-20160/log
    arch: amd64
    os: linux
  • host: xx.xx.47.10
    ssh_port: 22
    port: 20160
    status_port: 20180
    deploy_dir: /data/tidb-deploy/tikv-20160
    data_dir: /data/tidb-data/tikv-20160
    log_dir: /data/tidb-deploy/tikv-20160/log
    arch: amd64
    os: linux
    tiflash_servers:
  • host: xx.xx.45.11
    ssh_port: 22
    tcp_port: 9000
    http_port: 8123
    flash_service_port: 3930
    flash_proxy_port: 20170
    flash_proxy_status_port: 20292
    metrics_port: 8234
    deploy_dir: /data/tidb-deploy/tiflash-9000
    data_dir: /data/tidb-data/tiflash-9000
    log_dir: /data/tidb-deploy/tiflash-9000/log
    arch: amd64
    os: linux
    pd_servers:
  • host: xx.xxx.45.6
    ssh_port: 22
    name: pd-xx.xx.45.6-2379
    client_port: 2379
    peer_port: 2380
    deploy_dir: /data/tidb-deploy/pd-2379
    data_dir: /data/tidb-data/pd-2379
    log_dir: /data/tidb-deploy/pd-2379/log
    arch: amd64
    os: linux
  • host: xx.xx.46.6
    ssh_port: 22
    name: pd-xx.xxx.46.6-2379
    client_port: 2379
    peer_port: 2380
    deploy_dir: /data/tidb-deploy/pd-2379
    data_dir: /data/tidb-data/pd-2379
    log_dir: /data/tidb-deploy/pd-2379/log
    arch: amd64
    os: linux
  • host: xx.xx.47.6
    ssh_port: 22
    name: pd-xxx.xxx.47.6-2379
    client_port: 2379
    peer_port: 2380
    deploy_dir: /data/tidb-deploy/pd-2379
    data_dir: /data/tidb-data/pd-2379
    log_dir: /data/tidb-deploy/pd-2379/log
    arch: amd64
    os: linux
    cdc_servers:
  • host: xx.xxx.45.12
    ssh_port: 22
    port: 8300
    deploy_dir: /data/tidb-deploy/cdc-8300
    data_dir: /data/tidb-data/cdc-8300
    log_dir: /data/tidb-deploy/cdc-8300/log
    arch: amd64
    os: linux
  • host: xx.xxx.46.12
    ssh_port: 22
    port: 8300
    deploy_dir: /data/tidb-deploy/cdc-8300
    data_dir: /data/tidb-data/cdc-8300
    log_dir: /data/tidb-deploy/cdc-8300/log
    arch: amd64
    os: linux
  • host: xx.xxx.47.12
    ssh_port: 22
    port: 8300
    deploy_dir: /data/tidb-deploy/cdc-8300
    data_dir: /data/tidb-data/cdc-8300
    log_dir: /data/tidb-deploy/cdc-8300/log
    arch: amd64
    os: linux
    monitoring_servers:
  • host: xxx.xxx.45.9
    ssh_port: 22
    port: 9090
    deploy_dir: /data/tidb-deploy/prometheus-9090
    data_dir: /data/tidb-data/prometheus-9090
    log_dir: /data/tidb-deploy/prometheus-9090/log
    external_alertmanagers: []
    arch: amd64
    os: linux
    grafana_servers:
  • host: xxx.xxx.45.9
    ssh_port: 22
    port: 3000
    deploy_dir: /data/tidb-deploy/grafana-3000
    arch: amd64
    os: linux
    username: admin
    password: admin
    anonymous_enable: false
    root_url: “”
    domain: “”
    alertmanager_servers:
  • host: xxx.xxx.45.9
    ssh_port: 22
    web_port: 9093
    cluster_port: 9094
    deploy_dir: /data/tidb-deploy/alertmanager-9093
    data_dir: /data/tidb-data/alertmanager-9093
    log_dir: /data/tidb-deploy/alertmanager-9093/log
    arch: amd64
    os: linux
  • TiDB-Overview Grafana监控
    image
  • TiDB Grafana 监控
    image
  • TiKV Grafana 监控
    image
  • PD Grafana 监控
  • 对应模块日志(包含问题前后 1 小时日志)
    pd日志显示故障前大量region leader在tikv之间切换。

这个集群的硬件配置是怎么样的?

tikv 16核64G,tidb 16核128G

故障是的kv指令有阻塞而且写入量突增


是不是热点问题导致的? 10.110.45.10 可以看下日志

日志有点大

tikv.log.2021-12-03-16_41_31.zip (24.8 MB)

tikv.log.2021-12-03-18_08_13.zip (28.3 MB)

看下了,基本和这个帖子类似的问题

可以参考下

这个帖子好像解决不了问题。

tikv_error.log (213.2 KB)
我把当天的ERROR汇总了,帮忙看看是什么原因导致系统卡死的。

找到写入流量高得表,找业务进行和谐下:grinning: 如果某个TIKV 异常 可以选择驱逐,直接关闭分钟,这个是没法彻底解决问题的,线上也遇到你这样的问题,就是找业务进行“和谐”操作

我来补充下吧,这个问题我们已经解决了,不过解决方案没有补充到原来问题里。
我们出现的问题我大概描述一下,基本上是断定是下面这个高频查询SQL导致的:

FROM
  asset_fund_latest a
  JOIN pre_asset_fund b ON a.txn_account_id = b.txn_account_id
  AND a.fund_code = b.fund_code
  AND a.share_type = b.share_type
WHERE
  a.account3_id = ''
  AND a.broker = ''
  AND a.txn_account_id IN ('')
  AND a.fund_code IN ('');
 
-- asset_fund_latest
PRIMARY KEY (`account3_id`,`txn_account_id`,`fund_code`,`cal_date`) /*T![clustered_index] CLUSTERED */
-- pre_asset_fund
PRIMARY KEY (`txn_account_id`,`fund_code`) /*T![clustered_index] CLUSTERED */
 
-- EXPLAIN 信息
    id                          task        estRows operator info                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               actRows execution info                                                                                                                                                                                                                                                                      memory      disk
    Projection_8                root        0.00    ying99_asset.asset_fund_latest.fund_code, ying99_asset.asset_fund_latest.share_type, ying99_asset.asset_fund_latest.txn_account_id, round(ying99_asset.pre_asset_fund.acc_profit, 4)->Column#67, round(ying99_asset.pre_asset_fund.acc_profit_rate, 6)->Column#68, <nil>->Column#69, <nil>->Column#70, <nil>->Column#71, <nil>->Column#72, round(ying99_asset.pre_asset_fund.daily_profit, 4)->Column#73, round(ying99_asset.pre_asset_fund.daily_profit_rate, 6)->Column#74, ying99_asset.pre_asset_fund.nav_date, round(ying99_asset.pre_asset_fund.nav, 4)->Column#75 0       time:8m33.5s, loops:1, Concurrency:OFF                                                                                                                                                                                                                                              9.18 KB     N/A
    └─IndexJoin_23              root        0.00    inner join, inner:TableReader_19, outer key:ying99_asset.pre_asset_fund.txn_account_id, ying99_asset.pre_asset_fund.fund_code, inner key:ying99_asset.asset_fund_latest.txn_account_id, ying99_asset.asset_fund_latest.fund_code, equal cond:eq(ying99_asset.pre_asset_fund.fund_code, ying99_asset.asset_fund_latest.fund_code), eq(ying99_asset.pre_asset_fund.share_type, ying99_asset.asset_fund_latest.share_type), eq(ying99_asset.pre_asset_fund.txn_account_id, ying99_asset.asset_fund_latest.txn_account_id)                                                      0       time:8m33.5s, loops:1, inner:{total:3m1.7s, concurrency:5, task:26, construct:1.13s, fetch:3m0.6s, build:5.61µs}, probe:80.7ms                                                                                                                                                  128.5 MB    N/A
      ├─TableReader_19          root        0.00    data:Selection_18                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           0       time:2m59.9s, loops:26, cop_task: {num: 42, max: 19.1s, min: 1.13s, avg: 7.2s, p95: 18.2s, tot_proc: 17.5s, tot_wait: 4m43.1s, rpc_num: 42, rpc_time: 5m2.3s, copr_cache_hit_ratio: 0.00}                                                                                           N/A         N/A
      │ └─Selection_18          cop[tikv]   0.00    eq(ying99_asset.asset_fund_latest.account3_id, 2209059), eq(ying99_asset.asset_fund_latest.broker, "1178"), eq(ying99_asset.asset_fund_latest.fund_code, "000509"), eq(ying99_asset.asset_fund_latest.txn_account_id, "03554489"), not(isnull(ying99_asset.asset_fund_latest.share_type))                                                                                                                                                                                                                                                                                   0       tikv_task:{proc max:1.17s, min:4ms, p80:924ms, p95:1.12s, iters:42, tasks:42}, scan_detail: {total_process_keys: 0, total_keys: 449971, rocksdb: {delete_skipped_count: 0, key_skipped_count: 0, block: {cache_hit_count: 4924946, read_count: 0, read_byte: 0 Bytes}}}             N/A         N/A
      │   └─TableRangeScan_17   cop[tikv]   0.00    table:a, range: decided by [ying99_asset.pre_asset_fund.txn_account_id ying99_asset.pre_asset_fund.fund_code ying99_asset.pre_asset_fund.share_type], keep order:false                                                                                                                                                                                                                                                                                                                                                                                                      0       tikv_task:{proc max:1.17s, min:4ms, p80:924ms, p95:1.12s, iters:42, tasks:42}                                                                                                                                                                                                       N/A         N/A
      └─TableReader_33          root        449094  data:TableFullScan_32                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       449971  time:8m2.7s, loops:447, cop_task: {num: 3, max: 8m14.2s, min: 370.3ms, avg: 3m7.8s, p95: 8m14.2s, max_proc_keys: 180555, p95_proc_keys: 180555, tot_proc: 1.17s, tot_wait: 168ms, rpc_num: 14, rpc_time: 9m15.7s, copr_cache_hit_ratio: 0.00}, backoff{tikvRPC: 7.71s}              77.5 MB     N/A
        └─TableFullScan_32      cop[tikv]   449094  table:b, keep order:false, stats:pseudo 

这个SQL其实没有太大问题,当表b有一定数据量后,其实这个表查询也很快,两边都是走的主键扫描,但是在表比较小的情况下,就有坑了。具体原因如下:

  • 在表b每天都是从0开始写入,而在表b数据量很少的情况下,表的Region也只有一个落在某一台TiKV上
  • 因为表b很小导致一些本来可以走索引的查询被「优化」成全表扫描,
  • 而scan算子受tidb_distsql_scan_concurrency控制,这个参数默认值只有15。所以大量请求被打到后端TiKV进行排队,导致后端TiKV节点负载高。
  • 也因为在TiKV里排队,所以这些请求在TiDB Server里也会一直存在,占用一部分内存。
  • 因为max_execution_time默认为0,TiDB Server上查询不会自动被kill,导致TiDBServer 上连接一直增长,内存迅速增长把TiDB Server搞OOM了。

修复方案也很简单:

  • 修复表b的表结构,将account3_id也加入到主键中,修改查询SQL的JOIN字段,将a.account3_id = b.account3_id,这样即便表b很小的情况下,也不会走到全表扫描
  • 加大tidb_distsql_scan_concurrency的值,不过这个值官方也建议不超过TiKV的总核数,所以也才调大到40
3 个赞

可以增加TIKV负载告警image 类似这种,找对应TIKV 查看日志
可以加个自动KILL 脚本,要想稳定得多花点经历

1 个赞

高流量一般都伴随 热点,必须找到热点源,通过合理的优化 或者打散 才行的

数据批量写入这个热点是没法解决的,该存在还是存在的

批量写入,是写入到一个节点,还是多个节点,这个效果差很多的

批量写入一个会话也只会一个节点的

照你这么说,这个分布式就是假的,不知道你哪儿来的结论 :sweat:
你另外开个帖子吧(这个描述对这个帖子的问题,毫无帮助…)

结论就是干出来的,目前已经把那写入引起集群异常的表 已经下了 集群已经稳定了:grinning: