Highly available database setup guidelines
This document serves to capture general database guidelines to consider when setting up a highly available database for use with the JPA notary.
The CAP theorem states that no distributed system can simultaneously guarantee consistency, availability and partition tolerance at the same time. Given that network failures are unavoidable, some form of partition tolerance must be present in any distributed database setup. Therefore, a notary’s distributed database can either be consistent or highly available. Consistency is preferred to availability due to the critical nature of the data stored. A clustered setup will increase availability, depending on the clustering technology used, but the more important requirement should always be consistency.
Due to the importance of consistency for the data that a notary stores, synchronous replication is required of any database used with a notary. CockroachDB only supports synchronous replication, one of the reasons it was chosen for the JPA notary.
Asynchronous replication could result in data loss if data is written to one node which then goes down. For this reason, it should be avoided in any database used with a notary.
It is important to note that latency between database cluster members negatively affects the performance of the database cluster as a whole. One possible cause of increased latency would be having one or more members of the cluster were located in geographically separate data centres.
This is ideal from a disaster recovery perspective and is supported by Corda. While performance is negatively impacted, the prevention of data loss more than makes up for the loss. However, it may be worth bearing this in mind when performance tuning the notary.
Was this page helpful?
Thanks for your feedback!
Chat with us
Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.
Propose documentation improvements directly
Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.
We're sorry this page wasn't helpful. Let us know how we can make it better!
Chat with us
Create an issue
Create a new GitHub issue in this repository - submit technical feedback, draw attention to a potential documentation bug, or share ideas for improvement and general feedback.