domainwas added to the JetStream configuration block. When using it, follow these rules: Every server in a cluster and super cluster needs to have the same domain name. This means that domain names can only change between two servers if they are connected via a leaf node connection. As a result of this the JetStream API
$JS.API.>will also be available under a disambiguated name
$JS.<domain>.API.>. Needless to say, domain names need to be unique.
domainis set, JetStream-related traffic on the system account is suppressed. This is what causes JetStream not to be extended.
$JS.API.>is also suppressed. This causes clients to use the local JetStream that is available in the nats-servers they are connected to. To communicate with another JetStream, that JetStream's unique domain specific prefix
$JS.<domain>.APIneeds to be specified.
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.
accounts.confImported by Both Servers
nats-server -c hub.conf:
nats-server -c leaf.conf:
testsubscribing to subject
testin the JetStream domain, the program is connected to. As a result, this stream will be created in the domain hub which is the domain of the server listening on
js-domainargument. While connected to the same server as before, now the stream is created in
mirror. If you want to connect a leaf to the hub and get commands, even when the leaf node connection is offline, mirroring a stream located in the hub is the way to go.
source. If the streams located in each leaf are used for the same reasons, it is recommended to aggregate them in the hub for processing via
sourceas well as
mirrortake a copy of the messages. Once copied, accessing the data is independent of the leaf node connection being online. Copying this way also avoids having to run a dedicated program of your own. This is the recommended way to exchange persistent data across domains.
account.conffrom above needs to be modified and the server restarted or reloaded. This example exports the consumer and
FCAPI as well as a delivery subject which is used by the internal push consumer created by
ACKAPI are exported as well.
Known issue: Currently, across accounts, push consumer are not supported.
$JS.hub.APIis renamed to
[email protected]. This is to, once more, disambiguate which JetStream a client in the importing account might want to interact with. When using domains, the general recommendation is to export the domain specific API
$JS.<domain>.APIas this allows you to pin the export to a particular domain.
$JS.hub.API.CONSUMER.>or the entire API in a domain
$JS.hub.API.>or the entire API
$JS.API.>wherever the importing client connects.
mirrorcan be created as follows (same applies to
source): On import from a different account the renamed prefix
[email protected]is provided. In addition, the delivery subject name is extended to also include the importing domain and stream. This makes it unique to that particular import. If every delivery prefix follows the pattern
<static type>.<exporting account>.<exporting domain>.<importing account>.<importing domain>.<importing domain>.<importing stream name>overlaps caused by multiple imports are avoided.
ACCgot copied to the new stream in the account
accounts.confalso includes a separate import for an existing pull consumer. Let's create a consumer by the name
durin the stream
aggregate-test-leafin the account
testfrom where it is copied into
nats.APIPrefix("[email protected]")when obtaining the JetStream object. Because the API access is limited, the subscribe call provides the option
nats.Bind("aggregate-test-leaf", "dur")which prevents calls to infer the stream and durable name.
ACKsubject. However, instead of exporting/importing the
NEXTsubject, the delivery subject shown for source/mirror needs to be used.