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
The election module determines the election leader and ensures the uniqueness of the leader based on the exclusive election algorithm of OceanBase Database.
Clog module
The clog module first executes the reconfirmation process based on the election leader to ensure that the clog leader has full clogs. Then, the clog leader asynchronously notifies the RoleChangeService module of the clogs. After that, the clog leader becomes valid.
RoleChangeService module
The RoleChangeService module executes the specific logic after it detects that the clog leader needs to execute asynchronous notification of clogs. The modules that need to detect leader switchovers will be connected to the RoleChangeService module to detect the switchover operation and execute their respective switchover logic.