From d7c6b1ebcf24388f844236a95018b8a2ec2e65f0 Mon Sep 17 00:00:00 2001 From: Ginger Collison Date: Wed, 5 Jun 2019 17:39:52 -0500 Subject: [PATCH] Update upgrading_cluster.md --- nats_admin/upgrading_cluster.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/nats_admin/upgrading_cluster.md b/nats_admin/upgrading_cluster.md index f3997cd..3eb96da 100644 --- a/nats_admin/upgrading_cluster.md +++ b/nats_admin/upgrading_cluster.md @@ -4,7 +4,7 @@ The basic strategy for upgrading a cluster revolves around the server's ability Note that since each server stores it's own permission and authentication configuration, new servers added to a cluster should provide the same users and authorization to prevent clients from getting rejected or gaining unexpected privileges. -For purposes of describing the scenario, let's get some fingers on keyboards, and go through the motions. Let's consider a cluster of two servers: 'A' and 'B.', and yes - clusters should be *three* to *five* servers, but for purposes of describing the behavior and cluster upgrade process, a cluster of two servers will suffice. +For purposes of describing the scenario, let's get some fingers on keyboards, and go through the motions. Let's consider a cluster of two servers: 'A' and 'B', and yes - clusters should be *three* to *five* servers, but for purposes of describing the behavior and cluster upgrade process, a cluster of two servers will suffice. Let's build this cluster: