Configuration files

OceanBase Database provides cluster- and tenant-level parameters. An OBServer serializes all parameters and saves them to the observer.conf.bin configuration file in the etc/ directory under the working directory. When the OBServer 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 PARAMETERS statement in a user tenant to view the tenant-level parameters of the tenant. SQL syntax:

  SHOW PARAMETERS [SHOW_PARAM_OPTS]
  

• Query parameters of the SYS tenant

  You can execute the SHOW PARAMETERS statement in the SYS tenant to view the cluster- and tenant-level parameters. You can also specify the TENANT keyword in the statement to view the parameters of a specific tenant.

  • If you do not specify the TENANT keyword, 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.

  SQL syntax:

  SHOW PARAMETERS [SHOW_PARAM_OPTS] TENANT = tenant_name
  

The following table shows the details of the parameters:

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. SQL syntax:

ALTER SYSTEM [SET] parameter_name = expression [PARAM_OPTS] TENANT = all|tenant_name

Note

After the SQL statement is executed, the parameters of all specified tenants are modified.

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 when you modify the parameter. For example, you can specify a zone or an OBServer. For more information, see SQL Reference (MySQL Mode) and SQL Reference (Oracle Mode).

Store parameters

The OBServer 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 parameters

An update refers to the process in which each OBServer reads the incremental modifications to the persisted configurations from internal tables or the configuration file observer.config.bin in the etc/ directory, and then loads the modifications into the memory as needed. When a 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 starts, it first loads the parameters from the configuration file. This process is divided into the following three steps:

1. Calculate the default configuration based on the code and runtime environment.

2. Set the parameters one by one based on the configurations specified in the configuration file.

3. For tenant-level parameters, clone a copy of cluster-level parameters and overwrite values of these parameters by using tenant-level parameter values.

4. 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 a ALTER SYSTEM SET statement is verified, the internal table of the corresponding parameters is updated. The RootServer then sends heartbeat notifications to the OBServers and requests them to read the internal tables again and to update their parameters. When an OBServer receives notifications from the RootServer, the background threads of the OBServer start a task to update the parameters in the following process:

1. Read the parameter values from the internal table.

2. Clone a full copy of the current parameters.

3. Apply the parameter values from the internal table to the parameter copy.

4. Check whether the values of cloned parameters are valid.

5. Persist internal table values to the configuration files.

6. 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.