Compared to OceanBase Database V3.x, the biggest change in OceanBase Database V4.x is that multiple data partitions are associated with a log stream. This results in a significant reduction in the use of resources such as memory, CPU, and bandwidth. No independent role information is provided for data partitions. Instead, the roles of data partitions are determined by the roles of log streams to which the data partitions belong. The roles of log streams are determined based on the election protocol. Therefore, leader switchovers are performed based on log streams in OceanBase Database V4.x.
OceanBase Database provides the multitenancy feature. The resources of a tenant are isolated from those of other OceanBase tenants, and each tenant has its own log stream. To troubleshoot a leader switchover exception in OceanBase Database V4.x, you must first confirm the IDs of the tenant and its log stream.
The leader election of log streams depends on the following three modules in sequence:
Election module
Based on the exclusive election algorithm of OceanBase Database, the election module produces the leader and ensures its uniqueness. This leader is referred to as the election leader.
Clog module
Based on the election leader, the clog module first executes the reconfirm process to ensure that the clog leader has full logs. Then it executes the clog takeover process, which asynchronously notifies the RoleChangeService module. After that, the clog leader becomes valid.
RoleChangeService module
When it detects that the clog leader needs to execute the takeover process, the RoleChangeService module is responsible for executing the specific takeover logic. The modules that need to detect leader switchovers are connected to the RoleChangeService module to detect the switchover operation and execute their respective switchover logic.