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.
How are replicated tables used?
To create a replicated table, you must add the DUPLICATE_SCOPE option to the CREATE TABLE statement. You can create a replicated table only in a user tenant but not in the sys tenant. The SQL syntax for creating a replicated table is as follows:
CREATE TABLE table_name column_definition DUPLICATE_SCOPE='none | cluster';
In the syntax, the DUPLICATE_SCOPE option specifies the attribute of the replicated table. Valid values include:
none: The table is a normal table. This is the default value.cluster: The table is a replicated table. The leader must copy transactions to all full-featured and read-only replicas in the current tenant.
When the first replicated table is created for a tenant, the system automatically creates a broadcast log stream for the tenant. Then, subsequent replicated tables of the tenant will all be created in the broadcast log stream. A broadcast log stream differs from a normal log stream in that the broadcast log stream will automatically deploy a replica on each OBServer node of the tenant to ensure that the replicated table can provide strong-consistency reads on any OBServer node in ideal conditions. You can execute the following SQL statement to view the broadcast log stream where the replicated tables of a tenant reside:
SELECT * FROM SYS.DBA_OB_LS WHERE flag LIKE "%DUPLICATE%";
A sample query result is as follows:
+-------+--------+--------------+---------------+-------------+---------------------+----------+---------------------+---------------------+-----------+
| LS_ID | STATUS | PRIMARY_ZONE | UNIT_GROUP_ID | LS_GROUP_ID | CREATE_SCN | DROP_SCN | SYNC_SCN | READABLE_SCN | FLAG |
+-------+--------+--------------+---------------+-------------+---------------------+----------+---------------------+---------------------+-----------+
| 1003 | NORMAL | z1;z2 | 0 | 0 | 1684982852976428261 | NULL | 1684983282912048623 | 1684983282912048623 | DUPLICATE |
+-------+--------+--------------+---------------+-------------+---------------------+----------+---------------------+---------------------+-----------+
1 rows in set
In this example, the log stream with the ID (LS_ID) of 1003 is a broadcast log stream. All replicated tables of the current tenant are created in this log stream. For more information about broadcast log streams, see Overview.
After a replicated table is created, you can perform insert and read/write operations on the replicated table as on a normal table. When you connect to OceanBase Database by using OceanBase Database Proxy (ODP), your read requests may be routed to any OBServer node. When you directly connect to OceanBase Database, if the local replica is readable, your read requests will be executed on the OBServer node that you directly connect to.
References
For more information about database connection methods, see Overview.
For more information about how to create a table, see Create a table.