[转帖]TiKV 多副本丢失以及修复实践

tikv,副本,丢失,以及,修复,实践 · 浏览次数 : 0

小编点评

# tiup cluster display tidb-test5.3.7清理故障store的region清理方法： 在正常tikv（已经关闭掉）上执行命令： $ ./pd-ctl region --jq='.regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length as $total |map(if .==(4,497041,497042) then . else empty end|length>$total-length)}'{\"id\":164,\"peer_stores\":[4,497041,497042]}5.3.9.2停止实例停止10.12.16.225:20160 tikv实例（可以是其他任意正常的tikv实例）5.3.9.3根据上面查询出丢失的region id创建空region$ ./tikv-ctl --data-dir /data/tidb/tidb-data/tikv-20160 recreate-region -p 127.0.0.1:2379 -r 164命令输出结尾有success字样，说明创建成功5.3.9.4验证数据 原来总数为1024288，发现数据有丢失 5.3.10收尾$ tiup cluster display tidb-test » store delete 4Success!» store delete 497041Success!如果通过tiup cluster display tidb-test执行命令发现226、227、228上的store状态为up，说明开启了自动拉起$ tiup cluster prune tidb-test6总结1,如果region的单个副本丢失（小于replica一半的情况下），集群是不会丢失数据，此场景是绝大多数用户tikv挂掉场景；2,如果region多副本（副本数大于replica/2）丢失，如果开启sync-log=true则不会丢失数据，否则可能会丢失数据；3,如果region所有副本丢失，此时必定会丢失数据，需要进行破坏性修复；4,如果单机多tikv实例部署，一定需要打label，否则主机挂掉，region的多副本或者全部副本可能会丢失，从而导致丢失数据；

正文

https://tidb.net/blog/ad45bad9#6%E6%80%BB%E7%BB%93

 

 

1实验目的

随着tidb使用场景的越来越多，接入的业务越来越重要，不由得想试验下tidb组件的高可用性以及故障或者灾难如何恢复，恢复主要涉及的是pd组件和tikv组件，本文主要涉及tikv组件，

pd组件请参考另外一篇文章《pd集群多副本数据丢失以及修复实践》pd集群多副本数据丢失以及修复实践

2试验环境

2.1版本以及部署拓扑：

tidb版本：5.2.1

 
部署方式：tiup
 
部署拓扑

 

$ cat tidb-test.yaml
global:
  user: "tidb"
  ssh_port: 22
  deploy_dir: "/data/tidb/tidb-deploy"
  data_dir: "/data/tidb/tidb-data"

pd_servers:
  - host: 10.12.16.225
  - host: 10.12.16.226
  - host: 10.12.16.227

tidb_servers:
  - host: 10.12.16.225
  - host: 10.12.16.226
  - host: 10.12.16.227

tikv_servers:
  - host: 10.12.16.224
  - host: 10.12.16.225
  - host: 10.12.16.226
  - host: 10.12.16.227
  - host: 10.12.16.228

monitoring_servers:
  - host: 10.12.16.228

grafana_servers:
  - host: 10.12.16.228

alertmanager_servers:
  - host: 10.12.16.228

clipboard

 

 
5*TIKV

 

replica=3

温馨提示：

防止tiup部署后，在破坏掉tikv实例后，tikv-server被自动拉起来，影响试验效果，需要做如下修改

1、在/etc/systemd/system/tikv-20160.service中去掉 Restart=always或者改Restart=no，

2、执行systemctl daemon-reload 重新加载

2.2查看测试表数据

