You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: Documentation/Books/HTTP/Agency/README.md
+8-8Lines changed: 8 additions & 8 deletions
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
HTTP Interface for Agency feature
2
2
=================================
3
3
4
-
The Agency is the ArangoDB component which manages the entire ArangoDB cluster. ArangoDB itself mainly uses the Agency as a central place to store the configuration and the cluster nodes health management. It implements the Raft concensus protocol to act as the single-source of truth for the entire cluster. You may know other software providing similar functionality e.g. Apache Zookeeper, etcd or Consul.
4
+
The Agency is the ArangoDB component which manages the entire ArangoDB cluster. ArangoDB itself mainly uses the Agency as a central place to store the configuration and the cluster nodes health management. It implements the Raft consensus protocol to act as the single-source of truth for the entire cluster. You may know other software providing similar functionality e.g. Apache Zookeeper, etcd or Consul.
5
5
6
6
To an end-user the Agency is essentially a fault-tolerant Key-Value Store with a simple REST-API. It is possible to use the Agency API for a variety of use-cases, for example:
7
7
@@ -18,7 +18,7 @@ Note 2: The key-prefix /arango contains ArangoDBs internal configuration. You sh
18
18
19
19
Generally, all document IO to and from the key-value store consists of JSON arrays. The outer Array is an envelope for multiple read or write transactions. The results are arrays are an envelope around the results corresponding to the order of the incoming transactions.
20
20
21
-
Consider the following write operation into a prestine agency:
21
+
Consider the following write operation into a pristine agency:
In the first step we commited a single transaction that commits the JSON document inside the inner transaction array to the agency. The result is `[1]`, which is the replicated log index. Repeated invocation will yield growing log numbers 2, 3, 4, etc.
51
+
In the first step we committed a single transaction that commits the JSON document inside the inner transaction array to the agency. The result is `[1]`, which is the replicated log index. Repeated invocation will yield growing log numbers 2, 3, 4, etc.
52
52
53
53
The read access is a complete access to the key-value store indicated by access to it's root element and returns the result as an array corresponding to the outermost array in the read transaction.
54
54
55
55
Let's dig in some deeper.
56
56
57
57
### Read API
58
58
59
-
Let's start with the above initialised key-value store in the following. Let us visit the following read operations:
59
+
Let's start with the above initialized key-value store in the following. Let us visit the following read operations:
Note that the above results are identical, meaning that results obtained from the agencyare always return with full path.
93
+
Note that the above results are identical, meaning that results obtained from the agency are always return with full path.
94
94
95
95
The second outer array brackets in read operations correspond to transactions, meaning that the result is guaranteed to have been acquired without a write transaction in between:
While the first transaction consists of a single read access to the key-value-store thus strechting the meaning of the word transaction, the second bracket actually hold two disjunct read accesses, which have been joined within zero-time, i.e. without a write access in between. That is to say that `"/d"` cannot have changed before `"/a/b"` had been acquired.
119
+
While the first transaction consists of a single read access to the key-value-store thus stretching the meaning of the word transaction, the second bracket actually hold two disjunct read accesses, which have been joined within zero-time, i.e. without a write access in between. That is to say that `"/d"` cannot have changed before `"/a/b"` had been acquired.
120
120
121
121
Let's try to fetch a value from the key-value-store, which does not exist:
122
122
@@ -182,7 +182,7 @@ is a precondition specifying that the previous value of the key `"/a/b/c"` key m
182
182
{ "/a/b/c": [1, 2, 3] }
183
183
```
184
184
185
-
Consider the agency in initialised as above let's review the responses from the agency as follows:
185
+
Consider the agency in initialized as above let's review the responses from the agency as follows:
@@ -393,4 +393,4 @@ The output might look somewhat like this
393
393
394
394
This is the actual output of a healthy agency. The configuration of the agency is found in the `configuration` section as you might have guessed. It is populated by static information on the startup parameters like `agency size`, the once generated `unique id` etc. It holds information on the invariants of the RAFT algorithm and data compaction.
395
395
396
-
The remaining data reflect the variant entities in RAFT, as `term` and `leaderId`, also some debug information on how long the last leadership vote was received from any particular agency member. Low term numbers on a healthy network are an indication of good operation environemnt, while often increasing term numbers indicate, that the network environemnt and stability suggest to raise the RAFT parameters `min ping` and 'max ping' accordingly.
396
+
The remaining data reflect the variant entities in RAFT, as `term` and `leaderId`, also some debug information on how long the last leadership vote was received from any particular agency member. Low term numbers on a healthy network are an indication of good operation environment, while often increasing term numbers indicate, that the network environment and stability suggest to raise the RAFT parameters `min ping` and 'max ping' accordingly.
0 commit comments