br 备份时特定 region 狂喷 NotLeader

[npes87184]

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】k8s

【概述】 br 备份到自架 minio

【备份和数据迁移策略逻辑】

【背景】 第一次遇到问题重启 backup job 之后又撞到一样问题。

【现象】 发生问题后使用 mysqldump 进行一次完整备份成功，数据应是正常的。

【问题】 br 备份时特定 region 狂喷 NotLeader

【业务影响】 backup 卡在 99.99%

【TiDB 版本】 4.0.4

【附件】
Backup job 日誌

backup-log (220.4 KB)

相关 region 对应的 TiKV 日志

tikv-region-5209737 (318.4 KB)

谢谢

[这道题我不会 (Lizhengyang@PingCAP)]

请问每次同步遇到报错的都是 region 5209737 吗？从 region 日志中发现这个该 region 一直在进行发生 changepeer ，该 region 对应的表是有同步至 tiflash 吗？可以通过 pd-ctl 先看下 region 5209737 的状态

[npes87184]

请问每次同步遇到报错的都是 region 5209737 吗？

这个我需要重跑过一次才知道，如果没有其他线索，可以重跑一次观察。

该 region 对应的表是有同步至 tiflash 吗？

否，环境中没有 TiFlash。

可以通过 pd-ctl 先看下 region 5209737 的状态

内容如下

{
  "id": 5209737,
  "start_key": "",
  "end_key": "7480000000000000FF175F728000000000FF04A4100000000000FA",
  "epoch": {
    "conf_ver": 259100,
    "version": 241
  },
  "peers": [
    {
      "id": 5927699,
      "store_id": 1012
    },
    {
      "id": 5927846,
      "store_id": 1006
    },
    {
      "id": 5927973,
      "store_id": 1002
    }
  ],
  "leader": {
    "id": 5927846,
    "store_id": 1006
  },
  "written_bytes": 150593,
  "read_bytes": 3470050,
  "written_keys": 871,
  "read_keys": 52948,
  "approximate_size": 237,
  "approximate_keys": 987286
}

过 40 分钟以后再跑一次

{
  "id": 5209737,
  "start_key": "",
  "end_key": "7480000000000000FF175F728000000000FF04A4100000000000FA",
  "epoch": {
    "conf_ver": 259106,
    "version": 241
  },
  "peers": [
    {
      "id": 5927846,
      "store_id": 1006
    },
    {
      "id": 5928022,
      "store_id": 1005
    },
    {
      "id": 5928049,
      "store_id": 5639227
    }
  ],
  "leader": {
    "id": 5927846,
    "store_id": 1006
  },
  "written_bytes": 283603,
  "read_bytes": 6043618,
  "written_keys": 1310,
  "read_keys": 93754,
  "approximate_size": 237,
  "approximate_keys": 987286
}

看到 peers 有变化，此外多次跑的过程中，也曾有发现 leader 变化。

谢谢老师

[这道题我不会 (Lizhengyang@PingCAP)]

从上面的信息看 region leader 一直位于 store 1006，但非 leader 的 peer 都切换到其他 store 上了，你这边 tikv 节点经常扩缩容吗？或者是 tikv 的剩余空间有存在不足的情况吗？

[npes87184]

从上面的信息看 region leader 一直位于 store 1006

这句话非真，在多次 pd-ctl 取的资讯的过程中曾经有看过切换 leader。只是贴上来的刚好没贴到有换 leader 的。

再次执行一次就刚好看到换了

{
  "id": 5209737,
  "start_key": "",
  "end_key": "7480000000000000FF175F728000000000FF04A4100000000000FA",
  "epoch": {
    "conf_ver": 259121,
    "version": 241
  },
  "peers": [
    {
      "id": 5927846,
      "store_id": 1006
    },
    {
      "id": 5928176,
      "store_id": 1001
    },
    {
      "id": 5928241,
      "store_id": 1003
    }
  ],
  "leader": {
    "id": 5928176,
    "store_id": 1001
  },
  "written_bytes": 429,
  "read_bytes": 0,
  "written_keys": 1,
  "read_keys": 0,
  "approximate_size": 242,
  "approximate_keys": 1030649
}

这边 tikv 节点经常扩缩容吗？

否

tikv 的剩余空间有存在不足的情况吗？

否，刚刚看了一下，每一个 TiKV 的 PVC 剩余空间都有约 2 TB。

谢谢老师

[这道题我不会 (Lizhengyang@PingCAP)]

1.如果这个 region leader 和 peer 一直都在 transfer ，很可能是遇到热点问题，可以参考这篇文章处理下：https://docs.pingcap.com/zh/tidb/v5.0/troubleshoot-hot-spot-issues#tidb-热点问题处理
2.可以尝试找一个业务低峰期的时候再进行 BR 备份。

[npes87184]

不太像是热点问题，从热图看起来没有什么亮点，底下那排亮点看起来是遇到问题 (8/10) 之后才出现。

此外我看了一下用量，并不是特别高。

目前重启 TiKV 后再次触发备份成功了，会再继续观察。

谢谢

[这道题我不会 (Lizhengyang@PingCAP)]

好吧，如果再遇到问题可以提供下当时的监控相关数据。

[npes87184]

老师好，今天又撞到一样的问题。

这次撞到的 region 不一样是 5953461。

pd-ctl 的回传如下

{
  "id": 5953461,
  "start_key": "",
  "end_key": "7480000000000000FF175F728000000000FF026FC90000000000FA",
  "epoch": {
    "conf_ver": 260714,
    "version": 242
  },
  "peers": [
    {
      "id": 5969806,
      "store_id": 5639227
    },
    {
      "id": 5969809,
      "store_id": 1004
    },
    {
      "id": 5970061,
      "store_id": 1002
    }
  ],
  "leader": {
    "id": 5969806,
    "store_id": 5639227
  },
  "written_bytes": 172686,
  "read_bytes": 4867506,
  "written_keys": 826,
  "read_keys": 77258,
  "approximate_size": 248,
  "approximate_keys": 1505975
}

初步看负载并没有很高，请问老师有什么其他监控数据适合看?

谢谢老师

[这道题我不会 (Lizhengyang@PingCAP)]

麻烦参考链接 https://metricstool.pingcap.com/#backup-with-dev-tools 中的方法导出下 PD 和 tikv-details 的监控面板，选择 BR 备份的时间段，等页面全部加载出来后再导出。