In OceanBase Database, the full usage of the MemStore memory in business tenants blocks data writes. In addition, if the memory of specific modules, such as the sys500 and sys tenants, is insufficient or leaked, errors will occur during data writes or queries. This topic describes how to promptly handle the memory insufficiency or leakage of a system module.
Emergency procedure
In most cases, the memory insufficiency or leakage of a system module in OceanBase Database occurs in a special scenario. For example, a bug exists. To resolve this issue, you can isolate or restart the faulty OBServer node.
Restart the faulty OBServer node
You can resolve the memory exceptions of a system module by restarting the faulty OBServer node. We recommend that you restart the specific OBServer node in the OceanBase Cloud Platform (OCP) console. For more information, see Restart an OBServer node.
Isolate the faulty OBServer node or replica
If the suspected memory insufficiency or leakage of a module cannot be resolved by restarting the faulty OBServer node, you can isolate the OBServer node.
Execute the
stop serverstatement. Here is the syntax:ALTER SYSTEM STOP SERVER 'ip:port' [,'ip:port'...] [ZONE='zone']Here is an example:
alter system stop server '10.0.0.0:2882' zone='z1;For more information about the O&M of zones, see Cluster management operations in the Cluster management chapter.
In addition to isolating the faulty OBServer node, you can isolate the entire replica where the exception occurs by executing the
stop zonestatement. Refer to the following syntax:ALTER SYSTEM STOP ZONE zone_name;Here is an example:
ALTER SYSTEM STOP ZONE z4;