【 TiDB 使用环境`】测试环境
【 TiDB 版本】v5.4.1
【遇到的问题】
tidb执行命令tiup cluster check tidb-test --cluster发现如下异常！请问该怎么解决？
pd-ctl 查一下region check miss-peer
如果数据量不大可以手动补一下副本
operator add add-peer xx xx
好的感谢解答，但是查了好多miss-peer，请问太多了该怎么处理？手动补副本这么多不太现实！这种miss-peer是什么原因造成的？
理论上region miss 是会自动下降的，会自动补副本。你可以观察下
如果一直存在没有下降，可以检查tikv的磁盘容量 看是否达到阀值
调度策略控制
使用 pd-ctl 可以从以下三个方面来调整 PD 的调度策略。更具体的信息可以参考 PD Control。
启停调度器
pd-ctl 支持动态创建和删除 Scheduler，你可以通过这些操作来控制 PD 的调度行为，如：
-
scheduler show：显示当前系统中的 Scheduler -
scheduler remove balance-leader-scheduler：删除（停用）balance region 调度器 -
scheduler add evict-leader-scheduler 1：添加移除 Store 1 的所有 Leader 的调度器
手动添加 Operator
PD 支持直接通过 pd-ctl 来创建或删除 Operator，如：
-
operator add add-peer 2 5：在 Store 5 上为 Region 2 添加 Peer -
operator add transfer-leader 2 5：将 Region 2 的 Leader 迁移至 Store 5 -
operator add split-region 2：将 Region 2 拆分为 2 个大小相当的 Region -
operator remove 2：取消 Region 2 当前待执行的 Operator
调度参数调整
使用 pd-ctl 执行 config show 命令可以查看所有的调度参数，执行 config set {key} {value} 可以调整对应参数的值。常见调整如下：
-
leader-schedule-limit：控制 Transfer Leader 调度的并发数 -
region-schedule-limit：控制增删 Peer 调度的并发数 -
enable-replace-offline-replica：开启节点下线的调度 -
enable-location-replacement：开启调整 Region 隔离级别相关的调度 -
max-snapshot-count：每个 Store 允许的最大收发 Snapshot 的并发数
想问一下，什么情况下容易出现region miss的现象呀？
一般是上线/下线，或者tikv宕机,tifash补副本等
ok感谢大佬解答
ok谢谢解答
pd-ctl store 信息发一下
» store
{
“count”: 3,
“stores”: [
{
“store”: {
“id”: 4,
“address”: “10.60.28.171:20160”,
“version”: “5.4.1”,
“status_address”: “10.60.28.171:20180”,
“git_hash”: “91fe561f0af87cc47359cdf61d6e6838471cb644”,
“start_timestamp”: 1657783577,
“deploy_path”: “/tidb-deploy/tikv-20160/bin”,
“last_heartbeat”: 1657792548350658608,
“state_name”: “Up”
},
“status”: {
“capacity”: “99.75GiB”,
“available”: “94.71GiB”,
“used_size”: “42.7MiB”,
“leader_count”: 85,
“leader_weight”: 1,
“leader_score”: 85,
“leader_size”: 92,
“region_count”: 161,
“region_weight”: 1,
“region_score”: 789.034187893511,
“region_size”: 168,
“slow_score”: 1,
“start_ts”: “2022-07-14T15:26:17+08:00”,
“last_heartbeat_ts”: “2022-07-14T17:55:48.350658608+08:00”,
“uptime”: “2h29m31.350658608s”
}
},
{
“store”: {
“id”: 63,
“address”: “10.60.28.178:3930”,
“labels”: [
{
“key”: “engine”,
“value”: “tiflash”
}
],
“version”: “v5.4.1”,
“peer_address”: “10.60.28.178:20170”,
“status_address”: “10.60.28.178:20292”,
“git_hash”: “1d20105ad4a1b8516e6ee1b20acc257e3584fdd6”,
“start_timestamp”: 1657768678,
“deploy_path”: “/tidb-deploy/tiflash-9000/bin/tiflash”,
“last_heartbeat”: 1657792550566992459,
“state_name”: “Up”
},
“status”: {
“capacity”: “99.75GiB”,
“available”: “95.14GiB”,
“used_size”: “84.01KiB”,
“leader_count”: 0,
“leader_weight”: 1,
“leader_score”: 0,
“leader_size”: 0,
“region_count”: 0,
“region_weight”: 1,
“region_score”: 0,
“region_size”: 0,
“slow_score”: 0,
“start_ts”: “2022-07-14T11:17:58+08:00”,
“last_heartbeat_ts”: “2022-07-14T17:55:50.566992459+08:00”,
“uptime”: “6h37m52.566992459s”
}
},
{
“store”: {
“id”: 1,
“address”: “10.60.28.172:20160”,
“version”: “5.4.1”,
“status_address”: “10.60.28.172:20180”,
“git_hash”: “91fe561f0af87cc47359cdf61d6e6838471cb644”,
“start_timestamp”: 1657783572,
“deploy_path”: “/tidb-deploy/tikv-20160/bin”,
“last_heartbeat”: 1657792543334977209,
“state_name”: “Up”
},
“status”: {
“capacity”: “99.75GiB”,
“available”: “95.44GiB”,
“used_size”: “33.16MiB”,
“leader_count”: 76,
“leader_weight”: 1,
“leader_score”: 76,
“leader_size”: 76,
“region_count”: 161,
“region_weight”: 1,
“region_score”: 784.7309712676937,
“region_size”: 168,
“slow_score”: 1,
“start_ts”: “2022-07-14T15:26:12+08:00”,
“last_heartbeat_ts”: “2022-07-14T17:55:43.334977209+08:00”,
“uptime”: “2h29m31.334977209s”
}
}
]
}
2tikv 一个tiflash？3副本至少还要一个kv,要不丢了的副本没办法自动补
这种感觉就像主从延迟，如果能追上来也就没事了
嗯意思是需要增加一台tikv,至少3个tikv
对的 新增tikv之后你在看下
ok感谢指点
增加了一个tikv节点发现没有miss-peer了，感谢大佬指点谢谢
ok 3副本至少要保持三kv节点