OceanBase Database provides cluster-level and tenant-level parameters. An OBServer node serializes all parameters and saves them to the observer.conf.bin configuration file in the etc/ directory under the working directory. When the OBServer node starts under the working directory, it reads this configuration file.
Query parameters
Query parameters of a user tenant. The cluster- and tenant-level parameters of the queried user tenant are displayed in a virtual table. All cluster-level parameters are read-only. The tenant-level parameters can be modified based on their properties.
You can execute the
SHOW PARAMETERSstatement in a user tenant to view the tenant-level parameters of the tenant. The SQL syntax is as follows:SHOW PARAMETERS [SHOW_PARAM_OPTS]Query parameters of the sys tenant
You can execute the
SHOW PARAMETERSstatement in the sys tenant to view the cluster- and tenant-level parameters. You can also specify theTENANTkeyword in the statement to view the parameters of a specific tenant.If you do not specify the
TENANTkeyword, the cluster- and tenant-level parameters of the sys tenant are displayed. Both the cluster- and tenant-level parameters can be modified based on their properties.If you specify a user tenant, all parameters of the user tenant are displayed.
The SQL syntax is as follows:
SHOW PARAMETERS [SHOW_PARAM_OPTS] TENANT = tenant_name
The following table describes the details of the parameters.
| Column name | Description |
|---|---|
| svr_ip | The IP address of the server. |
| svr_port | The port number of the server. |
| name | The name of the parameter. |
| value | The value of the parameter. |
| type | The data type of the parameter. Valid values: NUMBER, STRING, and CAPACITY. |
| info | The description of the parameter. |
| section | The category of the parameter. |
| scope | The application scope of the parameter. Valid values: Tenant and Cluster. |
| source | The source of the current value. Valid values: Tenant, Cluster, CommandLine, ObAdmin, and File. |
| editable | Whether the parameter can be modified. |
| dynamic | Specifies whether the parameter takes effect immediately after it is modified. |
Modify parameters
Note
You can configure cluster-level parameters only when you have logged on by using the sys tenant account.
In MySQL mode, you can use the following SQL syntax to modify a parameter:
ALTER SYSTEM [SET] parameter_name = expression [PARAM_OPTS]
In the sys tenant, you can specify the TENANT option to modify the parameters of all tenants or a specific tenant. The SQL syntax is as follows:
Note
After the SQL statement is executed, the parameters of all specified tenants are modified.
ALTER SYSTEM [SET] parameter_name = expression [PARAM_OPTS] TENANT = all|all_user|all_meta|tenant_name
Note
all: In OceanBase Database V4.2.1 and later,tenant = allandtenant = all_userhave the same semantics and specify to take effect on all user tenants. Theallsyntax is to be deprecated. We recommend that you do not use this syntax.all_user: specifies to take effect on all user tenants.all_meta: specifies to take effect on all meta tenants.
In Oracle mode, you can use the following SQL syntax to modify a parameter:
ALTER SYSTEM SET parameter_name = expression [PARAM_OPTS]
Note
PARAM_OPTS specifies other conditions to take effect when you modify the parameter. For example, you can specify a zone or an OBServer node as a condition.
Store parameters
The OBServer node uses the configuration file for persistence, and maintains the internal tables at runtime.
Two types of physical tables are provided to store parameters. The cluster-level parameters are stored in the cluster-level parameter table, and the tenant-level parameters are stored in the tenant-level parameter table of each tenant. When you execute an SQL statement to modify a cluster-level parameter, the data is written to the cluster-level parameter table. Otherwise, the data is written to the tenant-level parameter table of the corresponding tenant. When cluster-level parameters are read, only the cluster-level parameter table is used. When tenant-level parameters are read, only the tenant-level parameter table is used.
Configuration file format
ObRecordHeader
[CLUSTER]
CLUSTER_PARAMETER_UPDATES
[TENANT_ID1]
TENANT_ID1_PARAMETER_UPDATES
[TENANT_ID2]
TENANT_ID2_PARAMETER_UPDATES
Update
An update refers to the process in which each OBServer node reads the incremental modifications to the persisted configurations from internal tables or the configuration file, and then loads the modifications into the memory as needed. When an observer process starts, it loads parameters from the configuration file. If you modify the parameters at runtime, the observer process loads the parameters from internal tables.
Load parameters from the configuration file
When an OBServer node starts, it first loads the parameters from the configuration file. This process is divided into the following three steps:
Calculate the default configuration based on the code and runtime environment.
Set the parameters one by one based on the configurations specified in the configuration file.
For tenant-level parameters, clone a copy of cluster-level parameters and overwrite values of these parameters by using tenant-level parameter values.
Set the parameters based on the values of the command-line options.
Load parameters from internal tables
The parameters are often updated when they are loaded from the internal tables. When a full set of parameters are available for normal operation, some parameters in the internal tables need to be modified.
When an ALTER SYSTEM SET statement is verified, the internal table of the corresponding parameters is updated. RootService then sends heartbeat notifications to the OBServer nodes and requests them to read the internal tables again and to update their parameters. When an OBServer node receives notifications from RootService, the background threads of the OBServer node start a task to update the parameters in the following process:
Read the parameter values from the internal table.
Clone a full copy of the current parameters.
Apply the parameter values from the internal table to the parameter copy.
Check whether the values of cloned parameters are valid.
Persist internal table values to the configuration files.
Replace the original parameters with the cloned parameters.
The processes to configure tenant- and cluster-level parameters are similar. The only difference is that the parameters are located in different internal tables.