Replication
OrientDB supports the Multi Master replication. This means that all the nodes in the cluster are Master and are able to read and write to the database. This allows to scale up horizontally without bottlenecks like most of any other RDBMS and NoSQL solution do.
Replication works only in the Distributed-Architecture and is subject to Distributed-Routing in the cluster.
In distributed configuration each Server Node maintains own Operation Log by writing all the non idempotent operations that modify the database. Log is written before to apply changes to the database.
Guarantees two databases are always consistent. It's more expensive than asynchronous because the First Server waits for the Second Server's answer before to send back the ACK to the client. After ACK the Client is secure the data is placed in multiple nodes at the same time.
Changes are propagated without waiting for the answer. Two databases could be not consistent in the range of few ms. For this reason it's called “Eventually Consistent”. It's much less expensive than synchronous replication.
Operations from 5a to 7a are executed in parallel with 5b avoiding the latency cost of synchronous mode.
Alignment is done automatic when a Server Node joins the cluster by comparing the last operation-id in the Server’s log files.
When the Server #3 joins the cluster, it sends an alignment request specifying last operation id in log. Each Server Node will send the newer operations in turn.
Server #1 acquires the distributed lock “align.DB-1” and start to send the delta. Once finished the lock is removed and the end alignment message is sent.
Server #1 releases the distributed lock “align.DB-1” and sends back the Alignment Response.
Server #3 sends a new alignment request against Server #2 with the new operation-id 92:999 but the Server #2 has no new operations, so returns 0 operations aligned.
All the Server Nodes are perfectly aligned to the last operation id.
Continue with: