replace-down-replica与replace-offline-replica的区别

🪐 TiDB 技术问题
1

因为之前的操作失误
集群是三副本，有2个tikv实例–force下线了
pd创建了很多operator任务，
主要有replace-down-replica与replace-offline-replica，
发现replace-down-replica的都正常结束了，耗时只要2 3秒
但是replace-offline-replica任务都timeout了，而且超时时间都在10分钟
请问这2个operator有什么区别

2 个赞
2

可以参考已有的FAQ

6 个赞
3

这个是store状态
我问的是这2个operator之间的区别
这2个operator我看做的事情的step都是一样的 但是一个很快一个一直在超时
我在测试环境模拟，已经把replace-offline-replica直接禁用了，region迁移速度提高了15倍
之前虽然提高了replica-schedule-limit这个参数的值
但是我用operator show 看全阻塞住了 最后看pd日志全是replace-offline-replica超时

2 个赞
4

我理解的down-replica是宕机状态的副本，offline-replica是下线状态的副本

1 个赞
5

是这么个道理 但是我找不到官方哪里有定义

1 个赞
6

官方文档中只找到两个类似的说明

  • enable-replace-offline-replica 用于开启迁移 OfflineReplica 的特性。当设置为 false 时，PD 不会迁移下线状态的副本。
  • enable-remove-down-replica 用于开启自动删除 DownReplica 的特性。当设置为 false 时，PD 不会自动清理宕机状态的副本。
3 个赞
7

enable-replace-offline-replica如果把这个设置为false 会有什么影响吗

1 个赞
8

上面描述了，为false时不会迁移下线状态的副本。如果副本一直不上线，应该是会有问题吧。

1 个赞
9

我确实搞不明白down-peer跟offline-peer的区别，因为我不小心执行了–offline,所以有2个store的数据已经恢复不了，在这2个store上的副本也上不了线了

1 个赞
10

哦哦，是那个缩容两个实例的么？缩容之后要等均衡结束就可以了。

1 个赞
11

是的。 但是他自动的调度包括主要包括2种operator

一种是replace-offline-replica,这个看看日志全部超时了，超时要10分钟，然后看operator show所有的线程全部阻塞住了
就算调大了replica-schedule-limit的值，所有的线程还是都会阻塞住

另一种是replace-down-replica,这个看日志全部finish了，而且耗时只要1-2秒。

看日志2个operator做的事情差不多。
看region check down-peer跟region check offline-peer2个打印很多都是重复的。
我们想确定下这种情况下如果把enable-replace-offline-replica设置为false会不会有影响

求大神帮忙啊！

2 个赞
12

replace-offline-replica 是在下线之前的调度模式，会把当前节点上的副本调度到其他节点上，满足平衡要求
replace-down-replica 是节点已经无法联系上了，会从其他的节点上寻找副本执行调度

两种模式不一样

你现在的目标是啥？

1 个赞
13

我现在要加快调度，因为还剩下11000多个region调度，非常慢。

1 个赞
14

先补齐tikv 的节点数，然后在加速调度

1 个赞
15

能加下qq或者微信吗。如果能解决我的疑问，我愿意付费的，我的qq是429882405

1 个赞
16

先在没补齐，先在就是32个减掉2个还剩下30个tikv实例

1 个赞
17
  • 如果你需要获得快速 “加急”处理问题的权限，加快问题响应速度， 点击完成认证，获得“加急”处理问题的权限，方便你更快速地解决问题。
1 个赞
18

认证后在 导航栏：我的团队-全部主题-加急，直接加急你的问题 。

1 个赞
19

根据你之前说的这个工作原理，我好像总结出来了。

比如下线了storeA,迁移的region是regionB.
replace-offline-replica是正常下线的调度模式，就是那个tikv实例还在正常工作。
所以他调度是这样的
如果这个下线的副本是leader，他会把leader先传给其他正常工作的副本，然后再执行找一个store新增regionB副本,给这个副本增加投票权，然后删除下线的storeA上的peer。这样就能维持regionB三个副本正常工作
如果这个下线的副本不是leader,就省去了传递leader给其他副本的步骤，后面一致

replace-down-replica是storeA失联半小时后的调度模式，就是storeA已经不能正常工作了。
这时候pd会找regionB一个可用的副本，然后找一个新的store新增regionB的副本，然后给这个副本增加投票权，然后删除storeA上的副本。
然后会有第二个操作，就是重新选举leader。

2 个赞
20

现在我们的现象是，我们通过–force强制下线了2个store
这2个store用display查看已经看不到了
但是在Pd-ctl里面用查看还是offlline状态

现在用pd-ctl查看region check offline-peer能查到很多。

例如这样的，67706533跟67706532是已经强制下线的store。
剩下的67706529这个是正常运行的store。所以有一个副本是正常的

“id”: 90538340,
“start_key”: “7480000000000077FF375F72A000000002FFB9EA660000000000FA”,
“end_key”: “7480000000000077FF375F72A000000003FF9E9BCF0000000000FA”,
“epoch”: {
“conf_ver”: 54893,
“version”: 16850
},
“peers”: [
{
“id”: 90538341,
“store_id”: 67706533
},
{
“id”: 90538342,
“store_id”: 67706532
},
{
“id”: 90538343,
“store_id”: 67706529
}
],

这样的 他会通过replace-offline-replica这样的operator来迁移，但是这个是当作offline了，因为67706533跟67706532对应的tikv实例已经没有了，服务也不存在，端口也没监听，所以他一直堵塞，直到10分钟超时。
现在有没有办法处理这些offline-peer
求帮助

1 个赞