Mirroristas/bigchaindb
2
0
Fork 0
mirror of https://github.com/bigchaindb/bigchaindb.git synced 2024-10-13 13:34:05 +00:00
Code Issues Packages Projects Releases Wiki Activity

updated set-up-a-cluster.md in server docs

Browse Source
This commit is contained in:
Troy McConaghy 2017-04-12 14:55:56 +02:00
parent ad37441115
commit ee3c7f607c
1 changed files with 12 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
docs/server/source/clusters-feds/set-up-a-cluster.md
View File

@ -3,7 +3,9 @@
This section is about how to set up a BigchainDB cluster where each node is operated by a different operator. If you want to set up and run a testing cluster on AWS (where all nodes are operated by you), then see [the section about that](aws-testing-cluster.html). This section is about how to set up a BigchainDB cluster where each node is operated by a different operator. If you want to set up and run a testing cluster on AWS (where all nodes are operated by you), then see [the section about that](aws-testing-cluster.html).
## Initial Checklist ## Initial Questions
There are many questions that must be answered before setting up a BigchainDB cluster. For example:
* Do you have a governance process for making consortium-level decisions, such as how to admit new members? * Do you have a governance process for making consortium-level decisions, such as how to admit new members?
* What will you store in creation transactions (data payload)? Is there a data schema? * What will you store in creation transactions (data payload)? Is there a data schema?
@ -15,14 +17,16 @@ This section is about how to set up a BigchainDB cluster where each node is oper
The consortium must decide some things before setting up the initial cluster (initial set of BigchainDB nodes): The consortium must decide some things before setting up the initial cluster (initial set of BigchainDB nodes):
1. Who will operate a node in the initial cluster? 1. Who will operate each node in the initial cluster?
2. What will the replication factor be? (It must be 3 or more for [RethinkDB failover](https://rethinkdb.com/docs/failover/) to work.) 2. What will the replication factor be? (It should be 3 or more.)
3. Which node will be responsible for sending the commands to configure the RethinkDB database? 3. Who will deploy the first node?
4. Who will add subsequent nodes? (It must be one of the existing nodes.)
Once those things have been decided, each node operator can begin setting up their BigchainDB (production) node. Once those things have been decided, the cluster deployment process can begin. The process for deploying a production node is outlined in the section on production nodes.
Each node operator will eventually need two pieces of information from all other nodes: Each BigchainDB node operator will eventually need some information from all other nodes:
1. Their RethinkDB hostname, e.g. `rdb.farm2.organization.org` 1. Their BigchainDB public key, e.g. `Eky3nkbxDTMgkmiJC8i5hKyVFiAQNmPP4a2G4JdDxJCK`
2. Their BigchainDB public key, e.g. `Eky3nkbxDTMgkmiJC8i5hKyVFiAQNmPP4a2G4JdDxJCK` 1. Their MongoDB hostname and port, e.g. `mdb.farm2.organization.org:27017`
To secure communications, more information will be needed.