ONgDB Enterprise Write Operations

ONgDB Enterprise Master Re-Election

Today we are covering ONgDB Enterprise Cluster Basics. ONgDB Enterprise enables a high availability cluster using the PAXOS protocol for cluster communication in early ONgDB releases and the RAFT protocol with the core-edge clustering model is now available in the current milestone releases. One very useful feature coming in the next release is the ability to read your own writes. Meaning you can require that the transaction with write you made to core is available on the edge server handling the read request before it returns your request.

So while that is coming in 3.x, what is the current landscape in 2.x?

When operating an ONgDB Enterprise cluster, there will always be one master instance and some number of slaves. ONgDB is capable of handling write requests on all instances, but that requires the slave to proxy the request to the master so it is best to separate reads and writes to ensure the master is the only ONgDB instance handling write requests.
Writes to the ONgDB master instance will be optimistically pushed to zero or more slaves as configured. This means the master will try pushing the successfully written transaction to the specified number of slaves prior to the write request completion. If the replication ends up failing for any reason, the transaction on the master will still remain successful although it will be different from the typical normal replication factor. The ONgDB slave instances will continue to pull for their updates at the configured interval so the writes will still eventually replicate and be available for read requests.

Whenever an ONgDB Enterprise graph database instance becomes unavailable (as a result of network outages or hardware issues), other ONgDB Enterprise graph database instances within the cluster will detect and leave a “temporarily failed” marking. A database instance that’s available (after being unavailable) will typically catch up with the cluster.

If the ONgDB Enterprise master instance happens to go down, the remaining slave instances must reach quorum on which one will be the next master. This is done by examining their transaction ids to see which has the highest and if there are multiple with the same then to break the tie the one with the higher server id is chosen. When the new master carries out its role switch, it will automatically broadcast its availability to other cluster members.

Typically, a new master is elected in a matter of seconds and write operations will continue flowing.

We’ve covered the ONgDB Enterprise cluster basics, and as I’m sure you now appreciate there are a lot of nuances involved in operating a high availability ONgDB Enterprise cluster consistently and reliably with all the configuration and tuning to maximize performance and reliability. GraphGrid Cloud provides proven ONgDB enterprise cloud hosting backed by experts in operating mission critical ONgDB Enterprise clusters to make sure your database remains available to your business. If you have questions about getting to production, schedule a demo and we’d love to help you succeed.