CREATE TABLE `t_test` (
  `name` varchar(200) DEFAULT '',
  `honor` varchar(200) DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin /*T! SHARD_ROW_ID_BITS=4 PRE_SPLIT_REGIONS=4 */

mysql> desc t_test;
+-------+--------------+------+------+---------+-------+
| Field | Type         | Null | Key  | Default | Extra |
+-------+--------------+------+------+---------+-------+
| name  | varchar(200) | YES  |      |         |       |
| honor | varchar(200) | YES  |      |         |       |
+-------+--------------+------+------+---------+-------+
2 rows in set (0.00 sec)

mysql> select count(*) from t_test;
+----------+
| count(*) |
+----------+
|  1024288 |
+----------+
1 row in set (3.68 sec)

3单副本损毁及修复

过程略

提示：

此种场景也是最常见的场景，replica>=3的时候，不会影响业务读写，也不会丢失数据，只需要扩容新TiKV节点，缩容下线故障节点即可。

如果是3*TiKV集群，必须只能先扩容，否则此时即便强制缩容下线故障节点，数据也不会发生replica均衡调度，因为无法补齐三副本。

4双副本同时损毁及修复

4.1查看测试表region分布

clipboard

mysql> select STORE_ID,ADDRESS,LEADER_COUNT,REGION_COUNT from information_schema.TIKV_STORE_STATUS ;
+----------+--------------------+--------------+--------------+
| STORE_ID | ADDRESS            | LEADER_COUNT | REGION_COUNT |
+----------+--------------------+--------------+--------------+
|        1 | 10.12.16.228:20160 |           12 |           25 |
|        2 | 10.12.16.225:20160 |           11 |           33 |
|        4 | 10.12.16.226:20160 |            9 |           14 |
|        3 | 10.12.16.227:20160 |            6 |           38 |
|        9 | 10.12.16.224:20160 |            7 |           25 |
+----------+--------------------+--------------+--------------+
5 rows in set (0.01 sec)

clipboard

 

 

 

clipboard

4.2模拟2个tikv同时损坏

同时损坏的TiKV节点是10.12.16.227:20160和10.12.16.228:20160

在10.12.16.227（store_id=3）和10.12.16.228（store_id=1）上分别执行


$ cd /data/tidb/tidb-data/
$ ls
monitor-9100 pd-2379 tikv-20160
$ rm -rf tikv-20160
$ ls
monitor-9100 pd-2379

查看集群状态：

clipboard

查看store_id=3和store_id=1的状态：

clipboard

可以发现30分钟过后（store的状态从disconnecting–》down），store 1和3上的region的leader和replica还存在，并不是因为store是down状态，其上面的regionleader和replica进行切换和调度，那是因为部分region同时失去两个副本，导致无法发生leader选举。

mysql> select count(*) from t_test;

ERROR 9002 (HY000): TiKV server timeout

clipboard

tidb查询发现hang住直到超时

4.3修复tidb集群

4.3.1关闭调度

关闭调度原因：防止恢复期间出现其他的异常情况

关闭调度方法：config set region-schedule-limit、replica-schedule-limit、leader-schedule-limit、merge-schedule-limit 这4个值

» config set region-schedule-limit 0
» config set replica-schedule-limit 0
» config set leader-schedule-limit 0
» config set merge-schedule-limit 0
4.3.2查询出大多数副本在故障tikv上的region id

检查大于等于一半副本数在故障节点（store_id in(1,3)）上的region，并记录它们的region id

$ ./pd-ctl region --jq='.regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length as $total |map(if .==(1,3) then . else empty end)|length>=$total-length)}'

clipboard

4.3.3关闭正常的tikv节点
$ tiup cluster stop    tidb-test  -N 10.12.16.224:20160
$ tiup cluster stop    tidb-test  -N 10.12.16.225:20160
$ tiup cluster stop    tidb-test  -N 10.12.16.226:20160

clipboard

4.3.4清理故障store的region

清理方法：

在正常的tikv（已经关闭掉）上执行命令：

$ ./tikv-ctl --data-dir /data/tidb/tidb-data/tikv-20160 unsafe-recover remove-fail-stores -s 1,3 --all-regions

执行命令在输出的结尾有success字样，说明执行成功

清理原因：在正常tikv上清理掉region peer落在故障tikv（1和3）peer

4.3.5重启pd集群
$ tiup cluster restart    tidb-test  -R pd

查看store 1和store 3

clipboard

发现上面的leader_count和region_count都变成0，如果pd集群不重启，则不会消失。

4.3.6启动正常的tikv节点
$ tiup cluster start    tidb-test  -N 10.12.16.224:20160
$ tiup cluster start    tidb-test  -N 10.12.16.225:20160
$ tiup cluster start    tidb-test  -N 10.12.16.226:20160

clipboard

查看副本数为2的region：

$ ./pd-ctl region --jq='.regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length==2) } '
{"id":36,"peer_stores":[2,9]}
{"id":140,"peer_stores":[2,9]}
{"id":249,"peer_stores":[2,4]}
{"id":46,"peer_stores":[2,9]}
{"id":168,"peer_stores":[2,9]}
{"id":176,"peer_stores":[2,9]}
{"id":188,"peer_stores":[4,9]}
{"id":48,"peer_stores":[9,2]}
{"id":184,"peer_stores":[2,9]}
{"id":26,"peer_stores":[2,9]}
{"id":152,"peer_stores":[4,2]}
{"id":52,"peer_stores":[2,4]}
{"id":40,"peer_stores":[4,2]}
{"id":253,"peer_stores":[4,9]}
{"id":44,"peer_stores":[2,9]}

查看只有单副本的region：

$ ./pd-ctl region --jq='.regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length==1) } '
{"id":42,"peer_stores":[2]}
{"id":62,"peer_stores":[9]}
{"id":192,"peer_stores":[9]}
{"id":180,"peer_stores":[2]}
{"id":196,"peer_stores":[2]}
{"id":60,"peer_stores":[9]}
{"id":160,"peer_stores":[2]}
{"id":164,"peer_stores":[4]}
{"id":54,"peer_stores":[9]}
{"id":172,"peer_stores":[2]}
{"id":220,"peer_stores":[2]}
{"id":7,"peer_stores":[9]}
{"id":50,"peer_stores":[9]}
{"id":144,"peer_stores":[9]}
{"id":156,"peer_stores":[2]}
{"id":38,"peer_stores":[2]}
{"id":56,"peer_stores":[2]}
4.3.7打开调度
config set region-schedule-limit  2048
config set replica-schedule-limit 64
config set leader-schedule-limit  4
config set merge-schedule-limit   8
4.3.8验证数据
$ ./pd-ctl region --jq='.regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length as $total |map(if .==(1,3) then . else empty end)|length>=$total-length)}'

输出为空

 
clipboard
 
数据已经可以查询，并且数据没有丢失

 

查看只有单副本的region：

clipboard

 

 
查看副本数为2的region：
 

 

clipboard

4.3.9清理收尾

发现store 1和3还是存在（状态为Down），需要在集群中剔除掉

clipboard

删除掉store 1和3

» store delete 1
Success!
» store delete 3
Success!

clipboard

clipboard

$ tiup cluster prune tidb-test
$ tiup cluster display tidb-test

clipboard

 

 
发现227和228已经不在集群

 

至此，双副本同时丢失的情景已经修复完毕

5三副本同时损毁及修复

5.1查看测试表region分布

$ ./pd-ctl region --jq='.regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length==3) } '
{"id":220,"peer_stores":[2,9,497041]}
{"id":249,"peer_stores":[2,4,497042]}
{"id":7,"peer_stores":[9,497041,497042]}
{"id":36,"peer_stores":[2,9,497041]}
{"id":140,"peer_stores":[2,497042,497041]}
{"id":144,"peer_stores":[9,497042,2]}
{"id":156,"peer_stores":[2,4,497042]}
{"id":168,"peer_stores":[2,9,497042]}
{"id":176,"peer_stores":[2,497042,4]}
{"id":188,"peer_stores":[497042,9,497041]}
{"id":38,"peer_stores":[2,9,497041]}
{"id":46,"peer_stores":[9,2,497041]}
{"id":50,"peer_stores":[9,497041,497042]}
{"id":48,"peer_stores":[2,9,497041]}
{"id":56,"peer_stores":[9,497041,497042]}
{"id":184,"peer_stores":[2,9,497041]}
{"id":152,"peer_stores":[4,9,497041]}
{"id":192,"peer_stores":[9,497042,497041]}
{"id":26,"peer_stores":[497042,497041,2]}
{"id":42,"peer_stores":[2,9,497042]}
{"id":62,"peer_stores":[9,497041,497042]}
{"id":180,"peer_stores":[2,9,497042]}
{"id":196,"peer_stores":[2,497041,497042]}
{"id":22,"peer_stores":[4,497042,9]}
{"id":52,"peer_stores":[4,497042,9]}
{"id":148,"peer_stores":[4,9,497041]}
{"id":40,"peer_stores":[4,9,497042]}
{"id":160,"peer_stores":[2,9,497041]}
{"id":164,"peer_stores":[4,497041,497042]}
{"id":253,"peer_stores":[4,2,497042]}
{"id":257,"peer_stores":[4,9,497041]}
{"id":34,"peer_stores":[4,497041,497042]}
{"id":58,"peer_stores":[4,497042,9]}
{"id":60,"peer_stores":[9,497041,497042]}
{"id":44,"peer_stores":[2,9,497041]}
{"id":54,"peer_stores":[9,497041,497042]}
{"id":172,"peer_stores":[497041,9,497042]}
mysql> select count(*) from t_test;
+----------+
| count(*) |
+----------+
|  1024288 |
+----------+
1 row in set (0.14 sec)

mysql> select count(*) from t_test;

+----------+

| count(*) |

+----------+

| 1024288 |

+----------+

1 row in set (0.14 sec)

5.2模拟3个（所有副本）tikv同时损坏

模拟10.12.16.226:20160 10.12.16.227:20160 10.12.16.228:20160三个tikv节点同时挂掉

在226、227、228上执行：


$ cd /data/tidb/tidb-data
$ ls
monitor-9100 pd-2379 tikv-20160
$ rm -rf tikv-20160
$ ls
monitor-9100 pd-2379

查看集群状态：

$ tiup cluster display tidb-test

clipboard

5.3修复tidb集群

5.3.1关闭调度
config set region-schedule-limit 0
config set replica-schedule-limit 0
config set leader-schedule-limit 0
config set merge-schedule-limit 0
5.3.2查询出三个（所有）副本在故障tikv上的region id
mysql> select STORE_ID,ADDRESS,LEADER_COUNT,REGION_COUNT,STORE_STATE_NAME from information_schema.TIKV_STORE_STATUS order by STORE_STATE_NAME;
+----------+--------------------+--------------+--------------+------------------+
| STORE_ID | ADDRESS            | LEADER_COUNT | REGION_COUNT | STORE_STATE_NAME |
+----------+--------------------+--------------+--------------+------------------+
|   497041 | 10.12.16.228:20160 |            2 |           25 | Disconnected     |
|   497042 | 10.12.16.227:20160 |            2 |           26 | Disconnected     |
|        4 | 10.12.16.226:20160 |           12 |           13 | Disconnected     |
|        2 | 10.12.16.225:20160 |           11 |           19 | Up               |
|        9 | 10.12.16.224:20160 |           10 |           28 | Up               |
+----------+--------------------+--------------+--------------+------------------+
5 rows in set (0.00 sec)

image

5.3.3关闭正常的tikv节点
$ tiup cluster stop    tidb-test  -N 10.12.16.224:20160
$ tiup cluster stop    tidb-test  -N 10.12.16.225:20160
$ tiup cluster display    tidb-test

clipboard

5.3.4清理故障store的region

清理方法：

在正常的tikv（已经关闭掉）上执行命令：

$ ./tikv-ctl --data-dir /data/tidb/tidb-data/tikv-20160 unsafe-recover remove-fail-stores -s 4,497041,497042 --all-regions

执行命令在输出的结尾有success字样，说明执行成功

清理原因：在正常tikv上清理掉region peer落在故障tikv（4,497041,497042）peer

5.3.5重启pd集群
$ tiup cluster restart    tidb-test  -R pd
5.3.6启动正常的tikv节点
$ tiup cluster start    tidb-test  -N 10.12.16.224:20160
$ tiup cluster start    tidb-test  -N 10.12.16.225:20160
$ tiup cluster display    tidb-test

clipboard

5.3.7打开调度
config set region-schedule-limit  2048
config set replica-schedule-limit 64
config set leader-schedule-limit  4
config set merge-schedule-limit   8
5.3.8验证数据

image

mysql> select count(*) from t_test;

ERROR 9005 (HY000): Region is unavailable

clipboard

5.3.9补偿所有副本都丢失的region
5.3.9.1查询所有副本都丢失的region，并记录region id
$ ./pd-ctl region --jq='.regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length as $total |map(if .==(4,497041,497042) then . else empty end)|length>$total-length)}'
{"id":164,"peer_stores":[4,497041,497042]}

clipboard

5.3.9.2停止实例

停止10.12.16.225:20160 tikv实例（可以是其他任意正常的tikv实例）

5.3.9.3根据上面查询出丢失的region id创建空region
$ ./tikv-ctl --data-dir /data/tidb/tidb-data/tikv-20160 recreate-region -p 127.0.0.1:2379 -r 164

命令输出结尾有success字样，说明创建成功

5.3.9.4验证数据

clipboard

 
原来总数为1024288，发现数据有丢失

 

5.3.10收尾
$ tiup cluster display    tidb-test

clipboard

» store delete 4
Success!
» store delete 497041
Success!
» store delete 497042
Success!

如果通过tiup cluster display tidb-test执行命令发现226、227、228上的store状态为up，说明开启了自动拉起

$ tiup cluster prune tidb-test

6总结

1、如果region的单个副本丢失（小于replica一半的情况下），集群是不会丢失数据，此场景是绝大多数用户tikv挂掉场景；

2、如果region多副本（副本数大于replica/2）丢失，如果开启sync-log=true则不会丢失数据，否则可能会丢失数据；

3、如果region所有副本丢失，此时必定会丢失数据，需要进行破坏性修复；

4、如果单机多tikv实例部署，一定需要打label，否则主机挂掉，region的多副本或者全部副本可能会丢失，从而导致丢失数据；

tikv 副本 丢失 以及 修复 实践

与[转帖]TiKV 多副本丢失以及修复实践相似的内容：

[转帖]TiKV 多副本丢失以及修复实践

https://tidb.net/blog/ad45bad9#6%E6%80%BB%E7%BB%93 1实验目的 随着tidb使用场景的越来越多，接入的业务越来越重要，不由得想试验下tidb组件的高可用性以及故障或者灾难如何恢复，恢复主要涉及的是pd组件和tikv组件，本文主要涉及tikv组件， p

tikv 副本 丢失 以及
0
[转帖]TiDB-unsafe recover(三台tikv宕机两台)

一、背景 名称数量tikv3副本3 1.故障： 因为某些原因，两台tikv不可连接，出现region不能访问的故障 2.几条理论： 2.1.多副本原则 存在一半以上的副本则集群访问不受影响（如n副本，存活（n+1）/ 2） 2.2.数据完整性 当副本数量等于tikv的数量的时候，每一个tikv都有全

tidb unsafe recover 三台
0
[转帖]TiKV & TiDB相关笔记

https://www.jianshu.com/p/1141be233bb2 一、TiKV存储 简述 通过单机的 RocksDB，TiKV 可以将数据快速地存储在磁盘上；通过 Raft，将数据复制到多台机器上，以防单机失效。数据的写入是通过 Raft 这一层的接口写入，而不是直接写 RocksDB。

tikv tidb 相关 笔记
0
[转帖]TiKV集群搭建

https://www.cnblogs.com/luohaixian/p/15227788.html 1.准备环境 准备4台ubuntu 16.04虚拟机 部署规划： 节点类型 CPU 内存 存储 部署数量 所在节点IP TiKV 8 core 8 GB 200GB 3 10.10.10.2 10.

tikv 集群 搭建
0
[转帖]TiKV读写流程浅析

https://www.cnblogs.com/luohaixian/p/15227838.html 1.TiKV框架图和模块说明 图1 TiKV整体架构图 1.1.各模块说明 PD Cluster：它是由多个PD节点组成的etcd集群，PD是具有“上帝视角”的管理组件，负责存储元数据和进行负载均衡

tikv 读写 流程 浅析
0
[转帖]TiKV 内存参数性能调优

https://docs.pingcap.com/zh/tidb/stable/tune-tikv-memory-performance 本文档用于描述如何根据机器配置情况来调整 TiKV 的参数，使 TiKV 的性能达到最优。你可以在 etc/config-template.toml 找到配置文件

tikv 内存 参数 性能
0
[转帖]TiKV 缩容不掉如何解决？

https://tidb.net/book/tidb-monthly/2022/2022-04/usercase/tikv TiKV节点缩容不掉，通常遇到的情况： 1、经常遇到的情况是：3个节点的tikv集群缩容肯定会一直卡着，因为没有新节点接受要下线kv的region peer。 2、另外就是除缩

tikv 不掉 如何 解决
0
[转帖]TiKV Control 使用说明

https://docs.pingcap.com/zh/tidb/stable/tikv-control TiKV Control（以下简称 tikv-ctl）是 TiKV 的命令行工具，用于管理 TiKV 集群。它的安装目录如下： 如果是使用 TiUP 部署的集群，在 ~/.tiup/compon

tikv control 使用 说明
0
[转帖]TiKV & TiFlash 加速复杂业务查询丨TiFlash 应用实践

返回全部 边城元元案例实践2022-08-02 复杂业务查询对于传统的关系型数据库来说是一种考验，而通过 TiKV 行存与 TiFlash 的列存结合使用就能很好地应对。本文根据 TUG 用户边城元元在 TiDB 社区技术交流石家庄站的分享整理，详细介绍了 TiKV & TiFlash 加速复杂业务

tikv tiflash 加速 复杂
0
[转帖]TiKV & TiDB相关笔记

https://www.jianshu.com/p/1141be233bb2 一、TiKV存储 简述 通过单机的 RocksDB，TiKV 可以将数据快速地存储在磁盘上；通过 Raft，将数据复制到多台机器上，以防单机失效。数据的写入是通过 Raft 这一层的接口写入，而不是直接写 RocksDB。

tikv tidb 相关 笔记
0
# 热门排行
微软 New Bing AI 申请与使用保姆级教程（免魔法） ChatGPT API使用介绍 ChatGPT开发实战 一篇带你了解如何使用纯前端类Excel表格构建现金流量表 手把手教你玩转 Excel 数据透视表 为什么 C# 可能是最好的第一编程语言 .NET 入门到高级路线 提高工作效率的神器：基于前端表格实现Chrome Excel扩展插件 React + Springboot + Quartz，从0实现Excel报表自动化 用Echarts实现前端表格引用从属关系可视化
© PmDaddy. 2023 PmDaddy教程网 All rights reserved.