h5n1
h5n1
V10
联通软件研究院DBA
2021-04-20 加入
获赞
991
回答
2254
文章
18
    现在啥情况了
    17 小时前
    该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。
    1 天前
    你是配置了5副本吗,把脚本输出结果 找几个region_id 在确认下,pd-ctl region xxxx 看下输出的store_id是不是全是之前处理的那些,是的话就可以 recreate , 参考下面 :
    2 天前
    之前下线的store 你不是已经做过unsafe recover了吗,现在是把那些在3个副本都在offline store里的region,然后把这些region recreate 后看看能否把down的tikv拉起来
    2 天前
    down是因为暂时起不来,先不要动呢。 offline没正常缩容完你就删了目录的话,up也不好使了
    2 天前
    down的不算,就你做过缩容、store delete 、unsafe recover的,你这些offline 还有没有数据目录没被删除的 ,哟的话 改为up状态停止缩容: curl -X POST http://:/pd/api/v1/store/<store_id>/state?state=Up
    2 天前
    store 列表里,你先找那些你下线的 、store delete 操作的节点,之前这些不是都unsafe recover了
    2 天前
    看你现在的操作不止是 .9 .10上做了缩容操作 .123上也做了, 在同一主机上的tikv应设置相同的label 保障同一主机上不会有相同region的副本,避免出现多副本失败的情况,你现在一下弄了这么多store 肯定有很多全副本丢失了, 多副本恢复的步骤是在 所有正常的tikv上去unsafe recover 下线的store,你先 按下面 故障节点为store id 1,5,6): pd-ctl region --jq=".regions\[] | {id: .id, peer\_stores: \[.peers\[].store\_id] | select(length as …
    2 天前
    你最初缩容怎么做的? 你看前面链接文章里找下 查找3个副本都没有的 脚本,然后检查下看看有多少全丢失的region,这些得重建里面数据肯定没了
    2 天前
    是只处理了这一个store吧,之前有缩容了几个?
    2 天前
    前面是15698413 后面就成了34673997 ,能贴个tiup display完整输出吗
    2 天前
    你现在看的store和前面的不一样啊,
    2 天前
    现在什么状态?做了哪些
    2 天前
    第三步在每个正常的tikv执行
    2 天前
    说下你的操作过程 ,还有tiup display的完整输出
    2 天前
    你有几个tikv,几个正常的? 估计你这得做多副本失败恢复,把有问题的store 剔除 参考以下几个:
    2 天前
    如果仅仅是强制下线了1个tikv节点,按理说不应该这样,他还有2个副本呢 ,你先手动添加remove peer命令,把下线节点上的peer移除。 参考下面脚本- for i in {下线store_id} do for j in pd-ctl region store $i | jq ".regions[] | {id: .id}"|grep id|awk '{print $2}' do pd-ctl operator add remove-peer $j $i done pd-ctl store $i done 然后pd-ctl 观察store的状态和region cou…
    2 天前
    store delete id 只是把tikv变为offline状态,在此期间会转移region和leader ,之后变成tombestone状态执行tiup cluster prune就好了。 tidb报找不到region是因为 因为tikv下线 leader和region转移了,导致tidb 的region cache 失效,tidb会自动重试这是正常机制。从你的描述来看应该是之前有tikv下线没完成,现在又做了tidb server的缩容,tiup cluster display xx 先看下集群状态
    2 天前