mirror of
https://github.com/taigrr/nats.docs
synced 2025-01-18 04:03:23 -08:00
updating docs
This commit is contained in:
ainsley
@@ -2354,7 +2354,7 @@
|
||||
<section class="normal markdown-section">
|
||||
|
||||
<h2 id="cluster-upgrading"><a name="cluster-upgrading" class="plugin-anchor" href="#cluster-upgrading"><i class="fa fa-link" aria-hidden="true"></i></a>Cluster Upgrading</h2>
|
||||
<p>The basic strategy for upgrading a cluster revolves around the server's ability to gossip cluster configuration to clients and other servers. When cluster configuration changes, clients become aware of new servers automatically. In case of a disconnect, a client has a list of servers that joined the cluster in addition to the ones it knew about from its connection settings. </p>
|
||||
<p>The basic strategy for upgrading a cluster revolves around the server's ability to gossip cluster configuration to clients and other servers. When cluster configuration changes, clients become aware of new servers automatically. In the case of a disconnect, a client has a list of servers that joined the cluster in addition to the ones it knew about from its connection settings. </p>
|
||||
<p>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.</p>
|
||||
<p>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 <em>three</em> to <em>five</em> servers, but for purposes of describing the behavior and cluster upgrade process, a cluster of two servers will suffice. </p>
|
||||
<p>Let's build this cluster:</p>
|
||||
@@ -2369,25 +2369,25 @@ to other servers. These URLs define the cluster ports enabled on the cluster pee
|
||||
<p>Let's fix that, by starting the second server:</p>
|
||||
<pre class="language-"><code class="lang-bash">nats-server -D -p 4333 -cluster nats://localhost:6333 -routes nats://localhost:6222,nats://localhost:6333
|
||||
</code></pre>
|
||||
<p>The second server was started on port 4333 with its cluster port on 6333. Otherwise the same as 'A.'</p>
|
||||
<p>The second server was started on port 4333 with its cluster port on 6333. Otherwise the same as 'A'.</p>
|
||||
<p>Let's get one client, so we can observe it moving between servers as servers get removed:</p>
|
||||
<pre class="language-"><code class="lang-bash">nats-sub -s nats://localhost:4222 <span class="token string">">"</span>
|
||||
</code></pre>
|
||||
<p>Nats-sub is a subscriber sample included with all NATS clients. Nats-sub subscribes to a subject and prints out any messages received. You can find the source code to the go version of nats-sub [here)(<a href="https://github.com/nats-io/go-nats/tree/master/examples" target="_blank">https://github.com/nats-io/go-nats/tree/master/examples</a>). After starting the subscriber you should see a message on 'A' that a new client connected.</p>
|
||||
<p>We have two servers and a client. Time to simulate our rolling upgrade. But wait, before we upgrade 'A,' let's introduce a new server 'T.' Server 'T' will join the existing cluster while we perform the upgrade. Its sole purpose is to provide an additional place where clients can go besides 'A.' and ensure we don't end up with a single server serving all the clients after the upgrade procedure. Clients will randomly select a server when connecting unless a special option is provided that disables that functionality (usually called 'DontRandomize' or 'noRandomize'). You can read more about <a href="../developer/reconnect/random.html">"Avoiding the Thundering Herd"</a>.
|
||||
Suffice it to say that clients redistribute themselves about evenly between all servers in the cluster. In our case 1/2 of the clients on 'A' will jump over to 'B' and the remaining half to 'T.'</p>
|
||||
<p><code>nats-sub</code> is a subscriber sample included with all NATS clients. <code>nats-sub</code> subscribes to a subject and prints out any messages received. You can find the source code to the go version of <code>nats-sub</code> [here)(<a href="https://github.com/nats-io/nats.go/tree/master/examples" target="_blank">https://github.com/nats-io/nats.go/tree/master/examples</a>). After starting the subscriber you should see a message on 'A' that a new client connected.</p>
|
||||
<p>We have two servers and a client. Time to simulate our rolling upgrade. But wait, before we upgrade 'A', let's introduce a new server 'C'. Server 'C' will join the existing cluster while we perform the upgrade. Its sole purpose is to provide an additional place where clients can go other than 'A' and ensure we don't end up with a single server serving all the clients after the upgrade procedure. Clients will randomly select a server when connecting unless a special option is provided that disables that functionality (usually called 'DontRandomize' or 'noRandomize'). You can read more about <a href="../developer/reconnect/random.html">"Avoiding the Thundering Herd"</a>.
|
||||
Suffice it to say that clients redistribute themselves about evenly between all servers in the cluster. In our case 1/2 of the clients on 'A' will jump over to 'B' and the remaining half to 'C'.</p>
|
||||
<p>Let's start our temporary server:</p>
|
||||
<pre class="language-"><code class="lang-bash">nats-server -D -p 4444 -cluster nats://localhost:6444 -routes nats://localhost:6222,nats://localhost:6333
|
||||
</code></pre>
|
||||
<p>After an instant or so, clients on 'A' learn of the new cluster member that joined. On our hands-on tutorial, <code>nats-sub</code> is now aware of 3 possible servers, 'A' (specified when we started the tool) and 'B' and 'T' learned from the cluster gossip.</p>
|
||||
<p>We invoke our admin powers and turn off 'A' by issuing a <code>CTRL+C</code> to the terminal on 'A,' and observe that either 'B' or 'T' reports that a new client connected. That is our <code>nats-sub</code> client.</p>
|
||||
<p>After an instant or so, clients on 'A' learn of the new cluster member that joined. On our hands-on tutorial, <code>nats-sub</code> is now aware of 3 possible servers, 'A' (specified when we started the tool) and 'B' and 'C' learned from the cluster gossip.</p>
|
||||
<p>We invoke our admin powers and turn off 'A' by issuing a <code>CTRL+C</code> to the terminal on 'A' and observe that either 'B' or 'C' reports that a new client connected. That is our <code>nats-sub</code> client.</p>
|
||||
<p>We perform the upgrade process, update the binary for 'A', and restart 'A':</p>
|
||||
<pre class="language-"><code class="lang-bash">nats-server -D -p 4222 -cluster nats://localhost:6222 -routes nats://localhost:6222,nats://localhost:6333
|
||||
</code></pre>
|
||||
<p>We move on to upgrade 'B'. Notice that clients from 'B' reconnect to 'A' and 'T'. We upgrade and restart 'B':</p>
|
||||
<p>We move on to upgrade 'B'. Notice that clients from 'B' reconnect to 'A' and 'C'. We upgrade and restart 'B':</p>
|
||||
<pre class="language-"><code class="lang-bash">nats-server -D -p 4333 -cluster nats://localhost:6333 -routes nats://localhost:6222,nats://localhost:6333
|
||||
</code></pre>
|
||||
<p>If we had more servers, we would continue the stop, update, restart rotation as we did for 'A' and 'B.' After restarting the last server, we can go ahead and turn off 'T.' Any clients on 'T' will redistribute to our permanent cluster members.</p>
|
||||
<p>If we had more servers, we would continue the stop, update, restart rotation as we did for 'A' and 'B'. After restarting the last server, we can go ahead and turn off 'C.' Any clients on 'C' will redistribute to our permanent cluster members.</p>
|
||||
<h3 id="seed-servers"><a name="seed-servers" class="plugin-anchor" href="#seed-servers"><i class="fa fa-link" aria-hidden="true"></i></a>Seed Servers</h3>
|
||||
<p>In the examples above we started nats-server specifying two clustering routes. It is possible to allow the server gossip protocol drive it and reduce the amount of configuration. You could for example start A, B and C as follows:</p>
|
||||
<h4 id="a---seed-server"><a name="a---seed-server" class="plugin-anchor" href="#a---seed-server"><i class="fa fa-link" aria-hidden="true"></i></a>A - Seed Server</h4>
|
||||
@@ -2399,7 +2399,7 @@ Suffice it to say that clients redistribute themselves about evenly between all
|
||||
<h4 id="c"><a name="c" class="plugin-anchor" href="#c"><i class="fa fa-link" aria-hidden="true"></i></a>C</h4>
|
||||
<pre class="language-"><code class="lang-bash">nats-server -D -p 4444 -cluster nats://localhost:6444 -routes nats://localhost:6222
|
||||
</code></pre>
|
||||
<p>Once they connect to the 'seed server', the will learn about all the other servers and connect to each other forming the full mesh.</p>
|
||||
<p>Once they connect to the 'seed server', they will learn about all the other servers and connect to each other forming the full mesh.</p>
|
||||
|
||||
|
||||
</section>
|
||||
@@ -2443,7 +2443,7 @@ Suffice it to say that clients redistribute themselves about evenly between all
|
||||
<script>
|
||||
var gitbook = gitbook || [];
|
||||
gitbook.push(function() {
|
||||
gitbook.page.hasChanged({"page":{"title":"Upgrading a Cluster","level":"4.6.1","depth":2,"next":{"title":"Slow Consumers","level":"4.6.2","depth":2,"path":"nats_admin/slow_consumers.md","ref":"nats_admin/slow_consumers.md","articles":[]},"previous":{"title":"Managing A NATS Server","level":"4.6","depth":1,"path":"nats_admin/README.md","ref":"nats_admin/README.md","articles":[{"title":"Upgrading a Cluster","level":"4.6.1","depth":2,"path":"nats_admin/upgrading_cluster.md","ref":"nats_admin/upgrading_cluster.md","articles":[]},{"title":"Slow Consumers","level":"4.6.2","depth":2,"path":"nats_admin/slow_consumers.md","ref":"nats_admin/slow_consumers.md","articles":[]},{"title":"Signals","level":"4.6.3","depth":2,"path":"nats_admin/signals.md","ref":"nats_admin/signals.md","articles":[]},{"title":"System Accounts","level":"4.6.4","depth":2,"path":"sys_accounts/README.md","ref":"sys_accounts/README.md","articles":[{"title":"Configuration","level":"4.6.4.1","depth":3,"path":"sys_accounts/sys_accounts.md","ref":"sys_accounts/sys_accounts.md","articles":[]}]}]},"dir":"ltr"},"config":{"plugins":["prism","-sharing","-highlight","include-html","toggle-chapters","anchors"],"styles":{"website":"styles/website.css","pdf":"styles/pdf.css","epub":"styles/epub.css","mobi":"styles/mobi.css","ebook":"styles/ebook.css","print":"styles/print.css"},"pluginsConfig":{"prism":{"lang":{"ascii":"markup","text":"markup"}},"include-html":{},"toggle-chapters":{},"anchors":{},"search":{},"lunr":{"maxIndexSize":1000000,"ignoreSpecialCharacters":false},"fontsettings":{"theme":"white","family":"sans","size":2},"theme-default":{"styles":{"website":"styles/website.css","pdf":"styles/pdf.css","epub":"styles/epub.css","mobi":"styles/mobi.css","ebook":"styles/ebook.css","print":"styles/print.css"},"showLevel":false}},"theme":"default","author":"The NATS Maintainers","pdf":{"pageNumbers":true,"fontSize":12,"fontFamily":"Arial","paperSize":"a4","chapterMark":"pagebreak","pageBreaksBefore":"/","margin":{"right":62,"left":62,"top":56,"bottom":56}},"structure":{"langs":"LANGS.md","readme":"README.md","glossary":"GLOSSARY.md","summary":"SUMMARY.md"},"variables":{},"title":"NATS","gitbook":"*","description":"Administrative, developer and conceptual documentation for the NATS messaging system."},"file":{"path":"nats_admin/upgrading_cluster.md","mtime":"2019-05-31T18:06:29.018Z","type":"markdown"},"gitbook":{"version":"3.2.3","time":"2019-06-04T21:01:15.070Z"},"basePath":"..","book":{"language":""}});
|
||||
gitbook.page.hasChanged({"page":{"title":"Upgrading a Cluster","level":"4.6.1","depth":2,"next":{"title":"Slow Consumers","level":"4.6.2","depth":2,"path":"nats_admin/slow_consumers.md","ref":"nats_admin/slow_consumers.md","articles":[]},"previous":{"title":"Managing A NATS Server","level":"4.6","depth":1,"path":"nats_admin/README.md","ref":"nats_admin/README.md","articles":[{"title":"Upgrading a Cluster","level":"4.6.1","depth":2,"path":"nats_admin/upgrading_cluster.md","ref":"nats_admin/upgrading_cluster.md","articles":[]},{"title":"Slow Consumers","level":"4.6.2","depth":2,"path":"nats_admin/slow_consumers.md","ref":"nats_admin/slow_consumers.md","articles":[]},{"title":"Signals","level":"4.6.3","depth":2,"path":"nats_admin/signals.md","ref":"nats_admin/signals.md","articles":[]},{"title":"System Accounts","level":"4.6.4","depth":2,"path":"sys_accounts/README.md","ref":"sys_accounts/README.md","articles":[{"title":"Configuration","level":"4.6.4.1","depth":3,"path":"sys_accounts/sys_accounts.md","ref":"sys_accounts/sys_accounts.md","articles":[]}]}]},"dir":"ltr"},"config":{"plugins":["prism","-sharing","-highlight","include-html","toggle-chapters","anchors"],"styles":{"website":"styles/website.css","pdf":"styles/pdf.css","epub":"styles/epub.css","mobi":"styles/mobi.css","ebook":"styles/ebook.css","print":"styles/print.css"},"pluginsConfig":{"prism":{"lang":{"ascii":"markup","text":"markup"}},"include-html":{},"toggle-chapters":{},"anchors":{},"search":{},"lunr":{"maxIndexSize":1000000,"ignoreSpecialCharacters":false},"fontsettings":{"theme":"white","family":"sans","size":2},"theme-default":{"styles":{"website":"styles/website.css","pdf":"styles/pdf.css","epub":"styles/epub.css","mobi":"styles/mobi.css","ebook":"styles/ebook.css","print":"styles/print.css"},"showLevel":false}},"theme":"default","author":"The NATS Maintainers","pdf":{"pageNumbers":true,"fontSize":12,"fontFamily":"Arial","paperSize":"a4","chapterMark":"pagebreak","pageBreaksBefore":"/","margin":{"right":62,"left":62,"top":56,"bottom":56}},"structure":{"langs":"LANGS.md","readme":"README.md","glossary":"GLOSSARY.md","summary":"SUMMARY.md"},"variables":{},"title":"NATS","gitbook":"*","description":"Administrative, developer and conceptual documentation for the NATS messaging system."},"file":{"path":"nats_admin/upgrading_cluster.md","mtime":"2019-06-05T22:32:07.014Z","type":"markdown"},"gitbook":{"version":"3.2.3","time":"2019-06-05T22:32:29.333Z"},"basePath":"..","book":{"language":""}});
|
||||
});
|
||||
</script>
|
||||
</div>
|
||||
|
||||
Reference in New Issue
Block a user