Tikv扩容成功后，几天后没有自动均衡数据

beebol · 2019 年9 月 25 日 09:47

可以均衡了，但是很慢，从版本升级到现在，只均衡了很少一部分数据

mao_siyu · 2019 年9 月 26 日 00:59

修改一个region 的副本数量呢？或者修改一个每个region的大小

beebol · 2019 年9 月 26 日 11:00

副本数量是默认的，需要怎么调整，增加还是减少？

qizheng · 2019 年9 月 27 日 01:17

通过 PD 监控 - Statistics - balance 确认下当前新加入 store 的 region 和 leader score，正常应该比其他 store 要小很多，并且其他 store 应该是均衡的；
通过 PD 监控 - Operator 确认下当前 balance - leader 和 balance - region 的的 scheduler operator 相关面板，也可以通过 pd-ctl > operator show 看下当前操作是否包含新加入的 store；
查一下 config show all，是否 region merge 打开了，region merge 会影响其他正常的调度，尝试关闭再观察下；
尝试调大 region 和 leader 相关的调度参数再观察下监控；
尝试手动 transfer leader 和 region 到其他 store 能否成功；

beebol · 2019 年9 月 27 日 06:06

1、监控显示新加入store的region很少，其它老的节点都是均衡的，可以看之前发的图
2、
pt-ctl -u http://xxxxx:2379 
» operator show
[]
3、已经将region meger关闭： "merge-schedule-limit": 0,
观察没有变化 
4、从默认值4调大到8：
"leader-schedule-limit": 8,
  "region-schedule-limit": 8,
5、手动 transfer leader 和 region 到其他 store 是可以成功的。


观察还没有正常均衡

qizheng · 2019 年9 月 27 日 06:22

这两个 store 上的 region 和 leader 数量有增加吗，还是一直不变？

beebol · 2019 年9 月 27 日 06:24

一直没有变。现在把这两store给delete了（目前正在ofline中），然后再重新扩上去试试。

beebol · 2019 年9 月 30 日 03:21

delete store后，一直是offline状态，region不会自动迁移，手动将region leader迁到其它节点后。直接stop 节点。再将数据目录mv掉。重新deploy。启动时报错：

[2019/09/30 11:04:21.540 +08:00] [ERROR] [util.rs:327] ["request failed"] [err="Grpc(RpcFailure(RpcStatus { status: Unknown, details: Some("duplicated store address: id:1108427 address:\"10.x.x.26:20160\" version:\"3.0.0-rc.2\" , already registered by id:1087486 address:\"10.x.x.26:20160\" state:Offline version:\"3.0.0-rc.2\" ") }))"]
[2019/09/30 11:04:21.541 +08:00] [ERROR] [util.rs:327] ["request failed"] [err="Grpc(RpcFailure(RpcStatus { status: Unknown, details: Some("duplicated store address: id:1108427 address:\"10.x.x.26:20160\" version:\"3.0.0-rc.2\" , already registered by id:1087486 address:\"10.x.x.26:20160\" state:Offline version:\"3.0.0-rc.2\" ") }))"]
[2019/09/30 11:04:21.542 +08:00] [ERROR] [util.rs:327] ["request failed"] [err="Grpc(RpcFailure(RpcStatus { status: Unknown, details: Some("duplicated store address: id:1108427 address:\"10.43.8.26:20160\" version:\"3.0.0-rc.2\" , already registered by id:1087486 address:\"10.x.x.26:20160\" state:Offline version:\"3.0.0-rc.2\" ") }))"]
[2019/09/30 11:04:21.543 +08:00] [ERROR] [util.rs:327] ["request failed"] [err="Grpc(RpcFailure(RpcStatus { status: Unknown, details: Some("duplicated store address: id:1108427 address:\"10.x.x.26:20160\" version:\"3.0.0-rc.2\" , already registered by id:1087486 address:\"10.x.x.26:20160\" state:Offline version:\"3.0.0-rc.2\" ") }))"]
[2019/09/30 11:04:21.544 +08:00] [ERROR] [util.rs:327] ["request failed"] [err="Grpc(RpcFailure(RpcStatus { status: Unknown, details: Some("duplicated store address: id:1108427 address:\"10.x.x.26:20160\" version:\"3.0.0-rc.2\" , already registered by id:1087486 address:\"10.x.x.26:20160\" state:Offline version:\"3.0.0-rc.2\" ") }))"]
[2019/09/30 11:04:21.545 +08:00] [ERROR] [util.rs:327] ["request failed"] [err="Grpc(RpcFailure(RpcStatus { status: Unknown, details: Some("duplicated store address: id:1108427 address:\"10.x.x.26:20160\" version:\"3.0.0-rc.2\" , already registered by id:1087486 address:\"10.x.x.26:20160\" state:Offline version:\"3.0.0-rc.2\" ") }))"]
[2019/09/30 11:04:21.546 +08:00] [ERROR] [util.rs:327] ["request failed"] [err="Grpc(RpcFailure(RpcStatus { status: Unknown, details: Some("duplicated store address: id:1108427 address:\"10.x.x.26:20160\" version:\"3.0.0-rc.2\" , already registered by id:1087486 address:\"10.x.x.26:20160\" state:Offline version:\"3.0.0-rc.2\" ") }))"]
[2019/09/30 11:04:21.547 +08:00] [ERROR] [util.rs:327] ["request failed"] [err="Grpc(RpcFailure(RpcStatus { status: Unknown, details: Some("duplicated store address: id:1108427 address:\"10.x.x.26:20160\" version:\"3.0.0-rc.2\" , already registered by id:1087486 address:\"10.x.x.26:20160\" state:Offline version:\"3.0.0-rc.2\" ") }))"]
[2019/09/30 11:04:21.548 +08:00] [ERROR] [util.rs:327] ["request failed"] [err="Grpc(RpcFailure(RpcStatus { status: Unknown, details: Some("duplicated store address: id:1108427 address:\"10.x.x.26:20160\" version:\"3.0.0-rc.2\" , already registered by id:1087486 address:\"10.x.x.26:20160\" state:Offline version:\"3.0.0-rc.2\" ") }))"]
[2019/09/30 11:04:21.549 +08:00] [ERROR] [util.rs:327] ["request failed"] [err="Grpc(RpcFailure(RpcStatus { status: Unknown, details: Some("duplicated store address: id:1108427 address:\"10.x.x.26:20160\" version:\"3.0.0-rc.2\" , already registered by id:1087486 address:\"10.x.x.26:20160\" state:Offline version:\"3.0.0-rc.2\" ") }))"]
[2019/09/30 11:04:21.549 +08:00] [FATAL] [server.rs:285] ["failed to start node: Other(StringError("[src/pd/util.rs:335]: fail to request"))"]

