Get desktop application:
View/edit binary Protocol Buffers messages
Used in:
,Use `BatchSplit` instead.
Command that updates RegionLocalState.gc_peers
Used in:
, ,Used in:
, ,UpdateGcPeer doesn't need to be responded. Avoid consuming a tag number.
Used in:
If true, the last region derive the origin region_id, other regions use new ids.
It should be false iff the region split by user key such as split table or create partion table etc, the new region's will not share the source region size, so it's region size is zero. It should be true iff the region's load reaches the threshold such as size, keys, load check etc, the new region's size will share the origin region, so it's region size is half of the source region.
Used in:
Used in:
Used in:
(message has no fields)
Used in:
,This can be only called in internal RaftStore now.
Used in:
Used in:
Used in:
Used in:
,Used in:
Used in v2. When it's present, `source` and `commit` will not be set.
Used in:
(message has no fields)
Used in:
Used in:
(message has no fields)
Used in:
Used in:
Used in:
(message has no fields)
Used in:
Used in:
(message has no fields)
Used in:
(message has no fields)
Used in:
(message has no fields)
Used in:
Used in:
Used in:
Used in:
(message has no fields)
Used in:
The start_ts that the current flashback progress is using.
Used in:
(message has no fields)
Used in:
Used in:
(message has no fields)
Used in:
Used in:
(message has no fields)
Used in:
Used in:
(message has no fields)
We can't enclose normal requests and administrator request at same time.
Used in:
true for read linearization
16 bytes, to distinguish request.
Read requests can be responsed directly after the Raft applys to `applied_index`.
Custom flags for this raft request.
Used in:
Used in:
In replica read, leader uses start_ts and key_ranges to check memory locks.
Used in:
The memory lock blocking this read at the leader
For getting more information of the region. We add some admin operations (ChangePeer, Split...) into the pb job list, then pd server will peek the first one, handle it and then pop it from the job lib. But sometimes, the pd server may crash before popping. When another pd server starts and finds the job is running but not finished, it will first check whether the raft server already has handled this job. E,g, for ChangePeer, if we add Peer10 into region1 and find region1 has already had Peer10, we can think this ChangePeer is finished, and can pop this job from job list directly.
Used in:
(message has no fields)
Used in:
For get the leader of the region.
Used in:
(message has no fields)
Used in:
Used in:
,Used in:
Used in:
Used in:
(message has no fields)
Used in:
(message has no fields)
Used in:
Used in:
,This can be only called in internal RaftStore now. The split_key must be in the been splitting region.
We split the region into two, first uses the origin parent region id, and the second uses the new_region_id. We must guarantee that the new_region_id is global unique.
The peer ids for the new split region.
If true, right region derive the origin region_id, left region use new_region_id. Will be ignored in batch split, use `BatchSplitRequest::right_derive` instead.
It should be false iff the region split by user key such as split table or create partion table etc, the new region's will not share the source region size, so it's region size is zero. It should be true iff the region's load reaches the threshold such as size, keys, load check etc, the new region's size will share the origin region, so it's region size is half of the source region.
Used in:
Used in:
,Used in:
Used in:
Used in:
Used in:
Used in:
(message has no fields)
Used in:
Used in:
Used in:
(message has no fields)