-
Notifications
You must be signed in to change notification settings - Fork 63
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add PD scheduling best practices and glossary
- Loading branch information
anotherrachel
committed
Dec 13, 2019
1 parent
c6b7746
commit bbe0318
Showing
2 changed files
with
335 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,68 @@ | ||
--- | ||
title: Glossary | ||
summary: Glossaries about TiKV. | ||
menu: | ||
docs: | ||
parent: Concepts | ||
weight: 3 | ||
--- | ||
|
||
## L | ||
|
||
### leader/follower/learner | ||
|
||
Leader/Follower/Learner each corresponds to a role in a Raft group of [peers](#regionpeerraft-group). The leader services all client requests and replicates data to the followers. If the group leader fails, one of the followers will be elected as the new leader. Learners are non-voting followers that only serves in the process of replica addition. | ||
|
||
## O | ||
|
||
### operator | ||
|
||
An operator is a collection of actions that applies to a region for scheduling purposes. Operators perform scheduling tasks such as "migrate the leader of Region 2 to Store 5" and "migrate replicas of Region 2 to Store 1, 4, 5". | ||
|
||
An operator can be computed and generated by a [scheduler](#scheduler), or created by an external API. | ||
|
||
### operator step | ||
|
||
An operator step is a step in the execution of an operator. An operator normally contains multiple Operator steps. | ||
|
||
Currently, available steps generated by PD include: | ||
|
||
- `TransferLeader`: Transfers leadership to a specified member | ||
- `AddPeer`: Adds peers to a specified store | ||
- `RemovePeer`: Removes a peer of a region | ||
- `AddLearner`: Adds learners to a specified store | ||
- `PromoteLearner`: Promotes a specified learner to a voting member | ||
- `SplitRegion`: Splits a specified region into two | ||
|
||
## P | ||
|
||
### pending/down | ||
|
||
"Pending" and "down" are two special states of a peer. Pending indicates that the Raft log of followers or learners is vastly different from that of the leader. Followers in pending cannot be elected as leader. "Down" refers to a state that a peer ceases to respond to the leader for a long time, which usually means the corresponding node is down or isolated from the network. | ||
|
||
## R | ||
|
||
### region/peer/Raft group | ||
|
||
Region is the minimal piece of data storage in TiKV, each representing a range of data (96 MiB by default). Each region has three replicas by default. A replica of a region is called a peer. Multiple peers of the same region replicate data via the Raft consensus algorithm, so peers are also members of a Raft instance. TiKV uses Multi-Raft to manage data. That is, for each region, there is a corresponding, isolated Raft group. | ||
|
||
### region split | ||
|
||
Regions are generated as data writes increase. The process of splitting is called region split. | ||
|
||
The mechanism of region split is to use one initial region to cover the entire key space, and generate new regions through splitting existing ones every time the size of the region or the number of keys has reached a threshold. | ||
|
||
## S | ||
|
||
### scheduler | ||
|
||
Schedulers are components in PD that generate scheduling tasks. Each scheduler in PD runs independently and serves different purposes. The commonly used schedulers are: | ||
|
||
- `balance-leader-scheduler`: Balances the distribution of leaders | ||
- `balance-region-scheduler`: Balances the distribution of peers | ||
- `hot-region-scheduler`: Balances the distribution of hot regions | ||
- `evict-leader-{store-id}`: Evicts all leaders of a node (often used for rolling upgrades) | ||
|
||
### store | ||
|
||
A store refers to the storage node in the TiKV cluster (an instance of `tikv-server`). Each store has a corresponding TiKV instance. |
Oops, something went wrong.