Get desktop application:
View/edit binary Protocol Buffers messages
Leader Peer sending the heartbeat.
Term is the term of raft group.
Leader considers that these peers are down.
Pending peers are the peers that the leader can't consider as working followers.
Bytes read/written during this period.
Keys read/written during this period.
Approximate region size.
Approximate number of keys.
QueryStats reported write query stats, and there are read query stats in store heartbeat
Actually reported time interval
ID of the region
Leader of the region at the moment of the corresponding request was made.
Notice, Pd only allows handling reported epoch >= current pd's. Leader peer reports region status with RegionHeartbeatRequest to pd regularly, pd will determine whether this region should do ChangePeer or not. E,g, max peer number is 3, region A, first only peer 1 in A. 1. Pd region state -> Peers (1), ConfVer (1). 2. Leader peer 1 reports region state to pd, pd finds the peer number is < 3, so first changes its current region state -> Peers (1, 2), ConfVer (1), and returns ChangePeer Adding 2. 3. Leader does ChangePeer, then reports Peers (1, 2), ConfVer (2), pd updates its state -> Peers (1, 2), ConfVer (2). 4. Leader may report old Peers (1), ConfVer (1) to pd before ConfChange finished, pd stills responses ChangePeer Adding 2, of course, we must guarantee the second ChangePeer can't be applied in TiKV.
Pd can return transfer_leader to let TiKV does leader transfer itself.
PD sends split_region to let TiKV split a region into two regions.
Multiple change peer operations atomically. Note: PD can use both ChangePeer and ChangePeerV2 at the same time (not in the same RegionHeartbeatResponse). Now, PD use ChangePeerV2 in following scenarios: 1. replacing peers 2. demoting voter directly
If group is defined, the regions with the same group would be scattered as a whole group. If not defined, the regions would be scattered in a cluster level.
If regions_id is defined, the region_id would be ignored.
Used in:
Used in:
name is the unique name of the scheduling participant.
id is the unique id of the scheduling participant.
listen_urls is the serivce endpoint list in the url format. listen_urls[0] is primary service endpoint.
Used in:
, , , , ,cluster_id is the ID of the cluster which be sent to.
sender_id is the ID of the sender server.
Used in:
, , , , ,cluster_id is the ID of the cluster which sent the response.