TIKV彼此间是怎么感知的

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

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

1 个赞

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

涉及PD的信息收集,生成调度以及执行调度:
信息收集中:TiKV 节点周期性地向 PD 上报 StoreHeartbeatRegionHeartbeat 两种心跳消息:

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

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

1 个赞

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

1 个赞

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

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

通过pd的

p d控制的

pd etcd

通过pd,pd是tidb的大脑。

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

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

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

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

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实现的

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

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

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