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

GitBook: [master] 61 pages modified

Browse Source
This commit is contained in:
Ginger Collison
2020-04-10 14:41:07 +00:00
committed by gitbook-bot
parent ed6c1ba06d
commit de933e912d
61 changed files with 348 additions and 378 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
nats-streaming-server/configuring/cfgfile.md
View File

@@ -85,7 +85,7 @@ Note that the Streaming Server uses a connection to a NATS Server, and so the NA
| client\_key | Client certificate for the streaming server | File path | `client_key: "/path/to/client/key_file"` |
| client\_ca | Client certificate CA for the streaming server | File path | `client_ca: "/path/to/client/ca_file"` |
| server\_name | Expected hostname returned in the NATS Server certificate | String | `server_name: "theserverhostname"` |
| insecure | Skips the NATS server's certificate chain and host name verification. Should not be used in production | `true` or `false` (default `false`) | `insecure: true` |
| insecure | Skips the NATS server's certificate chain and host name verification. Should not be used in production | `true` or `false` \(default `false`\) | `insecure: true` |
## Store Limits Configuration

4
nats-streaming-server/configuring/persistence/README.md
View File

@@ -1,7 +1,7 @@
# Persistence
By default, the NATS Streaming Server stores its state in memory, which means that if the streaming server is stopped, all state is lost. On server restart, since no connection information is recovered, running applications will stop receiving messages and new published messages will be rejected with an `invalid publish request` error. Client libraries that support and set the `Connection Lost` handler \(refer to [this](https://github.com/nats-io/stan.go#connection-status) for more information\) will be notified that the connection is lost with the error `client has been replaced or is no longer registered`.<br>
Still, this level of persistence allows applications to stop and later resume the stream of messages, and protect against applications disconnect \(network or applications crash\).
By default, the NATS Streaming Server stores its state in memory, which means that if the streaming server is stopped, all state is lost. On server restart, since no connection information is recovered, running applications will stop receiving messages and new published messages will be rejected with an `invalid publish request` error. Client libraries that support and set the `Connection Lost` handler \(refer to [this](https://github.com/nats-io/stan.go#connection-status) for more information\) will be notified that the connection is lost with the error `client has been replaced or is no longer registered`.
Still, this level of persistence allows applications to stop and later resume the stream of messages, and protect against applications disconnect \(network or applications crash\).
* [File Store](file_store.md)
* [SQL Store ](sql_store.md)

8
nats-streaming-server/configuring/storelimits.md
View File

@@ -139,8 +139,8 @@ On startup, the server will apply the store limits, which means that this channe
We strongly recommend not raising the limit back to the higher limit if messages have been removed in the previous step because those removed messages may or may not become available again depending on the store implementation or if running in clustering mode or not.
## Clustering
When running `--clustered`, messages are kept in a RAFT consensus log file (under `--cluster_log_path`) in addition to the configured store.
This directory will grow as more messages keep coming within the 2-4 minute intervals of RAFT Snapshotting.
After snapshotting the RAFT log will not shrink, but the space for more messages will be allocated internally.
As a result - in addition to `max_bytes` multiplied by `max_channels` - disk space needs to be provisioned for RAFT Log, which can grow up to the size of payloads that channels could receive per minute * 4.
When running `--clustered`, messages are kept in a RAFT consensus log file \(under `--cluster_log_path`\) in addition to the configured store.
This directory will grow as more messages keep coming within the 2-4 minute intervals of RAFT Snapshotting. After snapshotting the RAFT log will not shrink, but the space for more messages will be allocated internally. As a result - in addition to `max_bytes` multiplied by `max_channels` - disk space needs to be provisioned for RAFT Log, which can grow up to the size of payloads that channels could receive per minute \* 4.