This topic provides basic knowledge about replicas and introduces the replica types supported by OceanBase Database.
About replicas
To understand what a replica is, first take note of the following items:
Log: in this topic, log refers to the Clog related to transactions.
MemTable: data modified by a read or write operation and stored in the memory.
SSTable: the baseline data stored on the disk. When a transaction reads or modifies data, the data is temporarily stored in MemTable. In a major compaction, data in the MemTable is compacted with data in the SSTable to form a new SSTable.
The smallest unit of management in OceanBase Database is a partition. To ensure data security and service high availability, OceanBase Database stores the data in each partition in multiple copies. Each copy is called a replica of the partition. Each replica may include three major types of data: static data stored in the SSTable on the disk, incremental data stored in the MemTable in the memory, and logs that record transactions. OceanBase provides several types of replicas that contain different data categories to offer more choices in terms of data security, performance, elasticity, availability, and costs.
Replica types
OceanBase Database supports several replica types.
OceanBase Database supports the following types of replicas:
Full replica: the standard replica type that contains all the data categories and all the features, including MemTable, SSTable, and transaction logs. A full replica can quickly switch to become the leader to provide services.
Log-only replica: a replica that only contains logs. It does not have a MemTable or SSTable. It provides log services for external applications and participates in log voting. It can facilitate the recovery of other replicas, but it can not upgrade to be the leader to provide database services.
Readonly replica: contains full logs, MemTables, and SSTables. Its logging feature is special. It does not participate in elections as a Paxos group member, but tracks in real time the logs of Paxos group members and locally plays back the logs. When an application has low data reading consistency requirements, these replicas can provide the read-only services. They are not part of the Paxos group. Therefore they will not cause an increase in the transaction commit delay because the voting membership is not expanded.
The following table describes the features of these replicas:
| Feature | Full-featured replica | Log-only replica | Read-only replica |
|---|---|---|---|
| LOG | It has logs and participates in voting (STNC_CLOG). | It has logs and participates in voting (STNC_CLOG). | It has logs. It is only a listener instead of a member of the Paxos group (ASYNC_CLOG). |
| MemTable | Yes (WITH_MEMSTORE) | No (WITHOUT_MEMSTORE) | Yes (WITH_MEMSTORE) |
| SSTable | Yes (WITH_MEMSTORE) | No (WITHOUT_MEMSTORE) | Yes (WITH_MEMSTORE) |
| Data security | High | Low | Medium |
| Time to become leader | Fast | Not supported | Not supported |
| Resource cost | High | Low | High |
| Services | Provides data read and write services as the leader and non-consistent read services as a follower. | Not readable or writable | Non-consistent read service |
| Name (abbreviation) | FULL (F) | LOGON (L) | READONLY (R) |
| Replica type value | 0 | 5 | 16 |
