From 9194e33cf9509c10cf201a906eff60bb419609cb Mon Sep 17 00:00:00 2001 From: Philip O'Toole Date: Tue, 1 Nov 2016 21:39:51 -0700 Subject: [PATCH] Update CLUSTER_MGMT.md --- doc/CLUSTER_MGMT.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/CLUSTER_MGMT.md b/doc/CLUSTER_MGMT.md index 4f385f38..c21b4a3a 100644 --- a/doc/CLUSTER_MGMT.md +++ b/doc/CLUSTER_MGMT.md @@ -35,7 +35,7 @@ _When restarting a node, there is no further need to pass `-join`. It will be ig You've now got a fault-tolerant, distributed, relational database. It can tolerate the failure of any node, even the leader, and remain operational. ## Through the firewall -On some networks, like AWS EC2 cloud, nodes may have an IP address that is not routable from outside the firewall. Instead these nodes are addressed using a different IP address. You can still form rqlite cluster however -- check out [this tutorial](http://www.philipotoole.com/rqlite-v3-0-1-globally-replicating-sqlite/) for more details. +On some networks, like AWS EC2 cloud, nodes may have an IP address that is not routable from outside the firewall. Instead these nodes are addressed using a different IP address. You can still form a rqlite cluster however -- check out [this tutorial](http://www.philipotoole.com/rqlite-v3-0-1-globally-replicating-sqlite/) for more details. # Dealing with failure It is the nature of clustered systems, nodes can fail at anytime. Depending on the size of your cluster, it will tolerate various amounts of failure. With a 3-node cluster, it can tolerate the failure of a single node, including the leader.