diff --git a/docker-compose.network.yml b/docker-compose.network.yml index 311b8035..38a4b5c4 100644 --- a/docker-compose.network.yml +++ b/docker-compose.network.yml @@ -30,7 +30,7 @@ services: TENDERMINT_HOST: tendermint-one ports: - "9984" - command: bigchaindb -l DEBUG start --init + command: bigchaindb -l DEBUG start tendermint-one: image: tendermint/tendermint volumes: @@ -67,7 +67,7 @@ services: TENDERMINT_HOST: tendermint-two ports: - "9984" - command: bigchaindb -l DEBUG start --init + command: bigchaindb -l DEBUG start tendermint-two: image: tendermint/tendermint volumes: @@ -104,7 +104,7 @@ services: TENDERMINT_HOST: tendermint-three ports: - "9984" - command: bigchaindb -l DEBUG start --init + command: bigchaindb -l DEBUG start tendermint-three: image: tendermint/tendermint volumes: @@ -141,7 +141,7 @@ services: TENDERMINT_HOST: tendermint-four ports: - "9984" - command: bigchaindb -l DEBUG start --init + command: bigchaindb -l DEBUG start tendermint-four: image: tendermint/tendermint volumes: diff --git a/docker-compose.tendermint.yml b/docker-compose.tendermint.yml index 966368c4..2c43b36a 100644 --- a/docker-compose.tendermint.yml +++ b/docker-compose.tendermint.yml @@ -29,7 +29,7 @@ services: TENDERMINT_PORT: 46657 ports: - "9984" - command: bigchaindb -l DEBUG start --init + command: bigchaindb -l DEBUG start tendermint: image: tendermint/tendermint volumes: diff --git a/docs/server/source/appendices/index.rst b/docs/server/source/appendices/index.rst index ae2052f0..2fb1f44a 100755 --- a/docs/server/source/appendices/index.rst +++ b/docs/server/source/appendices/index.rst @@ -1,6 +1,3 @@ -.. You can adapt this file completely to your liking, but it should at least - contain the root `toctree` directive. - Appendices ========== @@ -8,12 +5,10 @@ Appendices :maxdepth: 1 install-os-level-deps - install-latest-pip run-with-docker json-serialization cryptography the-Bigchain-class - pipelines backend commands aws-setup @@ -22,10 +17,7 @@ Appendices generate-key-pair-for-ssh firewall-notes ntp-notes - rethinkdb-reqs - rethinkdb-backup licenses - install-with-lxd run-with-vagrant run-with-ansible vote-yaml diff --git a/docs/server/source/appendices/install-latest-pip.md b/docs/server/source/appendices/install-latest-pip.md deleted file mode 100644 index fc992fee..00000000 --- a/docs/server/source/appendices/install-latest-pip.md +++ /dev/null @@ -1,20 +0,0 @@ -# How to Install the Latest pip and setuptools - -You can check the version of `pip` you're using (in your current virtualenv) by doing: -```text -pip -V -``` - -If it says that `pip` isn't installed, or it says `pip` is associated with a Python version less than 3.5, then you must install a `pip` version associated with Python 3.5+. In the following instructions, we call it `pip3` but you may be able to use `pip` if that refers to the same thing. See [the `pip` installation instructions](https://pip.pypa.io/en/stable/installing/). - -On Ubuntu 16.04, we found that this works: -```text -sudo apt-get install python3-pip -``` - -That should install a Python 3 version of `pip` named `pip3`. If that didn't work, then another way to get `pip3` is to do `sudo apt-get install python3-setuptools` followed by `sudo easy_install3 pip`. - -You can upgrade `pip` (`pip3`) and `setuptools` to the latest versions using: -```text -pip3 install --upgrade pip setuptools -``` diff --git a/docs/server/source/appendices/install-with-lxd.md b/docs/server/source/appendices/install-with-lxd.md deleted file mode 100644 index 969f6841..00000000 --- a/docs/server/source/appendices/install-with-lxd.md +++ /dev/null @@ -1,43 +0,0 @@ -# Installing BigchainDB on LXC containers using LXD - -**Note: This page was contributed by an external contributor and is not actively maintained. We include it in case someone is interested.** - -You can visit this link to install LXD (instructions here): [LXD Install](https://linuxcontainers.org/lxd/getting-started-cli/) - -(assumption is that you are using Ubuntu 14.04 for host/container) - -Let us create an LXC container (via LXD) with the following command: - -`lxc launch ubuntu:14.04 bigchaindb` - -(ubuntu:14.04 - this is the remote server the command fetches the image from) -(bigchaindb - is the name of the container) - -Below is the `install.sh` script you will need to install BigchainDB within your container. - -Here is my `install.sh`: - -``` -#!/bin/bash -set -ex -export DEBIAN_FRONTEND=noninteractive -apt-get install -y wget -source /etc/lsb-release && echo "deb http://download.rethinkdb.com/apt $DISTRIB_CODENAME main" | sudo tee /etc/apt/sources.list.d/rethinkdb.list -wget -qO- https://download.rethinkdb.com/apt/pubkey.gpg | sudo apt-key add - -apt-get update -apt-get install -y rethinkdb python3-pip -pip3 install --upgrade pip wheel setuptools -pip install ptpython bigchaindb -``` - -Copy/Paste the above `install.sh` into the directory/path you are going to execute your LXD commands from (ie. the host). - -Make sure your container is running by typing: - -`lxc list` - -Now, from the host (and the correct directory) where you saved `install.sh`, run this command: - -`cat install.sh | lxc exec bigchaindb /bin/bash` - -If you followed the commands correctly, you will have successfully created an LXC container (using LXD) that can get you up and running with BigchainDB in <5 minutes (depending on how long it takes to download all the packages). diff --git a/docs/server/source/appendices/pipelines.rst b/docs/server/source/appendices/pipelines.rst deleted file mode 100644 index 8016e8cb..00000000 --- a/docs/server/source/appendices/pipelines.rst +++ /dev/null @@ -1,26 +0,0 @@ -######### -Pipelines -######### - -Block Creation -============== - -.. automodule:: bigchaindb.pipelines.block - - -Block Voting -============ - -.. automodule:: bigchaindb.pipelines.vote - - -Block Status -============ - -.. automodule:: bigchaindb.pipelines.election - - -Stale Transaction Monitoring -============================ - -.. automodule:: bigchaindb.pipelines.stale diff --git a/docs/server/source/appendices/rethinkdb-backup.md b/docs/server/source/appendices/rethinkdb-backup.md deleted file mode 100644 index dc33231e..00000000 --- a/docs/server/source/appendices/rethinkdb-backup.md +++ /dev/null @@ -1,124 +0,0 @@ -# Backing Up and Restoring Data - -This page was written when BigchainDB only worked with RethinkDB, so its focus is on RethinkDB-based backup. BigchainDB now supports MongoDB as a backend database and we recommend that you use MongoDB in production. Nevertheless, some of the following backup ideas are still relevant regardless of the backend database being used, so we moved this page to the Appendices. - - -## RethinkDB's Replication as a form of Backup - -RethinkDB already has internal replication: every document is stored on _R_ different nodes, where _R_ is the replication factor (set using `bigchaindb set-replicas R`). Those replicas can be thought of as "live backups" because if one node goes down, the cluster will continue to work and no data will be lost. - -At this point, there should be someone saying, "But replication isn't backup!" - -It's true. Replication alone isn't enough, because something bad might happen _inside_ the database, and that could affect the replicas. For example, what if someone logged in as a RethinkDB admin and did a "drop table"? We currently plan for each node to be protected by a next-generation firewall (or something similar) to prevent such things from getting very far. For example, see [issue #240](https://github.com/bigchaindb/bigchaindb/issues/240). - -Nevertheless, you should still consider having normal, "cold" backups, because bad things can still happen. - - -## Live Replication of RethinkDB Data Files - -Each BigchainDB node stores its subset of the RethinkDB data in one directory. You could set up the node's file system so that directory lives on its own hard drive. Furthermore, you could make that hard drive part of a [RAID](https://en.wikipedia.org/wiki/RAID) array, so that a second hard drive would always have a copy of the original. If the original hard drive fails, then the second hard drive could take its place and the node would continue to function. Meanwhile, the original hard drive could be replaced. - -That's just one possible way of setting up the file system so as to provide extra reliability. - -Another way to get similar reliability would be to mount the RethinkDB data directory on an [Amazon EBS](https://aws.amazon.com/ebs/) volume. Each Amazon EBS volume is, "automatically replicated within its Availability Zone to protect you from component failure, offering high availability and durability." - -As with shard replication, live file-system replication protects against many failure modes, but it doesn't protect against them all. You should still consider having normal, "cold" backups. - - -## rethinkdb dump (to a File) - -RethinkDB can create an archive of all data in the cluster (or all data in specified tables), as a compressed file. According to [the RethinkDB blog post when that functionality became available](https://rethinkdb.com/blog/1.7-release/): - -> Since the backup process is using client drivers, it automatically takes advantage of the MVCC [multiversion concurrency control] functionality built into RethinkDB. It will use some cluster resources, but will not lock out any of the clients, so you can safely run it on a live cluster. - -To back up all the data in a BigchainDB cluster, the RethinkDB admin user must run a command like the following on one of the nodes: -```text -rethinkdb dump -e bigchain.bigchain -e bigchain.votes -``` - -That should write a file named `rethinkdb_dump__