Within Clojure, we call start-node
from within crux.api
, passing it a set of options for the node.
There are a number of different configuration options a Crux node can have, grouped into topologies.
Name | Transaction Log | Topology |
---|---|---|
Uses local event log |
| |
Uses Kafka |
| |
Uses JDBC event log |
|
Use a Kafka node when horizontal scalability is required or when you want the guarantees that Kafka offers in terms of resiliency, availability and retention of data.
Multiple Crux nodes participate in a cluster with Kafka as the primary store and as the central means of coordination.
The JDBC node is useful when you don’t want the overhead of maintaining a Kafka cluster. Read more about the motivations of this setup here.
The Standalone node is a single Crux instance which has everything it needs locally. This is good for experimenting with Crux and for small to medium sized deployments, where running a single instance is permissible.
Crux nodes implement the ICruxAPI
interface and are the starting point for making use of Crux.
Nodes also implement java.io.Closeable
and can therefore be lifecycle managed.
The following set of options are used by KV backend implementations, defined within crux.kv
:
Property | Description | Default Value |
---|---|---|
| Directory to store K/V files | data |
| Sync the KV store to disk after every write? | false |
Using a Crux standalone node is the best way to get started. Once you’ve started a standalone Crux instance as described below, you can then follow the getting started example.
Property | Description | Default Value |
---|---|---|
| Directory used to store the event-log and used for backup/restore, i.e. | n/a |
| Key/Value store to use for standalone event-log persistence | 'crux.kv.memdb/kv |
| Sync the event-log backend KV store to disk after every write? | true |
link:example$deps.edn[role=include]
Can you improve this documentation?Edit on GitHub
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close