pd监控下掉的tikv一直是offline状态。请问是什么原因，是否可以强制下掉。

beebol · 2019 年9 月 30 日 03:32

for i in `pd-ctl -u http://10.x.x.91:2379 -d region store 1087487 |grep -B 1 'start_key'|grep id|awk '{print $NF}'|sed 's/,//g'`; do pd-ctl -u http://10.x.x.91:2379 -d operator add remove-peer $i 1087487; done

再使用如上方法，将region peer 删除掉，正常为Tombstone Stores

beebol · 2019 年9 月 30 日 03:38

继续再观察监控

beebol · 2019 年9 月 30 日 07:19

自动均衡了20个region后就没有再均衡了

beebol · 2019 年10 月 1 日 15:11

[2019/10/01 15:18:13.204 +08:00] [ERROR] [process.rs:177] ["get snapshot failed"] [err="Request(message: "region epoch is not match" epoch_not_match { current_regions { id: 115500 start_key: "t\200\000\000\000\000\000\003\377\261_i\200\000\000\000\000\377\000\000\013\003\200\000\000\000\377]\221H>\004\000\000\000\377\000\000\000\000\000\003\200\000\377\000\000\000\000\000\000\004\000\377\000\000\000\000\000\004\014\003\377\200\000\000\000\000\000\000\225\377\003\200\000\000\000\030\3361\377K\000\000\000\000\000\000\000\370" end_key: "t\200\000\000\000\000\000\003\377\261_i\200\000\000\000\000\377\000\000\014\003\200\000\000\000\377T\337-4\001F4-\3777B-5E\377-6\3773-CC-E\3774\377\000\000\000\000\000\000\000\370\377\003\200\000\000\000\000\000\000\377\001\004\000\000\000\000\000\000\377\000g\003\200\000\000\000\000\377\000\000\037\003\200\000\000\000\377\002\0073T\000\000\000\000\373" region_epoch { conf_ver: 104 version: 559 } peers { id: 981019 store_id: 4 } peers { id: 1021766 store_id: 1005501 } peers { id: 1108504 store_id: 1108427 } } current_regions { id: 1109441 start_key: "t\200\000\000\000\000\000\003\377\261_i\200\000\000\000\000\377\000\000\013\003\200\000\000\000\377]\216\257t\004\000\000\000\377\000\000\000\000\000\003\200\000\377\000\000\000\000\000\001\004\000\377\000\000\000\000\000\004\014\003\377\200\000\000\000\000\000\000\221\377\003\200\000\000\000\030\331\t\377n\000\000\000\000\000\000\000\370" end_key: "t\200\000\000\000\000\000\003\377\261_i\200\000\000\000\000\377\000\000\013\003\200\000\000\000\377]\221H>\004\000\000\000\377\000\000\000\000\000\003\200\000\377\000\000\000\000\000\000\004\000\377\000\000\000\000\000\004\014\003\377\200\000\000\000\000\000\000\225\377\003\200\000\000\000\030\3361\377K\000\000\000\000\000\000\000\370" region_epoch { conf_ver: 104 version: 559 } peers { id: 1109442 store_id: 4 } peers { id: 1109443 store_id: 1005501 } peers { id: 1109444 store_id: 1108427 } } })"] [cid=69631]

新扩容上去的tikv报如上异常日志，是什么问题？会不会影响均衡？

CodeLess-PingCAP · 2019 年10 月 2 日 03:04

“region epoch is not match” 这种情况是因为 region 元信息发生变化（可能的原因有 region 调度、region split 等），而 region cache 还未及时更新。
region 调度一般是在该 region 不被频繁访问时调度，热 region 可能不会及时调度，但是对于冷 region 的调度应该不会影响的。
看您用的是 TiDB v3.0.0-beta 版本，建议升级至 3.0 GA 版本。

beebol · 2019 年10 月 10 日 07:14

可以升级到最新版本吗？

beebol · 2019 年10 月 10 日 10:27

不自动均衡是否和tikv节点不在同一网段的原因。同网段网络延迟0.1ms（老的4台tikv之间的网络延迟），新加的机器节点网络延迟是1.2ms

CodeLess-PingCAP · 2019 年10 月 10 日 12:39

如果是生产环境，建议先测试下再升级。

beebol · 2019 年10 月 11 日 06:09

升级到3.0.0 GA版本后，自动均衡正常。

程序员小王 · 2019 年10 月 11 日 07:13

升级到3.0.0 GA版本后，自动均衡正常。

system · 2022 年10 月 31 日 19:03

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。