A replicated table is a special type of table in OceanBase Database. Such a table allows you to read the latest data modifications from any healthy replica. If you do not frequently write data and are more concerned about the read latency and load balancing, a replicated table is a good choice.
What are replicated tables?
The biggest difference between a replicated table and a normal table is whether they allow you to read the latest data from their replicas. The replicas of a normal table support weak-consistency reads, where earlier versions of data are read. The replicas of a replicated table support strong-consistency reads, where the latest version of data is read.
After you create a replicated table, a replica of the replicated table is created on each OBServer node in the current tenant. One of these replicas is elected as the leader to receive write requests, and other replicas serve as followers to receive only read requests.
All followers must report their status, including the replica replay progress (data synchronization progress), to the leader. Generally, the replica replay progress on a follower lags behind that on the leader. A follower is considered by the leader as healthy only if the data latency between the follower and the leader is within the specified threshold. A healthy follower can quickly synchronize data modifications from the leader. If the leader considers a follower as healthy within a period of time, it will grant a lease period to the follower. In other words, the leader believes that the follower can keep healthy and provide strong-consistency read services within the lease period. During this lease period, the leader confirms the replay progress on the follower before each replicated table transaction is committed. The leader returns the commit result of a transaction only after the follower successfully replays the modifications in the transaction. In this case, you can read the modifications made by the recently committed transaction from the healthy follower.
Why are replicated tables needed?
Amazon Aurora and many other databases use a single-writer multi-reader deployment mode where the writer node processes all writes and asynchronously synchronizes logical logs to reader nodes. In this mode, read load is distributed across multiple nodes, enhancing disaster recovery and ensuring lower latency for reads processed by nodes nearer to the client.
To meet this type of requirements, OceanBase Database combines weak-consistency reads with multiple replicas. One of these replicas serves as the leader, providing write services and real-time strong-consistency reads. Other replicas serve as followers, allowing you to read earlier committed data. Weak-consistency reads are a common choice in asynchronous data synchronization. The leader writes data without the need to pay attention to the data replay progress on followers. Followers provide consistent reads of data of an earlier version.
However, in scenarios with low write frequency, you may not care about the write latency. Instead, you are more concerned about the read latency and load balancing and want timely access to the latest data. The replicated table feature is designed to meet this need. It allows you to read the latest data from any healthy followers with a minimal compromise on the commit performance of transactions. A follower is considered healthy if it has a stable network connection with and a similar replay progress to the leader.
Differences in replicated tables between V3.x and V4.x
The replicated table feature is already supported in OceanBase Database V3.x. However, the database architecture is significantly modified in OceanBase Database V4.x. Therefore, to adapt to the new architecture of standalone log streams, OceanBase Database V4.x builds the partition-based readable version verification and log stream-based lease granting mechanisms to ensure the correctness in strong-consistency reads.
In addition, OceanBase Database V4.x improves the capability of switching the leader without terminating transactions. In OceanBase Database V4.x, replicated table transactions that are not committed when a leader switch is initiated by you or the load balancer can continue after the leader is switched, which is not supported in OceanBase Database V3.x. Compared with a replicated table of OceanBase Database V3.x, a replicated table of OceanBase Database V4.x has higher transaction write performance and more powerful disaster recovery capabilities. In addition, a replica crash has slighter impacts on read operations.