taigrr/nats.docs
1
0
Fork 0
mirror of https://github.com/taigrr/nats.docs synced 2025-01-18 04:03:23 -08:00
Code Issues Projects Releases Wiki Activity

initial syntax & grammar review

Browse Source
This commit is contained in:
Ginger Collison 2021-06-28 18:50:55 -05:00 committed by GitHub
parent 9011dc3619
commit ebc257e36f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 21 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
jetstream/leafnodes.md
View File

@ -1,12 +1,12 @@
# Jetstream in LeafNodes
# JetStream in LeafNodes
If you want to see a demonstration of the full range of this functionality, check out our [video](https://youtu.be/0MkS_S7lyHk)
One of the use cases for leaf nodes is to provide a local nats network even when the connection to a hub or the cloud is down.
To support such a disconnected use case with JetStream, independent JetStream islands are also supported and available through the same nats network.
One of the use cases for leafnodes is to provide a local NATS network even when the connection to a hub or the cloud is down.
To support such a disconnected use case with JetStream, independent JetStream islands are also supported and available through the same NATS network.
The general issue with multiple, independent JetStreams, accessible from the same client is that you need to be able to tell them apart.
As an example, consider a leaf node with a non clustered JetStream in each server.
As an example, consider a leafnode with a non-clustered JetStream in each server.
You connect to one of them, but which JetStream responds when you use the JetStream API `$JS.API.>` ?
To disambiguate that, the option `domain` was added to the JetStream configuration block.
@ -19,9 +19,9 @@ Needless to say, domain names need to be unique.
There are reasons to connect system accounts on either end of your leafnode connection.
You probably don't want to connect your cloud and edge device system accounts, but you might connect them when the only reason keeping you from using a super cluster are firewall rules.
The benefits are:
1) monitoring of all connected nats-servers.
2) nats-account-resolver working on the entire network.
3) extended JetStream cluster.
1) monitoring of all connected nats-servers
2) nats-account-resolver working on the entire network
3) extended JetStream cluster
When `domain` is set, JetStream-related traffic on the system account is suppressed.
This is what causes JetStream to not be extended.
@ -37,15 +37,15 @@ Furthermore, regular message flow is not restricted.
Thus, if the same subject is subscribed to by different streams in the same account in different domains, as long as the underlying leafnode was connected at the time, each stream will store the message.
This can be resolved by using the same account but use different subjects in each domain or use different accounts in each domain or [isolate accounts](https://youtu.be/0MkS_S7lyHk?t=1151) used in leaf nodes.
> *known issue*: if you have more than one JetStream enabled leaf node in a different cluster, the cluster you connect to also needs JetStream enabled and a domain set.
> *known issue*: when you intend to extend a central JetStream, by not supplying a domain name in leaf nodes, that central JetStream needs to be in clustered mode.
> *Known issue*: if you have more than one JetStream enabled leafnode in a different cluster, the cluster you connect to also needs JetStream enabled and a domain set.
> *Known issue*: when you intend to extend a central JetStream, by not supplying a domain name in leafnodes, that central JetStream needs to be in clustered mode.
## Configuration
Below is the config needed to connect two JetStream enabled servers via a leafnode connection.
In the example, the system accounts are connected for demonstration purposes (you do not have to do that).
### `accounts.conf` imported by both server
### `accounts.conf` Imported by Both Servers
```txt
accounts {
@ -428,7 +428,7 @@ accounts {
system_account: SYS
```
##### Copying via `source` an `mirror`
##### Copying via `source` and `mirror`
Once the servers have been restarted or reloaded, a `mirror` can be created as follows (same applies to `source`):
On import from a different account the renamed prefix `JS.acc@hub.API` is provided.