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

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

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

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

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


观察还没有正常均衡

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

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

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状态。 请问是什么原因,是否可以强制下掉。

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

1赞

image

继续再观察监控

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

[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报如上异常日志,是什么问题?会不会影响均衡?

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

可以升级到最新版本吗?

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

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

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

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