High Availability
High Availability (HA) is a Datomic Cloud feature ensuring the availability of Datomic for reads and writes in the event of node instance failures.
Datomic is designed to have no single point of failure anywhere in the database stack. In addition, Datomic's extensive caching means that even cold nodes will typically become warm without having to wait for high latency storage-of-record (S3).
Enabling HA
To enable HA, use the Production Topology.
The Production Topology is always highly-available, with no configuration required. The Production Topology mandates a minimum of 2 nodes, and allows more nodes for scaling purposes.
The Solo Topology is never highly available. The remainder of this document is about the Production Topology.
How HA Works
At any point in time a database has a preferred node for transactions. In normal operation all txes for a db will flow to/through that node. If for any reason (e.g. a temporary network partition) that node can't be reached, any node can and will handle txes. Consistency is ensured by CAS at the DynamoDB level. This situation increases contention for DynamoDB and decreases throughput, so if the condition persists (or in the case where the preferred node disappears) a different node will become preferred. This is all immediate, there are no transfer/recovery intervals etc. Thus it is not like the mastership transfer and failover of Datomic On-Prem (and many other dbs). But neither should it be confused with parallel multi-writer (a la Cassandra).
In the event of node failures, Datomic will remain available for transactions (albeit with reduced capacity) as long as even a single primary compute node stays healthy!
All nodes implement the entire Datomic API, so HA covers all Datomic functionality: query, transactions, and database administration.
Nodes are accessed via a Network Load Balancer (NLB), and their health is managed via Auto Scaling Group (ASG) health checks. If either the ASG or a node itself decide that a node is unhealthy, then the ASG will
- start a replacement node
- remove the ailing node from the NLB
- terminate the ailing node
Programs Should Be Ready for Transient Anomalies
When a node becomes unhealthy for any reason, client requests that are
routed from the NLB to that node may experience slow responses or
transient unavailable anomalies. (Client requests that reach one of
the other, healthy nodes during this time will experience normal
behavior and performance.)
Programs should be implemented to detect and handle transient anomalies in a manner appropriate to the program's needs.