OceanBase clusters are usually managed by O&M engineers. OceanBase clusters aggregate resources from multiple servers into a large resource pool and allocate the resources to tenants (also known as instances). OceanBase isolates resources of different tenants. It also isolates data access among tenants.
Concepts
Multi-replica architecture
OceanBase typically uses a three-replica cluster architecture, or five-replica architecture on a few occasions. In the three-replica architecture, the number of nodes in an OceanBase cluster is a multiple of three. The nodes in a cluster are divided into three zones. Each zone has an equal number of one or more nodes. The data in each tenant is also distributed across the three zones, but not necessarily across all nodes in a zone. This depends on the resource pool attributes of a tenant, which are set by O&M engineers.
High availability
By default, in a three-replica OceanBase cluster, each piece of data has three replicas, which are distributed across three zones. Partitions are the most fine-grained representation of the data. A partition is a subset of a table. In OceanBase clusters, the high availability and failover are implemented at the partition level. Therefore, when an OceanBase node fails, some data access sessions of an application are disconnected and then automatically restored. When the faulty node has many partitions, the restoration time may vary slightly for different data.
Parameter settings
OceanBase enables you to use parameters to optimize the functionality and performance of clusters and tenants. Cluster parameters are set in the sys tenant and applied across the cluster, including all its tenants. OceanBase also enables you to set variables for tenants, which apply to the current tenant. For more information about the general OceanBase parameters and variables, see Appendix "General OceanBase parameters and variables".
Data write in OceanBase Database
When you make the first change to a table in OceanBase Database, OceanBase Database fetches the block where the record is stored into an ROM area and records the change in another memory area. The former is called baseline data (stored in an SSTable) and the latter is called incremental data (stored in a MemTable). The memory for the MemTable is called incremental memory. Whether you insert, update, or delete data, OceanBase does not modify the SSTable. Instead, it appends the incremental data to the existing data. This design allows OceanBase writes to involve very few I/O operations, which ensures high performance. The incremental data is not flushed into the disk until the usage of the incremental memory exceeds the specified threshold and triggers a minor freeze. At this time, a new MemTable is generated for subsequent writes. The existing MemTable is directly dumped to the disk or compacted with the SSTable on the disk.
Note
By default, OceanBase performs major compaction on incremental and baseline data at 2:00 each day. Given the characteristics of memory write operations in OceanBase, developers O&M engineers need to pay attention to the speed of memory consumption by their application. If the writes to the incremental memory are much faster than the speed at which minor or major compactions release the memory, the incremental memory may be used up, causing an error in subsequent writes. In this case, you need to limit the writing speed of the application or database or increase the instance memory of the database.