OceanBase Glossary
Concise definitions for OceanBase architecture and operations. Each entry links to official documentation and related OceanDB Pro guides where available.
- OceanBase Database
-
A distributed relational database that stores data in log streams replicated with Paxos. It supports MySQL and Oracle compatibility modes.
Why it matters: Understanding the product boundary helps you choose compatibility mode, sizing, and migration tooling.
- Tenant
-
An isolated database instance inside an OceanBase cluster. Each tenant has its own resource units, compatibility mode, and data namespace.
Why it matters: Multi-tenant clusters rely on correct tenant boundaries for isolation, quotas, and blast-radius control.
- Zone
-
A failure domain, typically mapped to a data center or availability zone, that hosts observer replicas for Paxos quorums.
Why it matters: Zone layout determines whether the cluster survives single-site or single-region failures.
- Region
-
A geographic grouping of zones used for disaster recovery and multi-region quorum design.
Why it matters: Cross-region replication affects latency, RPO, and failover behavior.
- Unit
-
A resource slice (CPU, memory, disk) allocated to a tenant on a specific observer node.
Why it matters: Unit placement drives performance locality and failure isolation per tenant.
- Unit config
-
A template defining CPU, memory, and storage limits for units assigned to a resource pool.
Why it matters: Incorrect unit configs cause OOM, throttling, or wasted hardware.
- Resource pool
-
A pool of units with the same unit config distributed across zones for a tenant.
Why it matters: Pools define how tenant capacity scales and spreads across the cluster.
- Locality
-
Rules that specify how many replicas of a log stream or partition exist in each zone.
Why it matters: Locality drives quorum math and read locality for HTAP workloads.
- Tablet
-
A partition of user data mapped to a log stream. Tablets are the unit of data distribution inside a tenant.
Why it matters: Hot tablets affect single log stream leaders and migration parallelism.
- Log stream
-
An independently replicated shard that holds a portion of tablet data and its own Paxos log.
Why it matters: Leader election, replication lag, and failover all operate per log stream.
- Leader
-
The replica in a log stream that accepts writes and coordinates Paxos commits for that stream.
Why it matters: Leader loss triggers election; misconfigured quorums can block writes.
- Follower
-
A non-leader replica that receives and replays log entries from the leader for a log stream.
Why it matters: Follower lag and role transitions indicate replication or network problems.
- Paxos
-
The consensus protocol OceanBase uses to replicate log streams and elect leaders among replicas.
Why it matters: Quorum size and zone layout determine fault tolerance and failover behavior.
- MemStore
-
In-memory storage for recent writes in an observer before data is flushed to stable storage.
Why it matters: MemStore pressure causes write stalls and triggers minor freezes.
- Minor freeze
-
A process that flushes memstore data to disk as a minor SSTable when memory thresholds are reached.
Why it matters: Frequent minor freezes can signal memstore limits or hot write patterns.
- Minor compaction
-
Compaction that merges minor SSTables to reduce read amplification before major compaction.
Why it matters: Compaction backlog increases read latency and disk usage.
- Major compaction
-
Full compaction that rewrites SSTables into a stable baseline, often scheduled during maintenance windows.
Why it matters: Major compaction affects I/O and should be planned for large tenants.
- OCP (OceanBase Cloud Platform)
-
Management software for deploying, monitoring, and operating OceanBase clusters.
Why it matters: Many production teams use OCP for failover visibility, backups, and tenant operations.
- OBD (OceanBase Deployer)
-
Command-line tooling to deploy and bootstrap OceanBase clusters, often used before or alongside OCP.
Why it matters: Bootstrap and topology mistakes at deploy time are expensive to fix later.
- OMS (OceanBase Migration Service)
-
Data migration and synchronization service for moving data from supported sources into OceanBase.
Why it matters: OMS capabilities define feasible migration paths and cutover strategies.
OceanBase Migration Service documentation · OceanDB Pro guide
- ODP (OceanBase Database Proxy)
-
Connection proxy (OBProxy) that routes client SQL to the correct observer and log stream leader.
Why it matters: Applications should typically connect through the proxy for leader failover tolerance.
- MySQL mode
-
OceanBase compatibility mode that accepts a large subset of MySQL SQL and wire protocol behavior.
Why it matters: Migration from MySQL depends on dialect coverage and driver settings in this mode.
- Oracle mode
-
OceanBase compatibility mode targeting a subset of Oracle SQL and PL/SQL features.
Why it matters: Oracle migrations require explicit assessment of unsupported constructs.
- HTAP
-
Hybrid transactional and analytical processing: running OLTP and analytical queries on shared or coordinated storage.
Why it matters: HTAP shapes resource isolation, column store use, and workload scheduling.
- RootService
-
Cluster metadata service that coordinates tenant creation, partition balance, and global cluster state.
Why it matters: RootService health is required for topology changes and some recovery operations.