TIKV彼此间是怎么感知的

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境
【 TiDB 版本】5.2.3
TIKV 有多台 他们可以选举LEDDER, 我想知道他们之间是怎样感知的，是有配置文件 ，还是有什么进程 ， 比如其中一台挂了，另外两台是否知道，是怎么知道的

2

TiKV节点宕机时，会通过Raft的选举机制感知，内置的Raft算法来实现多副本之间的数据一致性和高可用性

1 个赞
3

都是和pd节点来进行交互的，pd来管理tikv各个节点之间的状态

4

涉及PD的信息收集，生成调度以及执行调度：
信息收集中：TiKV 节点周期性地向 PD 上报 StoreHeartbeat 和 RegionHeartbeat 两种心跳消息：

  • StoreHeartbeat 包含 Store 的基本信息、容量、剩余空间和读写流量等数据。
  • RegionHeartbeat 包含 Region 的范围、副本分布、副本状态、数据量和读写流量等数据。PD 梳理并转存这些信息供调度进行决策。
1 个赞
5

tikv 和region leader 会定期上报给pd，

1 个赞
6

tikv状态会上报PD；tikv间有Raft的选举机制

1 个赞
7

通过PD，他们与PD之间有心跳连接的

8

本身有raft，挂了不是还有etcd感知

9

通过pd的

10

p d控制的

11

pd etcd

12

通过pd，pd是tidb的大脑。

13

有通信进程，进行选举，应该也会将选举结果放内存或者文件中吧

14

那PD是怎么知道 有三台TIKV 的，怎么能看到

15

通过PD，都要上报信息给PD的

16

tidb部署的时候编写的topology会存到pd吧，pd再通过heartbeat调度

17

TiKV Server：
是Tikv集群中的核心组件，负责数据存储和处理。每个TiKV Server实例承载多个Region，根据Region的元信息进行数据读写操作等。
TiKV Client：
是Tikv集群外部应用程序（如TiDB）和TiKV Server之间的接口，负责处理各种请求并将其转发给TiKV Server执行。
Region：
是Tikv存储数据的基本单位，每个Region承载一段特定的数据，并分布在TiKV集群的不同节点上。Region的ID、范围、所在的节点信息等元信息会存储在PD中，TiKV Client通过查询PD获取Region的元信息，从而确定数据所在的节点。
Store：
是TiKV集群中存储实例的基本单位，包括磁盘、内存等存储介质。每个Store负责存储和管理一部分Region的数据，每个Store由一个或多个TiKV Server实例组成。
raft服务器：
通过实现Raft协议来保证数据的一致性和高可用性，提升TiKV整体的可靠性和性能。
peer实例:
Peer节点通过Raft协议实现了数据复制与一致性维护，确保了Tikv集群的高可用性、容错性和数据一致性。

你说的这个是通过raft实现的

18

tikv 和region leader 会定期上报给pd，dp确定他们的状态

19

连接集群的大脑PD啊，都是PD控制的

20

通过PD调度，tikv会定期向PD汇报心跳情况，如果指定周期内pd收不到tikv的心跳信息，会默认该节点不可用，会把该节点上的leader节点分给其他节点，进行数据的读写