This is an automated email from the ASF dual-hosted git repository.
jxue pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/helix.git
The following commit(s) were added to refs/heads/master by this push:
new 8824d2255 More term cleanup for tutorial website (#2059)
8824d2255 is described below
commit 8824d22558a062dfd6ae7b8947224ed6a8e8709e
Author: Qi (Quincy) Qu <[email protected]>
AuthorDate: Wed Apr 27 15:41:06 2022 -0700
More term cleanup for tutorial website (#2059)
---
website/0.9.9/src/site/markdown/Features.md | 44 +++++++--------
website/0.9.9/src/site/markdown/tutorial_admin.md | 8 +--
.../0.9.9/src/site/markdown/tutorial_rebalance.md | 46 ++++++++--------
.../src/site/markdown/tutorial_rest_service.md | 62 +++++++++++-----------
website/0.9.9/src/site/markdown/tutorial_state.md | 32 +++++------
.../0.9.9/src/site/markdown/tutorial_throttling.md | 2 +-
website/1.0.2/src/site/markdown/Features.md | 44 +++++++--------
website/1.0.2/src/site/markdown/tutorial_admin.md | 8 +--
.../1.0.2/src/site/markdown/tutorial_rebalance.md | 46 ++++++++--------
.../src/site/markdown/tutorial_rest_service.md | 56 +++++++++----------
website/1.0.2/src/site/markdown/tutorial_state.md | 32 +++++------
.../1.0.2/src/site/markdown/tutorial_throttling.md | 2 +-
website/1.0.3/src/site/markdown/Features.md | 44 +++++++--------
website/1.0.3/src/site/markdown/tutorial_admin.md | 8 +--
.../1.0.3/src/site/markdown/tutorial_rebalance.md | 46 ++++++++--------
.../src/site/markdown/tutorial_rest_service.md | 56 +++++++++----------
website/1.0.3/src/site/markdown/tutorial_state.md | 32 +++++------
.../1.0.3/src/site/markdown/tutorial_throttling.md | 2 +-
website/src/site/markdown/Concepts.md | 60 ++++++++++-----------
19 files changed, 315 insertions(+), 315 deletions(-)
diff --git a/website/0.9.9/src/site/markdown/Features.md
b/website/0.9.9/src/site/markdown/Features.md
index ba9d0e72d..476956a63 100644
--- a/website/0.9.9/src/site/markdown/Features.md
+++ b/website/0.9.9/src/site/markdown/Features.md
@@ -72,7 +72,7 @@ When the idealstate mode is set to AUTO_REBALANCE, Helix
controls both the locat
"IDEAL_STATE_MODE" : "AUTO_REBALANCE",
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
}
"listFields" : {
"MyResource_0" : [],
@@ -92,20 +92,20 @@ If there are 3 nodes in the cluster, then Helix will
internally compute the idea
"simpleFields" : {
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
},
"mapFields" : {
"MyResource_0" : {
- "N1" : "MASTER",
- "N2" : "SLAVE",
+ "N1" : "LEADER",
+ "N2" : "STANDBY",
},
"MyResource_1" : {
- "N2" : "MASTER",
- "N3" : "SLAVE",
+ "N2" : "LEADER",
+ "N3" : "STANDBY",
},
"MyResource_2" : {
- "N3" : "MASTER",
- "N1" : "SLAVE",
+ "N3" : "LEADER",
+ "N1" : "STANDBY",
}
}
}
@@ -125,7 +125,7 @@ When the idealstate mode is set to AUTO, Helix only
controls STATE of the replic
"IDEAL_STATE_MODE" : "AUTO",
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
}
"listFields" : {
"MyResource_0" : [node1, node2],
@@ -136,7 +136,7 @@ When the idealstate mode is set to AUTO, Helix only
controls STATE of the replic
}
}
```
-In this mode when node1 fails, unlike in AUTO-REBALANCE mode the partition is
not moved from node1 to others nodes in the cluster. Instead, Helix will decide
to change the state of MyResource_0 in N2 based on the system constraints. For
example, if a system constraint specified that there should be 1 Master and if
the Master failed, then node2 will be made the new master.
+In this mode when node1 fails, unlike in AUTO-REBALANCE mode the partition is
not moved from node1 to others nodes in the cluster. Instead, Helix will decide
to change the state of MyResource_0 in N2 based on the system constraints. For
example, if a system constraint specified that there should be 1 Master and if
the Master failed, then node2 will be made the new leader.
#### CUSTOM
@@ -150,27 +150,27 @@ Within this callback, the application can recompute the
idealstate. Helix will t
"IDEAL_STATE_MODE" : "CUSTOM",
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
},
"mapFields" : {
"MyResource_0" : {
- "N1" : "MASTER",
- "N2" : "SLAVE",
+ "N1" : "LEADER",
+ "N2" : "STANDBY",
},
"MyResource_1" : {
- "N2" : "MASTER",
- "N3" : "SLAVE",
+ "N2" : "LEADER",
+ "N3" : "STANDBY",
},
"MyResource_2" : {
- "N3" : "MASTER",
- "N1" : "SLAVE",
+ "N3" : "LEADER",
+ "N1" : "STANDBY",
}
}
}
```
-For example, the current state of the system might be 'MyResource_0' ->
{N1:MASTER,N2:SLAVE} and the application changes the ideal state to
'MyResource_0' -> {N1:SLAVE,N2:MASTER}. Helix will not blindly issue
MASTER-->SLAVE to N1 and SLAVE-->MASTER to N2 in parallel since it might result
in a transient state where both N1 and N2 are masters.
-Helix will first issue MASTER-->SLAVE to N1 and after its completed it will
issue SLAVE-->MASTER to N2.
+For example, the current state of the system might be 'MyResource_0' ->
{N1:LEADER,N2:STANDBY} and the application changes the ideal state to
'MyResource_0' -> {N1:STANDBY,N2:LEADER}. Helix will not blindly issue
LEADER-->STANDBY to N1 and STANDBY-->LEADER to N2 in parallel since it might
result in a transient state where both N1 and N2 are leaders.
+Helix will first issue LEADER-->STANDBY to N1 and after its completed it will
issue STANDBY-->LEADER to N2.
### State Machine Configuration
@@ -186,10 +186,10 @@ Apart from providing the state machine configuration, one
can specify the constr
For example one can say
Master:1. Max number of replicas in Master state at any time is 1.
-OFFLINE-SLAVE:5 Max number of Offline-Slave transitions that can happen
concurrently in the system
+OFFLINE-STANDBY:5 Max number of Offline-Slave transitions that can happen
concurrently in the system
STATE PRIORITY
-Helix uses greedy approach to satisfy the state constraints. For example if
the state machine configuration says it needs 1 master and 2 slaves but only 1
node is active, Helix must promote it to master. This behavior is achieved by
providing the state priority list as MASTER,SLAVE.
+Helix uses greedy approach to satisfy the state constraints. For example if
the state machine configuration says it needs 1 leader and 2 standbys but only
1 node is active, Helix must promote it to leader. This behavior is achieved by
providing the state priority list as LEADER,STANDBY.
STATE TRANSITION PRIORITY
Helix tries to fire as many transitions as possible in parallel to reach the
stable state without violating constraints. By default Helix simply sorts the
transitions alphabetically and fires as many as it can without violating the
constraints.
@@ -262,7 +262,7 @@ Since all state changes in the system are triggered through
transitions, Helix c
Helix allows applications to set threshold on transitions. The threshold can
be set at the multiple scopes.
* MessageType e.g STATE_TRANSITION
-* TransitionType e.g SLAVE-MASTER
+* TransitionType e.g STANDBY-LEADER
* Resource e.g database
* Node i.e per node max transitions in parallel.
diff --git a/website/0.9.9/src/site/markdown/tutorial_admin.md
b/website/0.9.9/src/site/markdown/tutorial_admin.md
index c6c56ebd9..3b4cf98b6 100644
--- a/website/0.9.9/src/site/markdown/tutorial_admin.md
+++ b/website/0.9.9/src/site/markdown/tutorial_admin.md
@@ -161,7 +161,7 @@ chmod +x *.sh
* Add a resource to cluster
```
- curl -d
'jsonParameters={"command":"addResource","resourceGroupName":"MyDB","partitions":"8","stateModelDefRef":"MasterSlave"
}' -H "Content-Type: application/json"
http://localhost:8100/clusters/MyCluster/resourceGroups
+ curl -d
'jsonParameters={"command":"addResource","resourceGroupName":"MyDB","partitions":"8","stateModelDefRef":"LeaderStandby"
}' -H "Content-Type: application/json"
http://localhost:8100/clusters/MyCluster/resourceGroups
```
* _/clusters/{clusterName}/resourceGroups/{resourceName}_
@@ -202,15 +202,15 @@ chmod +x *.sh
"NUM_PARTITIONS" : "8",
"REBALANCE_MODE" : "SEMI_AUTO",
"REPLICAS" : "0",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
"STATE_MODEL_FACTORY_NAME" : "DEFAULT"
},
"listFields" : {
},
"mapFields" : {
"MyDB_0" : {
- "localhost_1001" : "MASTER",
- "localhost_1002" : "SLAVE"
+ "localhost_1001" : "LEADER",
+ "localhost_1002" : "STANDBY"
}
}
}
diff --git a/website/0.9.9/src/site/markdown/tutorial_rebalance.md
b/website/0.9.9/src/site/markdown/tutorial_rebalance.md
index 2e1a79b76..ec00ec065 100644
--- a/website/0.9.9/src/site/markdown/tutorial_rebalance.md
+++ b/website/0.9.9/src/site/markdown/tutorial_rebalance.md
@@ -57,7 +57,7 @@ Helix has four options for rebalancing, in increasing order
of customization by
When the rebalance mode is set to FULL_AUTO, Helix controls both the location
of the replica along with the state. This option is useful for applications
where creation of a replica is not expensive.
-For example, consider this system that uses a MasterSlave state model, with 3
partitions and 2 replicas in the ideal state.
+For example, consider this system that uses a LeaderStandby state model, with
3 partitions and 2 replicas in the ideal state.
```
{
@@ -66,7 +66,7 @@ For example, consider this system that uses a MasterSlave
state model, with 3 pa
"REBALANCE_MODE" : "FULL_AUTO",
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
}
"listFields" : {
"MyResource_0" : [],
@@ -78,7 +78,7 @@ For example, consider this system that uses a MasterSlave
state model, with 3 pa
}
```
-If there are 3 nodes in the cluster, then Helix will balance the masters and
slaves equally. The ideal state is therefore:
+If there are 3 nodes in the cluster, then Helix will balance the leaders and
standbys equally. The ideal state is therefore:
```
{
@@ -86,20 +86,20 @@ If there are 3 nodes in the cluster, then Helix will
balance the masters and sla
"simpleFields" : {
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
},
"mapFields" : {
"MyResource_0" : {
- "N1" : "MASTER",
- "N2" : "SLAVE",
+ "N1" : "LEADER",
+ "N2" : "STANDBY",
},
"MyResource_1" : {
- "N2" : "MASTER",
- "N3" : "SLAVE",
+ "N2" : "LEADER",
+ "N3" : "STANDBY",
},
"MyResource_2" : {
- "N3" : "MASTER",
- "N1" : "SLAVE",
+ "N3" : "LEADER",
+ "N1" : "STANDBY",
}
}
}
@@ -112,7 +112,7 @@ When one node fails, Helix redistributes its 15 tasks to
the remaining 3 nodes,
When the application needs to control the placement of the replicas, use the
SEMI_AUTO rebalance mode.
-Example: In the ideal state below, the partition \'MyResource_0\' is
constrained to be placed only on node1 or node2. The choice of _state_ is
still controlled by Helix. That means MyResource_0.MASTER could be on node1
and MyResource_0.SLAVE on node2, or vice-versa but neither would be placed on
node3.
+Example: In the ideal state below, the partition \'MyResource_0\' is
constrained to be placed only on node1 or node2. The choice of _state_ is
still controlled by Helix. That means MyResource_0.LEADER could be on node1
and MyResource_0.STANDBY on node2, or vice-versa but neither would be placed on
node3.
```
{
@@ -121,7 +121,7 @@ Example: In the ideal state below, the partition
\'MyResource_0\' is constrained
"REBALANCE_MODE" : "SEMI_AUTO",
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
}
"listFields" : {
"MyResource_0" : [node1, node2],
@@ -133,16 +133,16 @@ Example: In the ideal state below, the partition
\'MyResource_0\' is constrained
}
```
-The MasterSlave state model requires that a partition has exactly one MASTER
at all times, and the other replicas should be SLAVEs. In this simple example
with 2 replicas per partition, there would be one MASTER and one SLAVE. Upon
failover, a SLAVE has to assume mastership, and a new SLAVE will be generated.
+The LeaderStandby state model requires that a partition has exactly one LEADER
at all times, and the other replicas should be STANDBYs. In this simple
example with 2 replicas per partition, there would be one LEADER and one
STANDBY. Upon failover, a STANDBY has to assume leadership, and a new STANDBY
will be generated.
-In this mode when node1 fails, unlike in FULL_AUTO mode the partition is _not_
moved from node1 to node3. Instead, Helix will decide to change the state of
MyResource_0 on node2 from SLAVE to MASTER, based on the system constraints.
+In this mode when node1 fails, unlike in FULL_AUTO mode the partition is _not_
moved from node1 to node3. Instead, Helix will decide to change the state of
MyResource_0 on node2 from STANDBY to LEADER, based on the system constraints.
### CUSTOMIZED
Helix offers a third mode called CUSTOMIZED, in which the application controls
the placement _and_ state of each replica. The application needs to implement a
callback interface that Helix invokes when the cluster state changes.
Within this callback, the application can recompute the idealstate. Helix will
then issue appropriate transitions such that _Idealstate_ and _Currentstate_
converges.
-Here\'s an example, again with 3 partitions, 2 replicas per partition, and the
MasterSlave state model:
+Here\'s an example, again with 3 partitions, 2 replicas per partition, and the
LeaderStandby state model:
```
{
@@ -151,26 +151,26 @@ Here\'s an example, again with 3 partitions, 2 replicas
per partition, and the M
"REBALANCE_MODE" : "CUSTOMIZED",
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
},
"mapFields" : {
"MyResource_0" : {
- "N1" : "MASTER",
- "N2" : "SLAVE",
+ "N1" : "LEADER",
+ "N2" : "STANDBY",
},
"MyResource_1" : {
- "N2" : "MASTER",
- "N3" : "SLAVE",
+ "N2" : "LEADER",
+ "N3" : "STANDBY",
},
"MyResource_2" : {
- "N3" : "MASTER",
- "N1" : "SLAVE",
+ "N3" : "LEADER",
+ "N1" : "STANDBY",
}
}
}
```
-Suppose the current state of the system is 'MyResource_0' \-\> {N1:MASTER,
N2:SLAVE} and the application changes the ideal state to 'MyResource_0' \-\>
{N1:SLAVE,N2:MASTER}. While the application decides which node is MASTER and
which is SLAVE, Helix will not blindly issue MASTER\-\-\>SLAVE to N1 and
SLAVE\-\-\>MASTER to N2 in parallel, since that might result in a transient
state where both N1 and N2 are masters, which violates the MasterSlave
constraint that there is exactly one MASTER [...]
+Suppose the current state of the system is 'MyResource_0' \-\> {N1:LEADER,
N2:STANDBY} and the application changes the ideal state to 'MyResource_0' \-\>
{N1:STANDBY,N2:LEADER}. While the application decides which node is LEADER and
which is STANDBY, Helix will not blindly issue LEADER\-\-\>STANDBY to N1 and
STANDBY\-\-\>LEADER to N2 in parallel, since that might result in a transient
state where both N1 and N2 are leaders, which violates the LeaderStandby
constraint that there is exactl [...]
### USER_DEFINED
diff --git a/website/0.9.9/src/site/markdown/tutorial_rest_service.md
b/website/0.9.9/src/site/markdown/tutorial_rest_service.md
index 79686c35b..c255bf595 100644
--- a/website/0.9.9/src/site/markdown/tutorial_rest_service.md
+++ b/website/0.9.9/src/site/markdown/tutorial_rest_service.md
@@ -245,9 +245,9 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
* **GET** - get the state model definition
```
- $curl -X POST -H "Content-Type: application/json"
http://localhost:1234/admin/v2/clusters/myCluster/statemodeldefs/MasterSlave
+ $curl -X POST -H "Content-Type: application/json"
http://localhost:1234/admin/v2/clusters/myCluster/statemodeldefs/LeaderStandby
{
- "id" : "MasterSlave",
+ "id" : "STANDBY",
"simpleFields" : {
"INITIAL_STATE" : "OFFLINE"
},
@@ -262,34 +262,34 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
"DROPPED" : "DROPPED",
"OFFLINE" : "OFFLINE"
},
- "MASTER.meta" : {
+ "LEADER.meta" : {
"count" : "1"
},
- "MASTER.next" : {
- "SLAVE" : "SLAVE",
- "DROPPED" : "SLAVE",
- "OFFLINE" : "SLAVE"
+ "LEADER.next" : {
+ "STANDBY" : "STANDBY",
+ "DROPPED" : "STANDBY",
+ "OFFLINE" : "STANDBY"
},
"OFFLINE.meta" : {
"count" : "-1"
},
"OFFLINE.next" : {
- "SLAVE" : "SLAVE",
- "MASTER" : "SLAVE",
+ "STANDBY" : "STANDBY",
+ "LEADER" : "STANDBY",
"DROPPED" : "DROPPED"
},
- "SLAVE.meta" : {
+ "STANDBY.meta" : {
"count" : "R"
},
- "SLAVE.next" : {
- "MASTER" : "MASTER",
+ "STANDBY.next" : {
+ "LEADER" : "LEADER",
"DROPPED" : "OFFLINE",
"OFFLINE" : "OFFLINE"
}
},
"listFields" : {
- "STATE_PRIORITY_LIST" : [ "MASTER", "SLAVE", "OFFLINE", "DROPPED",
"ERROR" ],
- "STATE_TRANSITION_PRIORITYLIST" : [ "MASTER-SLAVE", "SLAVE-MASTER",
"OFFLINE-SLAVE", "SLAVE-OFFLINE", "OFFLINE-DROPPED" ]
+ "STATE_PRIORITY_LIST" : [ "LEADER", "STANDBY", "OFFLINE", "DROPPED",
"ERROR" ],
+ "STATE_TRANSITION_PRIORITYLIST" : [ "LEADER-STANDBY",
"STANDBY-LEADER", "OFFLINE-STANDBY", "STANDBY-OFFLINE", "OFFLINE-DROPPED" ]
}
}
```
@@ -364,7 +364,7 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
,"NUM_PARTITIONS":"2"
,"REBALANCE_MODE":"SEMI_AUTO"
,"REPLICAS":"2"
- ,"STATE_MODEL_DEF_REF":"MasterSlave"
+ ,"STATE_MODEL_DEF_REF":"STANDBY"
}
,"listFields":{
"myResource_0":["host1", "host2"]
@@ -372,12 +372,12 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
}
,"mapFields":{
"myResource_0":{
- "host1":"MASTER"
- ,"host2":"SLAVE"
+ "host1":"LEADER"
+ ,"host2":"STANDBY"
}
,"myResource_1":{
- "host1":"SLAVE"
- ,"host2":"MASTER"
+ "host1":"STANDBY"
+ ,"host2":"LEADER"
}
}
}
@@ -396,7 +396,7 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
,"NUM_PARTITIONS":"2"
,"REBALANCE_MODE":"SEMI_AUTO"
,"REPLICAS":"2"
- ,"STATE_MODEL_DEF_REF":"MasterSlave"
+ ,"STATE_MODEL_DEF_REF":"STANDBY"
}
,"listFields":{
"myResource_0":["host1", "host2"]
@@ -404,12 +404,12 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
}
,"mapFields":{
"myResource_0":{
- "host1":"MASTER"
+ "host1":"LEADER"
,"host2":"OFFLINE"
}
,"myResource_1":{
- "host1":"SLAVE"
- ,"host2":"MASTER"
+ "host1":"STANDBY"
+ ,"host2":"LEADER"
}
}
}
@@ -539,7 +539,7 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
{
"id":"myResource1"
,"simpleFields":{
- "STATE_MODEL_DEF":"MasterSlave"
+ "STATE_MODEL_DEF":"STANDBY"
,"STATE_MODEL_FACTORY_NAME":"DEFAULT"
,"BUCKET_SIZE":"0"
,"SESSION_ID":"359619c2d7f109b"
@@ -548,19 +548,19 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
}
,"mapFields":{
"myResource1_2":{
- "CURRENT_STATE":"SLAVE"
+ "CURRENT_STATE":"STANDBY"
,"INFO":""
}
,"myResource1_3":{
- "CURRENT_STATE":"MASTER"
+ "CURRENT_STATE":"LEADER"
,"INFO":""
}
,"myResource1_0":{
- "CURRENT_STATE":"MASTER"
+ "CURRENT_STATE":"LEADER"
,"INFO":""
}
,"myResource1_1":{
- "CURRENT_STATE":"SLAVE"
+ "CURRENT_STATE":"STANDBY"
,"INFO":""
}
}
@@ -657,7 +657,7 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
"{DATE=2017-03-30T00:05:08:321, SESSION=5590151804e2c78,
TIME=1490832308321}",
"{DATE=2017-03-30T01:17:34:339, SESSION=2591d53b0421864,
TIME=1490836654339}",
"{DATE=2017-03-30T17:31:09:880, SESSION=2591d53b0421b2a,
TIME=1490895069880}",
- "{DATE=2017-03-30T18:05:38:220, SESSION=359619c2d7f109b,
TIME=1490.9.738220}"
+ "{DATE=2017-03-30T18:05:38:220, SESSION=359619c2d7f109b,
TIME=1490897138220}"
]
}
```
@@ -871,7 +871,7 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
},
"JobContext":{
"START_TIME":"1491005863291",
- "FINISH_TIME":"149101.0.0612",
+ "FINISH_TIME":"1491005902612",
"Tasks":[
{
"id":"0",
@@ -924,7 +924,7 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
{
"id":"JobContext":
"START_TIME":"1491005863291",
- "FINISH_TIME":"149101.0.0612",
+ "FINISH_TIME":"1491005902612",
"Tasks":[
{
"id":"0",
diff --git a/website/0.9.9/src/site/markdown/tutorial_state.md
b/website/0.9.9/src/site/markdown/tutorial_state.md
index 856b8b36f..c274a3cdb 100644
--- a/website/0.9.9/src/site/markdown/tutorial_state.md
+++ b/website/0.9.9/src/site/markdown/tutorial_state.md
@@ -51,11 +51,11 @@ In addition to the state machine configuration, one can
specify the constraints
For example, one can say:
-* MASTER:1
-<br/>Maximum number of replicas in MASTER state at any time is 1
+* LEADER:1
+<br/>Maximum number of replicas in LEADER state at any time is 1
-* OFFLINE-SLAVE:5
-<br/>Maximum number of OFFLINE-SLAVE transitions that can happen concurrently
in the system is 5 in this example.
+* OFFLINE-STANDBY:5
+<br/>Maximum number of OFFLINE-STANDBY transitions that can happen
concurrently in the system is 5 in this example.
#### Dynamic State Constraints
@@ -66,7 +66,7 @@ We also support two dynamic upper bounds for the number of
replicas in each stat
#### State Priority
-Helix uses a greedy approach to satisfy the state constraints. For example, if
the state machine configuration says it needs 1 MASTER and 2 SLAVES, but only 1
node is active, Helix must promote it to MASTER. This behavior is achieved by
providing the state priority list as \[MASTER, SLAVE\].
+Helix uses a greedy approach to satisfy the state constraints. For example, if
the state machine configuration says it needs 1 LEADER and 2 STANDBYS, but only
1 node is active, Helix must promote it to LEADER. This behavior is achieved by
providing the state priority list as \[LEADER, STANDBY\].
#### State Transition Priority
@@ -89,34 +89,34 @@ The ERROR state is used whenever the participant serving a
partition encountered
### Annotated Example
-Below is a complete definition of a Master-Slave state model. Notice the
fields marked REQUIRED; these are essential for any state model definition.
+Below is a complete definition of a Leader-Standby state model. Notice the
fields marked REQUIRED; these are essential for any state model definition.
```
-StateModelDefinition stateModel = new
StateModelDefinition.Builder("MasterSlave")
+StateModelDefinition stateModel = new
StateModelDefinition.Builder("LeaderStandby")
// OFFLINE is the state that the system starts in (initial state is REQUIRED)
.initialState("OFFLINE")
// Lowest number here indicates highest priority, no value indicates lowest
priority
- .addState("MASTER", 1)
- .addState("SLAVE", 2)
+ .addState("LEADER", 1)
+ .addState("STANDBY", 2)
.addState("OFFLINE")
// Note the special inclusion of the DROPPED state (REQUIRED)
.addState(HelixDefinedState.DROPPED.toString())
- // No more than one master allowed
- .upperBound("MASTER", 1)
+ // No more than one leader allowed
+ .upperBound("LEADER", 1)
// R indicates an upper bound of number of replicas for each partition
- .dynamicUpperBound("SLAVE", "R")
+ .dynamicUpperBound("STANDBY", "R")
// Add some high-priority transitions
- .addTransition("SLAVE", "MASTER", 1)
- .addTransition("OFFLINE", "SLAVE", 2)
+ .addTransition("STANDBY", "LEADER", 1)
+ .addTransition("OFFLINE", "STANDBY", 2)
// Using the same priority value indicates that these transitions can fire
in any order
- .addTransition("MASTER", "SLAVE", 3)
- .addTransition("SLAVE", "OFFLINE", 3)
+ .addTransition("LEADER", "STANDBY", 3)
+ .addTransition("STANDBY", "OFFLINE", 3)
// Not specifying a value defaults to lowest priority
// Notice the inclusion of the OFFLINE to DROPPED transition
diff --git a/website/0.9.9/src/site/markdown/tutorial_throttling.md
b/website/0.9.9/src/site/markdown/tutorial_throttling.md
index 16a6f8112..7c0f9c193 100644
--- a/website/0.9.9/src/site/markdown/tutorial_throttling.md
+++ b/website/0.9.9/src/site/markdown/tutorial_throttling.md
@@ -32,7 +32,7 @@ Since all state changes in the system are triggered through
transitions, Helix c
Helix allows applications to set a threshold on transitions. The threshold can
be set at multiple scopes:
* MessageType e.g STATE_TRANSITION
-* TransitionType e.g SLAVE-MASTER
+* TransitionType e.g STANDBY-LEADER
* Resource e.g database
* Node i.e per-node maximum transitions in parallel
diff --git a/website/1.0.2/src/site/markdown/Features.md
b/website/1.0.2/src/site/markdown/Features.md
index ba9d0e72d..476956a63 100644
--- a/website/1.0.2/src/site/markdown/Features.md
+++ b/website/1.0.2/src/site/markdown/Features.md
@@ -72,7 +72,7 @@ When the idealstate mode is set to AUTO_REBALANCE, Helix
controls both the locat
"IDEAL_STATE_MODE" : "AUTO_REBALANCE",
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
}
"listFields" : {
"MyResource_0" : [],
@@ -92,20 +92,20 @@ If there are 3 nodes in the cluster, then Helix will
internally compute the idea
"simpleFields" : {
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
},
"mapFields" : {
"MyResource_0" : {
- "N1" : "MASTER",
- "N2" : "SLAVE",
+ "N1" : "LEADER",
+ "N2" : "STANDBY",
},
"MyResource_1" : {
- "N2" : "MASTER",
- "N3" : "SLAVE",
+ "N2" : "LEADER",
+ "N3" : "STANDBY",
},
"MyResource_2" : {
- "N3" : "MASTER",
- "N1" : "SLAVE",
+ "N3" : "LEADER",
+ "N1" : "STANDBY",
}
}
}
@@ -125,7 +125,7 @@ When the idealstate mode is set to AUTO, Helix only
controls STATE of the replic
"IDEAL_STATE_MODE" : "AUTO",
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
}
"listFields" : {
"MyResource_0" : [node1, node2],
@@ -136,7 +136,7 @@ When the idealstate mode is set to AUTO, Helix only
controls STATE of the replic
}
}
```
-In this mode when node1 fails, unlike in AUTO-REBALANCE mode the partition is
not moved from node1 to others nodes in the cluster. Instead, Helix will decide
to change the state of MyResource_0 in N2 based on the system constraints. For
example, if a system constraint specified that there should be 1 Master and if
the Master failed, then node2 will be made the new master.
+In this mode when node1 fails, unlike in AUTO-REBALANCE mode the partition is
not moved from node1 to others nodes in the cluster. Instead, Helix will decide
to change the state of MyResource_0 in N2 based on the system constraints. For
example, if a system constraint specified that there should be 1 Master and if
the Master failed, then node2 will be made the new leader.
#### CUSTOM
@@ -150,27 +150,27 @@ Within this callback, the application can recompute the
idealstate. Helix will t
"IDEAL_STATE_MODE" : "CUSTOM",
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
},
"mapFields" : {
"MyResource_0" : {
- "N1" : "MASTER",
- "N2" : "SLAVE",
+ "N1" : "LEADER",
+ "N2" : "STANDBY",
},
"MyResource_1" : {
- "N2" : "MASTER",
- "N3" : "SLAVE",
+ "N2" : "LEADER",
+ "N3" : "STANDBY",
},
"MyResource_2" : {
- "N3" : "MASTER",
- "N1" : "SLAVE",
+ "N3" : "LEADER",
+ "N1" : "STANDBY",
}
}
}
```
-For example, the current state of the system might be 'MyResource_0' ->
{N1:MASTER,N2:SLAVE} and the application changes the ideal state to
'MyResource_0' -> {N1:SLAVE,N2:MASTER}. Helix will not blindly issue
MASTER-->SLAVE to N1 and SLAVE-->MASTER to N2 in parallel since it might result
in a transient state where both N1 and N2 are masters.
-Helix will first issue MASTER-->SLAVE to N1 and after its completed it will
issue SLAVE-->MASTER to N2.
+For example, the current state of the system might be 'MyResource_0' ->
{N1:LEADER,N2:STANDBY} and the application changes the ideal state to
'MyResource_0' -> {N1:STANDBY,N2:LEADER}. Helix will not blindly issue
LEADER-->STANDBY to N1 and STANDBY-->LEADER to N2 in parallel since it might
result in a transient state where both N1 and N2 are leaders.
+Helix will first issue LEADER-->STANDBY to N1 and after its completed it will
issue STANDBY-->LEADER to N2.
### State Machine Configuration
@@ -186,10 +186,10 @@ Apart from providing the state machine configuration, one
can specify the constr
For example one can say
Master:1. Max number of replicas in Master state at any time is 1.
-OFFLINE-SLAVE:5 Max number of Offline-Slave transitions that can happen
concurrently in the system
+OFFLINE-STANDBY:5 Max number of Offline-Slave transitions that can happen
concurrently in the system
STATE PRIORITY
-Helix uses greedy approach to satisfy the state constraints. For example if
the state machine configuration says it needs 1 master and 2 slaves but only 1
node is active, Helix must promote it to master. This behavior is achieved by
providing the state priority list as MASTER,SLAVE.
+Helix uses greedy approach to satisfy the state constraints. For example if
the state machine configuration says it needs 1 leader and 2 standbys but only
1 node is active, Helix must promote it to leader. This behavior is achieved by
providing the state priority list as LEADER,STANDBY.
STATE TRANSITION PRIORITY
Helix tries to fire as many transitions as possible in parallel to reach the
stable state without violating constraints. By default Helix simply sorts the
transitions alphabetically and fires as many as it can without violating the
constraints.
@@ -262,7 +262,7 @@ Since all state changes in the system are triggered through
transitions, Helix c
Helix allows applications to set threshold on transitions. The threshold can
be set at the multiple scopes.
* MessageType e.g STATE_TRANSITION
-* TransitionType e.g SLAVE-MASTER
+* TransitionType e.g STANDBY-LEADER
* Resource e.g database
* Node i.e per node max transitions in parallel.
diff --git a/website/1.0.2/src/site/markdown/tutorial_admin.md
b/website/1.0.2/src/site/markdown/tutorial_admin.md
index b7072efba..5619d294a 100644
--- a/website/1.0.2/src/site/markdown/tutorial_admin.md
+++ b/website/1.0.2/src/site/markdown/tutorial_admin.md
@@ -161,7 +161,7 @@ chmod +x *.sh
* Add a resource to cluster
```
- curl -d
'jsonParameters={"command":"addResource","resourceGroupName":"MyDB","partitions":"8","stateModelDefRef":"MasterSlave"
}' -H "Content-Type: application/json"
http://localhost:8100/clusters/MyCluster/resourceGroups
+ curl -d
'jsonParameters={"command":"addResource","resourceGroupName":"MyDB","partitions":"8","stateModelDefRef":"LeaderStandby"
}' -H "Content-Type: application/json"
http://localhost:8100/clusters/MyCluster/resourceGroups
```
* _/clusters/{clusterName}/resourceGroups/{resourceName}_
@@ -202,15 +202,15 @@ chmod +x *.sh
"NUM_PARTITIONS" : "8",
"REBALANCE_MODE" : "SEMI_AUTO",
"REPLICAS" : "0",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
"STATE_MODEL_FACTORY_NAME" : "DEFAULT"
},
"listFields" : {
},
"mapFields" : {
"MyDB_0" : {
- "localhost_1001" : "MASTER",
- "localhost_1002" : "SLAVE"
+ "localhost_1001" : "LEADER",
+ "localhost_1002" : "STANDBY"
}
}
}
diff --git a/website/1.0.2/src/site/markdown/tutorial_rebalance.md
b/website/1.0.2/src/site/markdown/tutorial_rebalance.md
index 2e1a79b76..ec00ec065 100644
--- a/website/1.0.2/src/site/markdown/tutorial_rebalance.md
+++ b/website/1.0.2/src/site/markdown/tutorial_rebalance.md
@@ -57,7 +57,7 @@ Helix has four options for rebalancing, in increasing order
of customization by
When the rebalance mode is set to FULL_AUTO, Helix controls both the location
of the replica along with the state. This option is useful for applications
where creation of a replica is not expensive.
-For example, consider this system that uses a MasterSlave state model, with 3
partitions and 2 replicas in the ideal state.
+For example, consider this system that uses a LeaderStandby state model, with
3 partitions and 2 replicas in the ideal state.
```
{
@@ -66,7 +66,7 @@ For example, consider this system that uses a MasterSlave
state model, with 3 pa
"REBALANCE_MODE" : "FULL_AUTO",
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
}
"listFields" : {
"MyResource_0" : [],
@@ -78,7 +78,7 @@ For example, consider this system that uses a MasterSlave
state model, with 3 pa
}
```
-If there are 3 nodes in the cluster, then Helix will balance the masters and
slaves equally. The ideal state is therefore:
+If there are 3 nodes in the cluster, then Helix will balance the leaders and
standbys equally. The ideal state is therefore:
```
{
@@ -86,20 +86,20 @@ If there are 3 nodes in the cluster, then Helix will
balance the masters and sla
"simpleFields" : {
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
},
"mapFields" : {
"MyResource_0" : {
- "N1" : "MASTER",
- "N2" : "SLAVE",
+ "N1" : "LEADER",
+ "N2" : "STANDBY",
},
"MyResource_1" : {
- "N2" : "MASTER",
- "N3" : "SLAVE",
+ "N2" : "LEADER",
+ "N3" : "STANDBY",
},
"MyResource_2" : {
- "N3" : "MASTER",
- "N1" : "SLAVE",
+ "N3" : "LEADER",
+ "N1" : "STANDBY",
}
}
}
@@ -112,7 +112,7 @@ When one node fails, Helix redistributes its 15 tasks to
the remaining 3 nodes,
When the application needs to control the placement of the replicas, use the
SEMI_AUTO rebalance mode.
-Example: In the ideal state below, the partition \'MyResource_0\' is
constrained to be placed only on node1 or node2. The choice of _state_ is
still controlled by Helix. That means MyResource_0.MASTER could be on node1
and MyResource_0.SLAVE on node2, or vice-versa but neither would be placed on
node3.
+Example: In the ideal state below, the partition \'MyResource_0\' is
constrained to be placed only on node1 or node2. The choice of _state_ is
still controlled by Helix. That means MyResource_0.LEADER could be on node1
and MyResource_0.STANDBY on node2, or vice-versa but neither would be placed on
node3.
```
{
@@ -121,7 +121,7 @@ Example: In the ideal state below, the partition
\'MyResource_0\' is constrained
"REBALANCE_MODE" : "SEMI_AUTO",
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
}
"listFields" : {
"MyResource_0" : [node1, node2],
@@ -133,16 +133,16 @@ Example: In the ideal state below, the partition
\'MyResource_0\' is constrained
}
```
-The MasterSlave state model requires that a partition has exactly one MASTER
at all times, and the other replicas should be SLAVEs. In this simple example
with 2 replicas per partition, there would be one MASTER and one SLAVE. Upon
failover, a SLAVE has to assume mastership, and a new SLAVE will be generated.
+The LeaderStandby state model requires that a partition has exactly one LEADER
at all times, and the other replicas should be STANDBYs. In this simple
example with 2 replicas per partition, there would be one LEADER and one
STANDBY. Upon failover, a STANDBY has to assume leadership, and a new STANDBY
will be generated.
-In this mode when node1 fails, unlike in FULL_AUTO mode the partition is _not_
moved from node1 to node3. Instead, Helix will decide to change the state of
MyResource_0 on node2 from SLAVE to MASTER, based on the system constraints.
+In this mode when node1 fails, unlike in FULL_AUTO mode the partition is _not_
moved from node1 to node3. Instead, Helix will decide to change the state of
MyResource_0 on node2 from STANDBY to LEADER, based on the system constraints.
### CUSTOMIZED
Helix offers a third mode called CUSTOMIZED, in which the application controls
the placement _and_ state of each replica. The application needs to implement a
callback interface that Helix invokes when the cluster state changes.
Within this callback, the application can recompute the idealstate. Helix will
then issue appropriate transitions such that _Idealstate_ and _Currentstate_
converges.
-Here\'s an example, again with 3 partitions, 2 replicas per partition, and the
MasterSlave state model:
+Here\'s an example, again with 3 partitions, 2 replicas per partition, and the
LeaderStandby state model:
```
{
@@ -151,26 +151,26 @@ Here\'s an example, again with 3 partitions, 2 replicas
per partition, and the M
"REBALANCE_MODE" : "CUSTOMIZED",
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
},
"mapFields" : {
"MyResource_0" : {
- "N1" : "MASTER",
- "N2" : "SLAVE",
+ "N1" : "LEADER",
+ "N2" : "STANDBY",
},
"MyResource_1" : {
- "N2" : "MASTER",
- "N3" : "SLAVE",
+ "N2" : "LEADER",
+ "N3" : "STANDBY",
},
"MyResource_2" : {
- "N3" : "MASTER",
- "N1" : "SLAVE",
+ "N3" : "LEADER",
+ "N1" : "STANDBY",
}
}
}
```
-Suppose the current state of the system is 'MyResource_0' \-\> {N1:MASTER,
N2:SLAVE} and the application changes the ideal state to 'MyResource_0' \-\>
{N1:SLAVE,N2:MASTER}. While the application decides which node is MASTER and
which is SLAVE, Helix will not blindly issue MASTER\-\-\>SLAVE to N1 and
SLAVE\-\-\>MASTER to N2 in parallel, since that might result in a transient
state where both N1 and N2 are masters, which violates the MasterSlave
constraint that there is exactly one MASTER [...]
+Suppose the current state of the system is 'MyResource_0' \-\> {N1:LEADER,
N2:STANDBY} and the application changes the ideal state to 'MyResource_0' \-\>
{N1:STANDBY,N2:LEADER}. While the application decides which node is LEADER and
which is STANDBY, Helix will not blindly issue LEADER\-\-\>STANDBY to N1 and
STANDBY\-\-\>LEADER to N2 in parallel, since that might result in a transient
state where both N1 and N2 are leaders, which violates the LeaderStandby
constraint that there is exactl [...]
### USER_DEFINED
diff --git a/website/1.0.2/src/site/markdown/tutorial_rest_service.md
b/website/1.0.2/src/site/markdown/tutorial_rest_service.md
index b5e951520..c2a9f141c 100644
--- a/website/1.0.2/src/site/markdown/tutorial_rest_service.md
+++ b/website/1.0.2/src/site/markdown/tutorial_rest_service.md
@@ -245,9 +245,9 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
* **GET** - get the state model definition
```
- $curl -X POST -H "Content-Type: application/json"
http://localhost:1234/admin/v2/clusters/myCluster/statemodeldefs/MasterSlave
+ $curl -X POST -H "Content-Type: application/json"
http://localhost:1234/admin/v2/clusters/myCluster/statemodeldefs/LeaderStandby
{
- "id" : "MasterSlave",
+ "id" : "STANDBY",
"simpleFields" : {
"INITIAL_STATE" : "OFFLINE"
},
@@ -262,34 +262,34 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
"DROPPED" : "DROPPED",
"OFFLINE" : "OFFLINE"
},
- "MASTER.meta" : {
+ "LEADER.meta" : {
"count" : "1"
},
- "MASTER.next" : {
- "SLAVE" : "SLAVE",
- "DROPPED" : "SLAVE",
- "OFFLINE" : "SLAVE"
+ "LEADER.next" : {
+ "STANDBY" : "STANDBY",
+ "DROPPED" : "STANDBY",
+ "OFFLINE" : "STANDBY"
},
"OFFLINE.meta" : {
"count" : "-1"
},
"OFFLINE.next" : {
- "SLAVE" : "SLAVE",
- "MASTER" : "SLAVE",
+ "STANDBY" : "STANDBY",
+ "LEADER" : "STANDBY",
"DROPPED" : "DROPPED"
},
- "SLAVE.meta" : {
+ "STANDBY.meta" : {
"count" : "R"
},
- "SLAVE.next" : {
- "MASTER" : "MASTER",
+ "STANDBY.next" : {
+ "LEADER" : "LEADER",
"DROPPED" : "OFFLINE",
"OFFLINE" : "OFFLINE"
}
},
"listFields" : {
- "STATE_PRIORITY_LIST" : [ "MASTER", "SLAVE", "OFFLINE", "DROPPED",
"ERROR" ],
- "STATE_TRANSITION_PRIORITYLIST" : [ "MASTER-SLAVE", "SLAVE-MASTER",
"OFFLINE-SLAVE", "SLAVE-OFFLINE", "OFFLINE-DROPPED" ]
+ "STATE_PRIORITY_LIST" : [ "LEADER", "STANDBY", "OFFLINE", "DROPPED",
"ERROR" ],
+ "STATE_TRANSITION_PRIORITYLIST" : [ "LEADER-STANDBY",
"STANDBY-LEADER", "OFFLINE-STANDBY", "STANDBY-OFFLINE", "OFFLINE-DROPPED" ]
}
}
```
@@ -364,7 +364,7 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
,"NUM_PARTITIONS":"2"
,"REBALANCE_MODE":"SEMI_AUTO"
,"REPLICAS":"2"
- ,"STATE_MODEL_DEF_REF":"MasterSlave"
+ ,"STATE_MODEL_DEF_REF":"STANDBY"
}
,"listFields":{
"myResource_0":["host1", "host2"]
@@ -372,12 +372,12 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
}
,"mapFields":{
"myResource_0":{
- "host1":"MASTER"
- ,"host2":"SLAVE"
+ "host1":"LEADER"
+ ,"host2":"STANDBY"
}
,"myResource_1":{
- "host1":"SLAVE"
- ,"host2":"MASTER"
+ "host1":"STANDBY"
+ ,"host2":"LEADER"
}
}
}
@@ -396,7 +396,7 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
,"NUM_PARTITIONS":"2"
,"REBALANCE_MODE":"SEMI_AUTO"
,"REPLICAS":"2"
- ,"STATE_MODEL_DEF_REF":"MasterSlave"
+ ,"STATE_MODEL_DEF_REF":"STANDBY"
}
,"listFields":{
"myResource_0":["host1", "host2"]
@@ -404,12 +404,12 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
}
,"mapFields":{
"myResource_0":{
- "host1":"MASTER"
+ "host1":"LEADER"
,"host2":"OFFLINE"
}
,"myResource_1":{
- "host1":"SLAVE"
- ,"host2":"MASTER"
+ "host1":"STANDBY"
+ ,"host2":"LEADER"
}
}
}
@@ -539,7 +539,7 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
{
"id":"myResource1"
,"simpleFields":{
- "STATE_MODEL_DEF":"MasterSlave"
+ "STATE_MODEL_DEF":"STANDBY"
,"STATE_MODEL_FACTORY_NAME":"DEFAULT"
,"BUCKET_SIZE":"0"
,"SESSION_ID":"359619c2d7f109b"
@@ -548,19 +548,19 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
}
,"mapFields":{
"myResource1_2":{
- "CURRENT_STATE":"SLAVE"
+ "CURRENT_STATE":"STANDBY"
,"INFO":""
}
,"myResource1_3":{
- "CURRENT_STATE":"MASTER"
+ "CURRENT_STATE":"LEADER"
,"INFO":""
}
,"myResource1_0":{
- "CURRENT_STATE":"MASTER"
+ "CURRENT_STATE":"LEADER"
,"INFO":""
}
,"myResource1_1":{
- "CURRENT_STATE":"SLAVE"
+ "CURRENT_STATE":"STANDBY"
,"INFO":""
}
}
diff --git a/website/1.0.2/src/site/markdown/tutorial_state.md
b/website/1.0.2/src/site/markdown/tutorial_state.md
index 856b8b36f..c274a3cdb 100644
--- a/website/1.0.2/src/site/markdown/tutorial_state.md
+++ b/website/1.0.2/src/site/markdown/tutorial_state.md
@@ -51,11 +51,11 @@ In addition to the state machine configuration, one can
specify the constraints
For example, one can say:
-* MASTER:1
-<br/>Maximum number of replicas in MASTER state at any time is 1
+* LEADER:1
+<br/>Maximum number of replicas in LEADER state at any time is 1
-* OFFLINE-SLAVE:5
-<br/>Maximum number of OFFLINE-SLAVE transitions that can happen concurrently
in the system is 5 in this example.
+* OFFLINE-STANDBY:5
+<br/>Maximum number of OFFLINE-STANDBY transitions that can happen
concurrently in the system is 5 in this example.
#### Dynamic State Constraints
@@ -66,7 +66,7 @@ We also support two dynamic upper bounds for the number of
replicas in each stat
#### State Priority
-Helix uses a greedy approach to satisfy the state constraints. For example, if
the state machine configuration says it needs 1 MASTER and 2 SLAVES, but only 1
node is active, Helix must promote it to MASTER. This behavior is achieved by
providing the state priority list as \[MASTER, SLAVE\].
+Helix uses a greedy approach to satisfy the state constraints. For example, if
the state machine configuration says it needs 1 LEADER and 2 STANDBYS, but only
1 node is active, Helix must promote it to LEADER. This behavior is achieved by
providing the state priority list as \[LEADER, STANDBY\].
#### State Transition Priority
@@ -89,34 +89,34 @@ The ERROR state is used whenever the participant serving a
partition encountered
### Annotated Example
-Below is a complete definition of a Master-Slave state model. Notice the
fields marked REQUIRED; these are essential for any state model definition.
+Below is a complete definition of a Leader-Standby state model. Notice the
fields marked REQUIRED; these are essential for any state model definition.
```
-StateModelDefinition stateModel = new
StateModelDefinition.Builder("MasterSlave")
+StateModelDefinition stateModel = new
StateModelDefinition.Builder("LeaderStandby")
// OFFLINE is the state that the system starts in (initial state is REQUIRED)
.initialState("OFFLINE")
// Lowest number here indicates highest priority, no value indicates lowest
priority
- .addState("MASTER", 1)
- .addState("SLAVE", 2)
+ .addState("LEADER", 1)
+ .addState("STANDBY", 2)
.addState("OFFLINE")
// Note the special inclusion of the DROPPED state (REQUIRED)
.addState(HelixDefinedState.DROPPED.toString())
- // No more than one master allowed
- .upperBound("MASTER", 1)
+ // No more than one leader allowed
+ .upperBound("LEADER", 1)
// R indicates an upper bound of number of replicas for each partition
- .dynamicUpperBound("SLAVE", "R")
+ .dynamicUpperBound("STANDBY", "R")
// Add some high-priority transitions
- .addTransition("SLAVE", "MASTER", 1)
- .addTransition("OFFLINE", "SLAVE", 2)
+ .addTransition("STANDBY", "LEADER", 1)
+ .addTransition("OFFLINE", "STANDBY", 2)
// Using the same priority value indicates that these transitions can fire
in any order
- .addTransition("MASTER", "SLAVE", 3)
- .addTransition("SLAVE", "OFFLINE", 3)
+ .addTransition("LEADER", "STANDBY", 3)
+ .addTransition("STANDBY", "OFFLINE", 3)
// Not specifying a value defaults to lowest priority
// Notice the inclusion of the OFFLINE to DROPPED transition
diff --git a/website/1.0.2/src/site/markdown/tutorial_throttling.md
b/website/1.0.2/src/site/markdown/tutorial_throttling.md
index 16a6f8112..7c0f9c193 100644
--- a/website/1.0.2/src/site/markdown/tutorial_throttling.md
+++ b/website/1.0.2/src/site/markdown/tutorial_throttling.md
@@ -32,7 +32,7 @@ Since all state changes in the system are triggered through
transitions, Helix c
Helix allows applications to set a threshold on transitions. The threshold can
be set at multiple scopes:
* MessageType e.g STATE_TRANSITION
-* TransitionType e.g SLAVE-MASTER
+* TransitionType e.g STANDBY-LEADER
* Resource e.g database
* Node i.e per-node maximum transitions in parallel
diff --git a/website/1.0.3/src/site/markdown/Features.md
b/website/1.0.3/src/site/markdown/Features.md
index ba9d0e72d..476956a63 100644
--- a/website/1.0.3/src/site/markdown/Features.md
+++ b/website/1.0.3/src/site/markdown/Features.md
@@ -72,7 +72,7 @@ When the idealstate mode is set to AUTO_REBALANCE, Helix
controls both the locat
"IDEAL_STATE_MODE" : "AUTO_REBALANCE",
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
}
"listFields" : {
"MyResource_0" : [],
@@ -92,20 +92,20 @@ If there are 3 nodes in the cluster, then Helix will
internally compute the idea
"simpleFields" : {
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
},
"mapFields" : {
"MyResource_0" : {
- "N1" : "MASTER",
- "N2" : "SLAVE",
+ "N1" : "LEADER",
+ "N2" : "STANDBY",
},
"MyResource_1" : {
- "N2" : "MASTER",
- "N3" : "SLAVE",
+ "N2" : "LEADER",
+ "N3" : "STANDBY",
},
"MyResource_2" : {
- "N3" : "MASTER",
- "N1" : "SLAVE",
+ "N3" : "LEADER",
+ "N1" : "STANDBY",
}
}
}
@@ -125,7 +125,7 @@ When the idealstate mode is set to AUTO, Helix only
controls STATE of the replic
"IDEAL_STATE_MODE" : "AUTO",
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
}
"listFields" : {
"MyResource_0" : [node1, node2],
@@ -136,7 +136,7 @@ When the idealstate mode is set to AUTO, Helix only
controls STATE of the replic
}
}
```
-In this mode when node1 fails, unlike in AUTO-REBALANCE mode the partition is
not moved from node1 to others nodes in the cluster. Instead, Helix will decide
to change the state of MyResource_0 in N2 based on the system constraints. For
example, if a system constraint specified that there should be 1 Master and if
the Master failed, then node2 will be made the new master.
+In this mode when node1 fails, unlike in AUTO-REBALANCE mode the partition is
not moved from node1 to others nodes in the cluster. Instead, Helix will decide
to change the state of MyResource_0 in N2 based on the system constraints. For
example, if a system constraint specified that there should be 1 Master and if
the Master failed, then node2 will be made the new leader.
#### CUSTOM
@@ -150,27 +150,27 @@ Within this callback, the application can recompute the
idealstate. Helix will t
"IDEAL_STATE_MODE" : "CUSTOM",
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
},
"mapFields" : {
"MyResource_0" : {
- "N1" : "MASTER",
- "N2" : "SLAVE",
+ "N1" : "LEADER",
+ "N2" : "STANDBY",
},
"MyResource_1" : {
- "N2" : "MASTER",
- "N3" : "SLAVE",
+ "N2" : "LEADER",
+ "N3" : "STANDBY",
},
"MyResource_2" : {
- "N3" : "MASTER",
- "N1" : "SLAVE",
+ "N3" : "LEADER",
+ "N1" : "STANDBY",
}
}
}
```
-For example, the current state of the system might be 'MyResource_0' ->
{N1:MASTER,N2:SLAVE} and the application changes the ideal state to
'MyResource_0' -> {N1:SLAVE,N2:MASTER}. Helix will not blindly issue
MASTER-->SLAVE to N1 and SLAVE-->MASTER to N2 in parallel since it might result
in a transient state where both N1 and N2 are masters.
-Helix will first issue MASTER-->SLAVE to N1 and after its completed it will
issue SLAVE-->MASTER to N2.
+For example, the current state of the system might be 'MyResource_0' ->
{N1:LEADER,N2:STANDBY} and the application changes the ideal state to
'MyResource_0' -> {N1:STANDBY,N2:LEADER}. Helix will not blindly issue
LEADER-->STANDBY to N1 and STANDBY-->LEADER to N2 in parallel since it might
result in a transient state where both N1 and N2 are leaders.
+Helix will first issue LEADER-->STANDBY to N1 and after its completed it will
issue STANDBY-->LEADER to N2.
### State Machine Configuration
@@ -186,10 +186,10 @@ Apart from providing the state machine configuration, one
can specify the constr
For example one can say
Master:1. Max number of replicas in Master state at any time is 1.
-OFFLINE-SLAVE:5 Max number of Offline-Slave transitions that can happen
concurrently in the system
+OFFLINE-STANDBY:5 Max number of Offline-Slave transitions that can happen
concurrently in the system
STATE PRIORITY
-Helix uses greedy approach to satisfy the state constraints. For example if
the state machine configuration says it needs 1 master and 2 slaves but only 1
node is active, Helix must promote it to master. This behavior is achieved by
providing the state priority list as MASTER,SLAVE.
+Helix uses greedy approach to satisfy the state constraints. For example if
the state machine configuration says it needs 1 leader and 2 standbys but only
1 node is active, Helix must promote it to leader. This behavior is achieved by
providing the state priority list as LEADER,STANDBY.
STATE TRANSITION PRIORITY
Helix tries to fire as many transitions as possible in parallel to reach the
stable state without violating constraints. By default Helix simply sorts the
transitions alphabetically and fires as many as it can without violating the
constraints.
@@ -262,7 +262,7 @@ Since all state changes in the system are triggered through
transitions, Helix c
Helix allows applications to set threshold on transitions. The threshold can
be set at the multiple scopes.
* MessageType e.g STATE_TRANSITION
-* TransitionType e.g SLAVE-MASTER
+* TransitionType e.g STANDBY-LEADER
* Resource e.g database
* Node i.e per node max transitions in parallel.
diff --git a/website/1.0.3/src/site/markdown/tutorial_admin.md
b/website/1.0.3/src/site/markdown/tutorial_admin.md
index 6dd7cd853..465f6648f 100644
--- a/website/1.0.3/src/site/markdown/tutorial_admin.md
+++ b/website/1.0.3/src/site/markdown/tutorial_admin.md
@@ -161,7 +161,7 @@ chmod +x *.sh
* Add a resource to cluster
```
- curl -d
'jsonParameters={"command":"addResource","resourceGroupName":"MyDB","partitions":"8","stateModelDefRef":"MasterSlave"
}' -H "Content-Type: application/json"
http://localhost:8100/clusters/MyCluster/resourceGroups
+ curl -d
'jsonParameters={"command":"addResource","resourceGroupName":"MyDB","partitions":"8","stateModelDefRef":"LeaderStandby"
}' -H "Content-Type: application/json"
http://localhost:8100/clusters/MyCluster/resourceGroups
```
* _/clusters/{clusterName}/resourceGroups/{resourceName}_
@@ -202,15 +202,15 @@ chmod +x *.sh
"NUM_PARTITIONS" : "8",
"REBALANCE_MODE" : "SEMI_AUTO",
"REPLICAS" : "0",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
"STATE_MODEL_FACTORY_NAME" : "DEFAULT"
},
"listFields" : {
},
"mapFields" : {
"MyDB_0" : {
- "localhost_1001" : "MASTER",
- "localhost_1002" : "SLAVE"
+ "localhost_1001" : "LEADER",
+ "localhost_1002" : "STANDBY"
}
}
}
diff --git a/website/1.0.3/src/site/markdown/tutorial_rebalance.md
b/website/1.0.3/src/site/markdown/tutorial_rebalance.md
index 2e1a79b76..ec00ec065 100644
--- a/website/1.0.3/src/site/markdown/tutorial_rebalance.md
+++ b/website/1.0.3/src/site/markdown/tutorial_rebalance.md
@@ -57,7 +57,7 @@ Helix has four options for rebalancing, in increasing order
of customization by
When the rebalance mode is set to FULL_AUTO, Helix controls both the location
of the replica along with the state. This option is useful for applications
where creation of a replica is not expensive.
-For example, consider this system that uses a MasterSlave state model, with 3
partitions and 2 replicas in the ideal state.
+For example, consider this system that uses a LeaderStandby state model, with
3 partitions and 2 replicas in the ideal state.
```
{
@@ -66,7 +66,7 @@ For example, consider this system that uses a MasterSlave
state model, with 3 pa
"REBALANCE_MODE" : "FULL_AUTO",
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
}
"listFields" : {
"MyResource_0" : [],
@@ -78,7 +78,7 @@ For example, consider this system that uses a MasterSlave
state model, with 3 pa
}
```
-If there are 3 nodes in the cluster, then Helix will balance the masters and
slaves equally. The ideal state is therefore:
+If there are 3 nodes in the cluster, then Helix will balance the leaders and
standbys equally. The ideal state is therefore:
```
{
@@ -86,20 +86,20 @@ If there are 3 nodes in the cluster, then Helix will
balance the masters and sla
"simpleFields" : {
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
},
"mapFields" : {
"MyResource_0" : {
- "N1" : "MASTER",
- "N2" : "SLAVE",
+ "N1" : "LEADER",
+ "N2" : "STANDBY",
},
"MyResource_1" : {
- "N2" : "MASTER",
- "N3" : "SLAVE",
+ "N2" : "LEADER",
+ "N3" : "STANDBY",
},
"MyResource_2" : {
- "N3" : "MASTER",
- "N1" : "SLAVE",
+ "N3" : "LEADER",
+ "N1" : "STANDBY",
}
}
}
@@ -112,7 +112,7 @@ When one node fails, Helix redistributes its 15 tasks to
the remaining 3 nodes,
When the application needs to control the placement of the replicas, use the
SEMI_AUTO rebalance mode.
-Example: In the ideal state below, the partition \'MyResource_0\' is
constrained to be placed only on node1 or node2. The choice of _state_ is
still controlled by Helix. That means MyResource_0.MASTER could be on node1
and MyResource_0.SLAVE on node2, or vice-versa but neither would be placed on
node3.
+Example: In the ideal state below, the partition \'MyResource_0\' is
constrained to be placed only on node1 or node2. The choice of _state_ is
still controlled by Helix. That means MyResource_0.LEADER could be on node1
and MyResource_0.STANDBY on node2, or vice-versa but neither would be placed on
node3.
```
{
@@ -121,7 +121,7 @@ Example: In the ideal state below, the partition
\'MyResource_0\' is constrained
"REBALANCE_MODE" : "SEMI_AUTO",
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
}
"listFields" : {
"MyResource_0" : [node1, node2],
@@ -133,16 +133,16 @@ Example: In the ideal state below, the partition
\'MyResource_0\' is constrained
}
```
-The MasterSlave state model requires that a partition has exactly one MASTER
at all times, and the other replicas should be SLAVEs. In this simple example
with 2 replicas per partition, there would be one MASTER and one SLAVE. Upon
failover, a SLAVE has to assume mastership, and a new SLAVE will be generated.
+The LeaderStandby state model requires that a partition has exactly one LEADER
at all times, and the other replicas should be STANDBYs. In this simple
example with 2 replicas per partition, there would be one LEADER and one
STANDBY. Upon failover, a STANDBY has to assume leadership, and a new STANDBY
will be generated.
-In this mode when node1 fails, unlike in FULL_AUTO mode the partition is _not_
moved from node1 to node3. Instead, Helix will decide to change the state of
MyResource_0 on node2 from SLAVE to MASTER, based on the system constraints.
+In this mode when node1 fails, unlike in FULL_AUTO mode the partition is _not_
moved from node1 to node3. Instead, Helix will decide to change the state of
MyResource_0 on node2 from STANDBY to LEADER, based on the system constraints.
### CUSTOMIZED
Helix offers a third mode called CUSTOMIZED, in which the application controls
the placement _and_ state of each replica. The application needs to implement a
callback interface that Helix invokes when the cluster state changes.
Within this callback, the application can recompute the idealstate. Helix will
then issue appropriate transitions such that _Idealstate_ and _Currentstate_
converges.
-Here\'s an example, again with 3 partitions, 2 replicas per partition, and the
MasterSlave state model:
+Here\'s an example, again with 3 partitions, 2 replicas per partition, and the
LeaderStandby state model:
```
{
@@ -151,26 +151,26 @@ Here\'s an example, again with 3 partitions, 2 replicas
per partition, and the M
"REBALANCE_MODE" : "CUSTOMIZED",
"NUM_PARTITIONS" : "3",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
},
"mapFields" : {
"MyResource_0" : {
- "N1" : "MASTER",
- "N2" : "SLAVE",
+ "N1" : "LEADER",
+ "N2" : "STANDBY",
},
"MyResource_1" : {
- "N2" : "MASTER",
- "N3" : "SLAVE",
+ "N2" : "LEADER",
+ "N3" : "STANDBY",
},
"MyResource_2" : {
- "N3" : "MASTER",
- "N1" : "SLAVE",
+ "N3" : "LEADER",
+ "N1" : "STANDBY",
}
}
}
```
-Suppose the current state of the system is 'MyResource_0' \-\> {N1:MASTER,
N2:SLAVE} and the application changes the ideal state to 'MyResource_0' \-\>
{N1:SLAVE,N2:MASTER}. While the application decides which node is MASTER and
which is SLAVE, Helix will not blindly issue MASTER\-\-\>SLAVE to N1 and
SLAVE\-\-\>MASTER to N2 in parallel, since that might result in a transient
state where both N1 and N2 are masters, which violates the MasterSlave
constraint that there is exactly one MASTER [...]
+Suppose the current state of the system is 'MyResource_0' \-\> {N1:LEADER,
N2:STANDBY} and the application changes the ideal state to 'MyResource_0' \-\>
{N1:STANDBY,N2:LEADER}. While the application decides which node is LEADER and
which is STANDBY, Helix will not blindly issue LEADER\-\-\>STANDBY to N1 and
STANDBY\-\-\>LEADER to N2 in parallel, since that might result in a transient
state where both N1 and N2 are leaders, which violates the LeaderStandby
constraint that there is exactl [...]
### USER_DEFINED
diff --git a/website/1.0.3/src/site/markdown/tutorial_rest_service.md
b/website/1.0.3/src/site/markdown/tutorial_rest_service.md
index a2432b56d..b4c117e61 100644
--- a/website/1.0.3/src/site/markdown/tutorial_rest_service.md
+++ b/website/1.0.3/src/site/markdown/tutorial_rest_service.md
@@ -245,9 +245,9 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
* **GET** - get the state model definition
```
- $curl -X POST -H "Content-Type: application/json"
http://localhost:1234/admin/v2/clusters/myCluster/statemodeldefs/MasterSlave
+ $curl -X POST -H "Content-Type: application/json"
http://localhost:1234/admin/v2/clusters/myCluster/statemodeldefs/LeaderStandby
{
- "id" : "MasterSlave",
+ "id" : "STANDBY",
"simpleFields" : {
"INITIAL_STATE" : "OFFLINE"
},
@@ -262,34 +262,34 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
"DROPPED" : "DROPPED",
"OFFLINE" : "OFFLINE"
},
- "MASTER.meta" : {
+ "LEADER.meta" : {
"count" : "1"
},
- "MASTER.next" : {
- "SLAVE" : "SLAVE",
- "DROPPED" : "SLAVE",
- "OFFLINE" : "SLAVE"
+ "LEADER.next" : {
+ "STANDBY" : "STANDBY",
+ "DROPPED" : "STANDBY",
+ "OFFLINE" : "STANDBY"
},
"OFFLINE.meta" : {
"count" : "-1"
},
"OFFLINE.next" : {
- "SLAVE" : "SLAVE",
- "MASTER" : "SLAVE",
+ "STANDBY" : "STANDBY",
+ "LEADER" : "STANDBY",
"DROPPED" : "DROPPED"
},
- "SLAVE.meta" : {
+ "STANDBY.meta" : {
"count" : "R"
},
- "SLAVE.next" : {
- "MASTER" : "MASTER",
+ "STANDBY.next" : {
+ "LEADER" : "LEADER",
"DROPPED" : "OFFLINE",
"OFFLINE" : "OFFLINE"
}
},
"listFields" : {
- "STATE_PRIORITY_LIST" : [ "MASTER", "SLAVE", "OFFLINE", "DROPPED",
"ERROR" ],
- "STATE_TRANSITION_PRIORITYLIST" : [ "MASTER-SLAVE", "SLAVE-MASTER",
"OFFLINE-SLAVE", "SLAVE-OFFLINE", "OFFLINE-DROPPED" ]
+ "STATE_PRIORITY_LIST" : [ "LEADER", "STANDBY", "OFFLINE", "DROPPED",
"ERROR" ],
+ "STATE_TRANSITION_PRIORITYLIST" : [ "LEADER-STANDBY",
"STANDBY-LEADER", "OFFLINE-STANDBY", "STANDBY-OFFLINE", "OFFLINE-DROPPED" ]
}
}
```
@@ -364,7 +364,7 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
,"NUM_PARTITIONS":"2"
,"REBALANCE_MODE":"SEMI_AUTO"
,"REPLICAS":"2"
- ,"STATE_MODEL_DEF_REF":"MasterSlave"
+ ,"STATE_MODEL_DEF_REF":"STANDBY"
}
,"listFields":{
"myResource_0":["host1", "host2"]
@@ -372,12 +372,12 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
}
,"mapFields":{
"myResource_0":{
- "host1":"MASTER"
- ,"host2":"SLAVE"
+ "host1":"LEADER"
+ ,"host2":"STANDBY"
}
,"myResource_1":{
- "host1":"SLAVE"
- ,"host2":"MASTER"
+ "host1":"STANDBY"
+ ,"host2":"LEADER"
}
}
}
@@ -396,7 +396,7 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
,"NUM_PARTITIONS":"2"
,"REBALANCE_MODE":"SEMI_AUTO"
,"REPLICAS":"2"
- ,"STATE_MODEL_DEF_REF":"MasterSlave"
+ ,"STATE_MODEL_DEF_REF":"STANDBY"
}
,"listFields":{
"myResource_0":["host1", "host2"]
@@ -404,12 +404,12 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
}
,"mapFields":{
"myResource_0":{
- "host1":"MASTER"
+ "host1":"LEADER"
,"host2":"OFFLINE"
}
,"myResource_1":{
- "host1":"SLAVE"
- ,"host2":"MASTER"
+ "host1":"STANDBY"
+ ,"host2":"LEADER"
}
}
}
@@ -539,7 +539,7 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
{
"id":"myResource1"
,"simpleFields":{
- "STATE_MODEL_DEF":"MasterSlave"
+ "STATE_MODEL_DEF":"STANDBY"
,"STATE_MODEL_FACTORY_NAME":"DEFAULT"
,"BUCKET_SIZE":"0"
,"SESSION_ID":"359619c2d7f109b"
@@ -548,19 +548,19 @@ curl
http://localhost:12345/admin/v2/clusters/myCluster/resources/myResource/Ide
}
,"mapFields":{
"myResource1_2":{
- "CURRENT_STATE":"SLAVE"
+ "CURRENT_STATE":"STANDBY"
,"INFO":""
}
,"myResource1_3":{
- "CURRENT_STATE":"MASTER"
+ "CURRENT_STATE":"LEADER"
,"INFO":""
}
,"myResource1_0":{
- "CURRENT_STATE":"MASTER"
+ "CURRENT_STATE":"LEADER"
,"INFO":""
}
,"myResource1_1":{
- "CURRENT_STATE":"SLAVE"
+ "CURRENT_STATE":"STANDBY"
,"INFO":""
}
}
diff --git a/website/1.0.3/src/site/markdown/tutorial_state.md
b/website/1.0.3/src/site/markdown/tutorial_state.md
index 856b8b36f..c274a3cdb 100644
--- a/website/1.0.3/src/site/markdown/tutorial_state.md
+++ b/website/1.0.3/src/site/markdown/tutorial_state.md
@@ -51,11 +51,11 @@ In addition to the state machine configuration, one can
specify the constraints
For example, one can say:
-* MASTER:1
-<br/>Maximum number of replicas in MASTER state at any time is 1
+* LEADER:1
+<br/>Maximum number of replicas in LEADER state at any time is 1
-* OFFLINE-SLAVE:5
-<br/>Maximum number of OFFLINE-SLAVE transitions that can happen concurrently
in the system is 5 in this example.
+* OFFLINE-STANDBY:5
+<br/>Maximum number of OFFLINE-STANDBY transitions that can happen
concurrently in the system is 5 in this example.
#### Dynamic State Constraints
@@ -66,7 +66,7 @@ We also support two dynamic upper bounds for the number of
replicas in each stat
#### State Priority
-Helix uses a greedy approach to satisfy the state constraints. For example, if
the state machine configuration says it needs 1 MASTER and 2 SLAVES, but only 1
node is active, Helix must promote it to MASTER. This behavior is achieved by
providing the state priority list as \[MASTER, SLAVE\].
+Helix uses a greedy approach to satisfy the state constraints. For example, if
the state machine configuration says it needs 1 LEADER and 2 STANDBYS, but only
1 node is active, Helix must promote it to LEADER. This behavior is achieved by
providing the state priority list as \[LEADER, STANDBY\].
#### State Transition Priority
@@ -89,34 +89,34 @@ The ERROR state is used whenever the participant serving a
partition encountered
### Annotated Example
-Below is a complete definition of a Master-Slave state model. Notice the
fields marked REQUIRED; these are essential for any state model definition.
+Below is a complete definition of a Leader-Standby state model. Notice the
fields marked REQUIRED; these are essential for any state model definition.
```
-StateModelDefinition stateModel = new
StateModelDefinition.Builder("MasterSlave")
+StateModelDefinition stateModel = new
StateModelDefinition.Builder("LeaderStandby")
// OFFLINE is the state that the system starts in (initial state is REQUIRED)
.initialState("OFFLINE")
// Lowest number here indicates highest priority, no value indicates lowest
priority
- .addState("MASTER", 1)
- .addState("SLAVE", 2)
+ .addState("LEADER", 1)
+ .addState("STANDBY", 2)
.addState("OFFLINE")
// Note the special inclusion of the DROPPED state (REQUIRED)
.addState(HelixDefinedState.DROPPED.toString())
- // No more than one master allowed
- .upperBound("MASTER", 1)
+ // No more than one leader allowed
+ .upperBound("LEADER", 1)
// R indicates an upper bound of number of replicas for each partition
- .dynamicUpperBound("SLAVE", "R")
+ .dynamicUpperBound("STANDBY", "R")
// Add some high-priority transitions
- .addTransition("SLAVE", "MASTER", 1)
- .addTransition("OFFLINE", "SLAVE", 2)
+ .addTransition("STANDBY", "LEADER", 1)
+ .addTransition("OFFLINE", "STANDBY", 2)
// Using the same priority value indicates that these transitions can fire
in any order
- .addTransition("MASTER", "SLAVE", 3)
- .addTransition("SLAVE", "OFFLINE", 3)
+ .addTransition("LEADER", "STANDBY", 3)
+ .addTransition("STANDBY", "OFFLINE", 3)
// Not specifying a value defaults to lowest priority
// Notice the inclusion of the OFFLINE to DROPPED transition
diff --git a/website/1.0.3/src/site/markdown/tutorial_throttling.md
b/website/1.0.3/src/site/markdown/tutorial_throttling.md
index 16a6f8112..7c0f9c193 100644
--- a/website/1.0.3/src/site/markdown/tutorial_throttling.md
+++ b/website/1.0.3/src/site/markdown/tutorial_throttling.md
@@ -32,7 +32,7 @@ Since all state changes in the system are triggered through
transitions, Helix c
Helix allows applications to set a threshold on transitions. The threshold can
be set at multiple scopes:
* MessageType e.g STATE_TRANSITION
-* TransitionType e.g SLAVE-MASTER
+* TransitionType e.g STANDBY-LEADER
* Resource e.g database
* Node i.e per-node maximum transitions in parallel
diff --git a/website/src/site/markdown/Concepts.md
b/website/src/site/markdown/Concepts.md
index 7df3ae3eb..257448d2b 100644
--- a/website/src/site/markdown/Concepts.md
+++ b/website/src/site/markdown/Concepts.md
@@ -114,9 +114,9 @@ For increasing the availability of the system, it\'s better
to place the replica
### State
-Now let\'s take a slightly more complicated scenario where a task represents a
database. Unlike an index which is in general read-only, a database supports
both reads and writes. Keeping the data consistent among the replicas is
crucial in distributed data stores. One commonly applied technique is to assign
one replica as the MASTER and remaining replicas as SLAVEs. All writes go to
the MASTER and are then replicated to the SLAVE replicas.
+Now let\'s take a slightly more complicated scenario where a task represents a
database. Unlike an index which is in general read-only, a database supports
both reads and writes. Keeping the data consistent among the replicas is
crucial in distributed data stores. One commonly applied technique is to assign
one replica as the LEADER and remaining replicas as STANDBYs. All writes go to
the LEADER and are then replicated to the STANDBY replicas.
-Helix allows one to assign different __states__ to each replica. Let\'s say
you have two MySQL instances N1 and N2, where one will serve as MASTER and
another as SLAVE. The IdealState can be changed to:
+Helix allows one to assign different __states__ to each replica. Let\'s say
you have two MySQL instances N1 and N2, where one will serve as LEADER and
another as STANDBY. The IdealState can be changed to:
```
{
@@ -127,8 +127,8 @@ Helix allows one to assign different __states__ to each
replica. Let\'s say you
},
"mapFields" : {
"myDB" : {
- "N1" : "MASTER",
- "N2" : "SLAVE",
+ "N1" : "LEADER",
+ "N2" : "STANDBY",
}
}
}
@@ -144,20 +144,20 @@ The next logical question is: how does the controller
compute the transitions re
* __State__: Describes the role of a replica
* __Transition__: An action that allows a replica to move from one state to
another, thus changing its role.
-Here is an example of MasterSlave state machine:
+Here is an example of LeaderStandby state machine:
```
- OFFLINE | SLAVE | MASTER
- _____________________________
- | | | |
-OFFLINE | N/A | SLAVE | SLAVE |
- |__________|________|_________|
- | | | |
-SLAVE | OFFLINE | N/A | MASTER |
- |__________|________|_________|
- | | | |
-MASTER | SLAVE | SLAVE | N/A |
- |__________|________|_________|
+ OFFLINE | STANDBY | LEADER
+ ______________________________
+ | | | |
+OFFLINE | N/A | STANDBY | STANDBY |
+ |__________|_________|_________|
+ | | | |
+STANDBY | OFFLINE | N/A | LEADER |
+ |__________|_________|_________|
+ | | | |
+LEADER | STANDBY | STANDBY | N/A |
+ |__________|_________|_________|
```
@@ -169,12 +169,12 @@ Helix allows each resource to be associated with one
state machine. This means y
"simpleFields" : {
"NUM_PARTITIONS" : "1",
"REPLICAS" : "2",
- "STATE_MODEL_DEF_REF" : "MasterSlave",
+ "STATE_MODEL_DEF_REF" : "LeaderStandby",
},
"mapFields" : {
"myDB" : {
- "N1" : "MASTER",
- "N2" : "SLAVE",
+ "N1" : "LEADER",
+ "N2" : "STANDBY",
}
}
}
@@ -194,17 +194,17 @@ The __CurrentState__ of a resource simply represents its
actual state at a parti
,"simpleFields":{
,"SESSION_ID":"13d0e34675e0002"
,"INSTANCE_NAME":"node1"
- ,"STATE_MODEL_DEF":"MasterSlave"
+ ,"STATE_MODEL_DEF":"LeaderStandby"
}
,"mapFields":{
"MyResource_0":{
- "CURRENT_STATE":"SLAVE"
+ "CURRENT_STATE":"STANDBY"
}
,"MyResource_1":{
- "CURRENT_STATE":"MASTER"
+ "CURRENT_STATE":"LEADER"
}
,"MyResource_2":{
- "CURRENT_STATE":"MASTER"
+ "CURRENT_STATE":"LEADER"
}
}
}
@@ -221,19 +221,19 @@ In order to communicate with the participants, external
clients need to know the
"id":"MyResource",
"mapFields":{
"MyResource_0":{
- "N1":"SLAVE",
- "N2":"MASTER",
+ "N1":"STANDBY",
+ "N2":"LEADER",
"N3":"OFFLINE"
},
"MyResource_1":{
- "N1":"MASTER",
- "N2":"SLAVE",
+ "N1":"LEADER",
+ "N2":"STANDBY",
"N3":"ERROR"
},
"MyResource_2":{
- "N1":"MASTER",
- "N2":"SLAVE",
- "N3":"SLAVE"
+ "N1":"LEADER",
+ "N2":"STANDBY",
+ "N3":"STANDBY"
}
}
}
