obd has multiple levels of commands. You can use the -h/--help option at each level to view the help information of subcommands. Similarly, when an error occurs during the execution of subcommands at each level, you can use the -v/--verbose option to view the detailed execution process of the command.
The smallest unit for operating obd cluster commands is a deployment configuration. A deployment configuration is a yaml file that contains all the configuration information for the deployment, including server login information, component information, component configuration information, and component server lists.
Before you use obd to start a cluster, you need to register the deployment configuration of the cluster in obd. You can use the obd cluster edit-config command to create an empty deployment configuration, or use the obd cluster deploy -c config command to import a deployment configuration.
obd cluster autodeploy
You can specify a simple configuration file to deploy a cluster with the maximum specifications based on the resources of the target server.
Note
After you modify the configuration file, if you use this command to deploy the cluster, the configuration generated by obd based on the server resources will overwrite the modified configuration. In other words, you can deploy the cluster only by using the configuration generated by obd.
obd cluster autodeploy <deploy name> -c <yaml path> [-f] [-U] [-A] [-s]
# example
obd cluster autodeploy test -c all-components.yaml
The deploy name parameter specifies the deployment name, which can be considered an alias for the configuration file.
The following table describes the options.
Option |
Required |
Data type |
Default value |
Description |
|---|---|---|---|---|
| -c/--config | Yes | string | N/A | Specifies the path of the required YAML file. obd uses the specified YAML file to deploy the cluster and registers the deployment configuration in obd. If deploy name is specified, obd checks the status of the deployment. If the old configuration has not been deployed, obd overwrites it. Otherwise, obd returns an error. |
| -f/--force | No | bool | false | This option does not require a value. The configuration in the command takes effect. When you configure this option, obd clears the working directory (home_path). If the working directory is not empty and the component requires it to be empty, an error is returned when you do not use this option. |
| -C/--clean | No | bool | false | This option does not require a value. The configuration in the command takes effect. When you configure this option, obd checks whether the working directory (home_path) belongs to the current user. If it does, obd clears the working directory. |
| -U/--ulp/ --unuselibrepo | No | bool | false | This option does not require a value. The configuration in the command takes effect. If you do not configure this option, obd searches for related library images and installs them when it detects missing dependencies. When you use this option, obd adds unuse_lib_repository: true to the corresponding configuration file. You can also use unuse_lib_repository: true in the configuration file to enable this option. |
| -A/--act/--auto-create-tenant | No | bool | false | This option does not require a value. The configuration in the command takes effect. When you configure this option, obd creates a tenant named test using all available cluster resources during the bootstrap phase. When you use this option, obd adds auto_create_tenant: true to the corresponding configuration file. You can also use auto_create_tenant: true in the configuration file to enable this option. |
| -s/--strict-check | No | bool | false | Some components perform checks before they start. If the checks fail, a warning is returned, but the process does not stop. When you use this option, obd exits directly after the checks fail. We recommend that you enable this option to avoid startup failures caused by insufficient resources. |
| --gcc/--generate-consistent-config | No | bool | false | When you deploy the cluster on multiple servers, you can use this option to generate consistent configurations. For example, if the memory of server A is 10 GB and that of server B is 20 GB, obd automatically configures them based on the minimum value (10 GB) after you enable this option. |
obd cluster edit-config
Modifies a deployment configuration. If the deployment configuration does not exist, it creates one.
obd cluster edit-config <deploy name>
# example
obd cluster edit-config test
The deploy name parameter specifies the deployment name, which can be considered an alias for the configuration file.
obd cluster deploy
You can run this command to deploy a cluster based on the configuration.
This command will find suitable images based on the component information in the deployment configuration file and install them to the local repository. This process is called local installation. Then, it will distribute the components with suitable versions from the local repository to the target servers. This process is called remote installation.
During both local and remote installation, the command will check whether the required dependencies for component operation are present on the servers. You can directly deploy the cluster using the registered deploy name in obd, or provide the yaml configuration information.
obd cluster deploy <deploy name> [-c <yaml path>] [-f] [-U] [-A]
# example
obd cluster deploy test -c all-components-min.yaml
The deploy name parameter specifies the name of the deployment, which can be considered an alias for the configuration file.
The following table describes the options.
Option |
Required |
Data type |
Default value |
Description |
|---|---|---|---|---|
| -c/--config | No | string | N/A | Specifies the path of the required YAML file. obd uses the specified YAML file to deploy the cluster and registers the deployment configuration in obd. If deploy name exists, the configuration will be overwritten.If you do not use this option, obd will look up the registered configuration information based on deploy name. |
| -f/--force | No | bool | false | This option does not require a value. The configuration in the command will take effect. When you configure this option, obd will forcibly clear the working directory. If the component requires an empty working directory and you do not use this option, an error will be returned if the working directory is not empty. |
| -C/--clean | No | bool | false | This option does not require a value. The configuration in the command will take effect. When you configure this option, obd will check whether the working directory (home_path) belongs to the current user. If it does, obd will clear the working directory. |
| -U/--ulp/ --unuselibrepo | No | bool | false | This option does not require a value. The configuration in the command will take effect. When you use this option, obd will not automatically handle dependencies. If you do not configure this option, obd will search for related libs images and install them when it detects missing dependencies. When you use this option, unuse_lib_repository: true will be added to the corresponding configuration file. You can also use unuse_lib_repository: true in the configuration file to enable this option. |
| -A/--act/--auto-create-tenant | No | bool | false | This option does not require a value. The configuration in the command will take effect. When you configure this option, obd will create a tenant named test using all available resources of the cluster during the bootstrap phase.When you use this option, auto_create_tenant: true will be added to the corresponding configuration file. You can also use auto_create_tenant: true in the configuration file to enable this option. |
| -i/--interactive | No | bool | false | This option does not require a value. The configuration in the command will take effect. When you configure this option, the interactive deployment process will be initiated. For more information, see Interactively deploy an OceanBase cluster.
NoteThis option was introduced in obd V3.4.0. |
obd cluster start
Starts a deployed cluster and prints the cluster status upon successful startup.
obd cluster start <deploy name> [flags]
# example
obd cluster start test -S
The deploy name parameter specifies the name of the deployment, which can be considered an alias for the configuration file.
The following table describes the options.
Option |
Required |
Data type |
Default value |
Description |
|---|---|---|---|---|
| -s/--servers | No | string | Empty | The list of servers, followed by the name value in the servers section of the YAML file. If the name value is not specified for servers, the ip value will be used instead. The servers to be started are separated by commas (,). |
| -c/--components | No | string | Empty | The list of components, separated by commas (,). The components to be started are specified here. If not all components are started, the configuration will not be in the running state. |
| --wp/--with-parameter | No | bool | false | Starts the cluster with parameters. This option does not require a value. The configuration in the command will take effect.
NoteWhen a node is started for the first time, it will be treated as a parameter-based start regardless of whether this option is configured. |
| -S/--strict-check | No | bool | false | Some components will perform relevant checks before startup. If the checks fail, obd will issue a warning but will not forcibly stop the process. When you use this option, the process will exit immediately upon check failure. We recommend enabling this option to avoid startup failures caused by insufficient resources. |
| --sn/--service-names | No | string | Empty | The list of services to be started by PowerRAG, separated by commas (,). |
obd cluster list
Displays the status of all clusters (deploy names) registered in the current obd.
obd cluster list
The status of a cluster registered in obd can be one of the following:
configured: The cluster is configured. This indicates that the cluster's configuration file is included in obd, but the cluster has not been deployed yet. You can execute the
obd cluster deploycommand to deploy the cluster.deployed: The cluster is deployed. This indicates that the cluster has been deployed but has not been started yet. You can execute the
obd cluster startcommand to start the cluster.running: The cluster is running.
stopped: The cluster is stopped. This indicates that some components of the cluster are stopped. You can execute the
obd cluster startcommand to start the cluster.upgrading: The cluster is being upgraded. This indicates that some components of the cluster are being upgraded.
destroyed: The cluster is destroyed.
obd cluster display
Displays the status of a specified cluster.
obd cluster display <deploy name>
# example
obd cluster display test
The deploy name parameter specifies the name of the cluster, which can be considered an alias for the configuration file. Starting from V3.2.0, if an encryption key is set in obd, the cluster information output by the display command will be in an encrypted state. If you want to output the plaintext password, you can add the --epk/--encryption-passkey parameter to the command to specify the key for verification.
obd cluster reload
Reloads a running cluster. After you modify the configuration information of a running cluster using edit-config, you can execute the reload command to apply the changes.
Notice
Not all configuration items can be applied by using the reload command. Some configuration items require restarting or redeploying the cluster to take effect. Please operate based on the information returned after executing edit-config.
obd cluster reload <deploy name>
# example
obd cluster reload test
The deploy name parameter specifies the name of the cluster, which can be considered an alias for the configuration file.
obd cluster restart
Restarts a running cluster. By default, the restart is performed without parameters. After you modify the configuration information of a running cluster using edit-config, you can execute the obd cluster restart <deploy name> --wp command to apply the changes.
Notice
Not all configuration items can be applied by using the restart command. Some configuration items require redeploying the cluster to take effect. Please operate based on the information returned after executing edit-config.
obd cluster restart <deploy name>
# example
obd cluster restart test -c obproxy-ce --wp
The deploy name parameter specifies the name of the cluster, which can be considered an alias for the configuration file.
The following table describes the options.
Option |
Required |
Data Type |
Default Value |
Description |
|---|---|---|---|---|
| -s/--servers | No | string | Empty string | The list of servers. The value of the name parameter in the servers section of the YAML file is used. If the name parameter is not specified, the ip parameter is used. Separate the values with commas (,). This option specifies the servers to restart. |
| -c/--components | No | string | Empty string | The list of components. Separate the values with commas (,). This option specifies the components to restart. If not all components are started, the cluster will not be in the running state. |
| --wp/--with-parameter | No | bool | false | Specifies whether to perform a parameter-based restart. This option specifies whether to apply the changes to the configuration items that take effect after the restart. |
obd cluster redeploy
Redeploys a running cluster. After you modify the configuration information of a running cluster using edit-config, you can execute the redeploy command to apply the changes.
Notice
This command will destroy the cluster and redeploy it. Data in the cluster will be lost. Please back up the data before execution.
obd cluster redeploy <deploy name> [-f]
# example
obd cluster redeploy test -f
The deploy name parameter specifies the name of the cluster, which can be considered an alias for the configuration file.
Option |
Required |
Data Type |
Default Value |
Description |
|---|---|---|---|---|
| -f/--force-kill | No | bool | false | Before obd executes the destroy command, it will check whether any processes are running. These running processes may be left over from a failed start operation or may belong to another cluster due to overlapping configurations. Regardless of the cause, if any processes are still running in the working directory, obd will stop executing the obd cluster redeploy command. If the -f option is specified, obd will forcibly stop any running processes and proceed with the obd cluster redeploy command. |
| --confirm | No | bool | false | Specifies whether to confirm the restart of the cluster. If this option is specified, the confirmation process will be skipped, and the cluster will be restarted directly. |
| --igs/--ignore-standby | No | string | Empty string | If a standby tenant exists in another cluster for the tenant in the current cluster, the obd cluster redeploy command will be forcibly executed. After the cluster is destroyed, the standby tenant will no longer be usable. |
obd cluster stop
Stops a running cluster.
obd cluster stop <deploy name>
# example
obd cluster stop test -s server1
The deploy name parameter specifies the deployment name, which can be considered an alias for the configuration file.
The following table describes the options.
Option |
Required? |
Data Type |
Default Value |
Description |
|---|---|---|---|---|
| -s/--servers | No | string | Empty string | The list of servers, followed by the name value in the servers section of the YAML file. If the name value is not specified, the ip value is used. Separate the values with commas (,). This option specifies the servers to stop. |
| -c/--components | No | string | Empty string | The list of components, separated by commas (,). This option specifies the components to stop. If not all components are stopped, the configuration will not be marked as stopped. |
obd cluster destroy
Destroys a deployed cluster. If the cluster is running, this command will first attempt to execute the stop command, and then proceed with the destroy command if successful.
obd cluster destroy <deploy name> [-f]
# example
obd cluster destroy test -f
The deploy name parameter specifies the deployment name, which can be considered an alias for the configuration file.
Option |
Required? |
Data Type |
Default Value |
Description |
|---|---|---|---|---|
| -f/--force-kill | No | bool | false | Before executing the destroy command, obd checks if any processes are still running. These processes could be leftover from a failed start command or belong to another cluster. If any processes are still running in the working directory, obd will stop executing the obd cluster destroy command. When the -f option is enabled, obd will forcibly stop any running processes and proceed with the obd cluster destroy command. |
| --confirm | No | bool | false | This option does not require a value. If specified, it skips the confirmation prompt during command execution. If not specified, executing the destroy command will prompt for confirmation before proceeding. |
| --igs/--ignore-standby | No | bool | false | If a standby tenant exists in another cluster, the obd cluster destroy command will be forcibly executed. After the cluster is destroyed, the standby tenant will no longer be usable. |
obd cluster prune-config
Deletes the configuration files of a destroyed or configured cluster. When a cluster is in the destroyed or configured state (you can view the cluster status using the obd cluster list command), this command can be used to completely remove the specified cluster's configuration files to free up storage space.
Notice
This command can only delete configuration files of clusters in the
destroyedorconfiguredstate. If the cluster is not in one of these states, the command will fail and exit.Once the configuration file is deleted, it cannot be used to deploy the cluster again. That is, when executing the deployment command, you must specify the path to a new configuration file. This action is irreversible.
obd cluster prune-config <deploy name> [--confirm]
# example
obd cluster prune-config test
obd cluster prune-config test --confirm
The deploy name parameter specifies the deployment cluster name, which can be considered an alias for the configuration file. The --confirm option controls whether to skip the confirmation prompt during command execution. This option does not require a value. If specified, it skips the confirmation prompt and directly deletes the configuration file.
obd cluster upgrade
You can use this command to upgrade a running component.
obd cluster upgrade <deploy name> -c <component name> -V <version> [tags]
# example
obd cluster upgrade test -c oceanbase-ce -V 4.0.0.0 --usable=c63bb73384b17d74299b34fe3aceb0ae310fd319d2ccdb1acd39f31ba6673198
The deploy name parameter specifies the deployment name, which can be considered an alias for the configuration file.
Option |
Required |
Data Type |
Default Value |
Description |
|---|---|---|---|---|
| -c/--component | Yes | string | Empty string. | The name of the component to be upgraded. |
| -V/--version | No | string | Empty string. | The target version of the component to be upgraded.
NoteThis option is required when you upgrade a component other than OMS. |
| --tag | No | string | N/A | The tag of the target version. You can run the docker images command to view the tag (the TAG field).
NoteThis option is required when you upgrade OMS. |
| -i/--image-name | No | string | N/A | The name of the Docker image of the target version. You can run the docker images command to view the name (the REPOSITORY field).
NoteThis option is required when you upgrade OMS. |
| --skip-check | No | bool | false | Specifies whether to skip the check. |
| --usable | No | string | Empty string. | The list of image hashes used during the upgrade, separated by commas (,). If multiple images of the same version exist for the component to be upgraded, you must specify the image hash by using this option. |
| --disable | No | string | Empty string. | The list of image hashes that cannot be used during the upgrade, separated by commas (,). |
| -e/--executer-path | No | string | /usr/obd/lib/executer | The path of the interpreter used for the upgrade script. |
| -t/--script-query-timeout | No | int | N/A | If this option is not specified, the upgrade script determines whether a statement execution times out based on experience. The upgrade requires execution of multiple upgrade scripts. If the machine performance is poor and the upgrade times out, you can specify a larger value by using this option. The default unit is seconds (s). |
| --igs/--ignore-standby | No | bool | false | Specifies whether to forcibly execute the obd cluster upgrade command when an associated standby tenant cluster has not been upgraded. |
| --oms-backup-path | No | string | ~/oms/meta_backup_data |
The directory for storing the backup of OMS metadata. |
| --dob/--disable-oms-backup | No | bool | false | This option does not require a value. If you specify this option, OMS metadata backup is disabled. |
obd cluster reinstall
You can use this command to reinstall the repository of a deployed component. The new repository must have the same version number as the current repository. After you run this command when the deployment status is running, the component is restarted without parameters.
obd cluster reinstall <deploy name> -c <component name> --hash <hash> [-f/--force]
# example
[admin@test ~]$ obd mirror list
+------------------------------------------------------------------+
| Mirror Repository List |
+----------------------------+--------+---------+------------------+
| SectionName | Type | Enabled | Update Time |
+----------------------------+--------+---------+------------------+
| oceanbase.community.stable | remote | True | 2022-12-16 10:41 |
| oceanbase.development-kit | remote | True | 2022-12-16 10:41 |
| local | local | - | 2022-12-16 10:52 |
+----------------------------+--------+---------+------------------+
Use `obd mirror list <section name>` for more details
[admin@test ~]$ obd mirror list oceanbase.community.stable | grep -e " oceanbase-ce " | grep -e " 4.0.0.0 "
| oceanbase-ce | 4.0.0.0 | 100000272022110114.el7 | x86_64 | 759074414c7b7b723013855353f62a7ba0aae0f493216ef2511825850ce77b51 |
| oceanbase-ce | 4.0.0.0 | 100000282022112511.el7 | x86_64 | debb18ab3c0b3d16f145c41cd21c30686863580b721d45ddaa068e6309e03b64 |
| oceanbase-ce | 4.0.0.0 | 102000032022120718.el7 | x86_64 | c63bb73384b17d74299b34fe3aceb0ae310fd319d2ccdb1acd39f31ba6673198 |
[admin@test ~]$ obd cluster reinstall test -c oceanbase-ce --hash=c63bb73384b17d74299b34fe3aceb0ae310fd319d2ccdb1acd39f31ba6673198
The deploy name parameter specifies the deployment name, which can be considered an alias for the configuration file.
Option |
Required |
Data Type |
Default Value |
Description |
|---|---|---|---|---|
| -c/--component | Yes | string | Empty string. | The name of the component whose repository is to be replaced. |
| --hash | Yes | string | Empty string. | The hash value of the target repository. The target repository must have the same version number as the current repository. |
| -f/--force | No | bool | false | If this option is specified, the repository is forcibly replaced even if the startup fails. |
obd cluster tenant create
You can run this command to create a tenant. During the process, resource units and resource pools are automatically created. You do not need to manually create them. This command applies only to OceanBase Database.
obd cluster tenant create <deploy name> [-n <tenant name>] [flags]
# example
obd cluster tenant create test -n obmysql --max-cpu=2 --memory-size=2G --log-disk-size=3G --max-iops=10000 --iops-weight=2 --unit-num=1 --charset=utf8 -o htap -s 'ob_tcp_invited_nodes="%"'
The deploy name parameter specifies the name of the deployment, which can be considered an alias for the configuration file.
Note
Since obd V3.2.0, you can set a password for the root user of a tenant by using this command.
The options are described in the table below:
Option |
Required |
Data type |
Default value |
Description |
|---|---|---|---|---|
| -t/-n/--tenant-name | No | string | test | The name of the tenant. The corresponding resource units and resource pools are automatically generated based on the tenant name to avoid duplication. |
| --password | No | string | N/A | The password of the root user of the tenant. |
| --max-cpu | No | float | 0 | The maximum number of CPU cores available to the tenant. If the value is 0, all remaining CPU cores in the cluster are used. |
| --min-cpu | No | float | 0 | The minimum number of CPU cores available to the tenant. If the value is 0, it is equivalent to --max-cpu. |
| --max-memory | No | int | 0 | The maximum memory available to the tenant. If the value is 0, all remaining memory in the cluster is used. If the value is less than 1G, an error is returned.
NoteThis option is not supported in OceanBase Database V4.0.0.0 and later. You can use |
| --min-memory | No | int | 0 | The minimum memory available to the tenant. If the value is 0, it is equivalent to --max-memory.
NoteThis option is not supported in OceanBase Database V4.0.0.0 and later. You can use |
| --memory-size | No | int | 0 | The size of the memory unit available to the tenant. This option is supported only in OceanBase Database V4.0.0.0 and later. |
| --max-disk-size | No | int | 0 | The maximum disk space available to the tenant. If the value is 0, all remaining disk space in the cluster is used. If the value is less than 512M, an error is returned.
NoteThis option is not supported in OceanBase Database V4.0.0.0 and later. |
| --log-disk-size | No | int | 0 | The size of the log disk of the tenant. The minimum value is 2G. If the value is 0, all remaining LOG_DISK_CAPACITY in the cluster is used. You can log in to the sys tenant of the cluster as the root user and execute the SELECT * FROM oceanbase.GV$OB_SERVERS; statement to query the LOG_DISK_CAPACITY. | | --max-iops | No | int |
- 128 (for OceanBase Database versions earlier than V4.0.0)
- 1024 (for OceanBase Database V4.0.0 and later)
- For OceanBase Database versions earlier than V4.0.0, the value range is [128, +∞).
- For OceanBase Database V4.0.0 and later, the value range is [1024, +∞).
| --min-iops | No | int | 0 | The minimum IOPS of the tenant. The value range is the same as that of --max-iops. If the value is 0, it is equivalent to --max-iops. | | --iops-weight | No | int | 0 | The weight of the tenant's IOPS. This option is supported only in OceanBase Database V4.0.0.0 and later. | | --max-session-num | No | int | 64 | The maximum number of sessions for the tenant. The value range is [64, +∞).
Note
This option is not supported in OceanBase Database V4.0.0.0 and later.
| | --unit-num | No | int | 0 | The number of resource units in a single zone. The value must be less than the number of OBServer nodes in a single zone. If the value is0, the maximum value is automatically obtained. | | -z/--zone-list | No | string | Empty | The list of zones for the tenant. Separate multiple zones with commas (,). If the value is empty, all zones in the cluster are used. | | --mode | No | string | mysql | The mode of the tenant (MySQL/Oracle). OceanBase Database Community Edition supports only MySQL mode. | | --primary-zone | No | string | RANDOM | The primary zone of the tenant. | | --time-zone | No | varchar | +08:00 | The time zone for the tenant's sessions. You can specify the offset format +08:00 or the region format Asia/Shanghai. | | --charset | No | string | Empty string | The character set of the tenant. | | --collate | No | string | Empty string | The collation of the tenant. | | --replica-num | No | int | 0 | The number of replicas of the tenant. If the value is 0, it is equal to the number of zones. | | --logonly-replica-num | No | string | 0 | The number of log-only replicas of the tenant. If the value is 0, it is equivalent to --replica-num. | | --tablegroup | No | string | Empty string | The default table group of the tenant. | | --locality | No | string | Empty string | Describes the distribution of replicas across zones. For example, F@z1,F@z2,F@z3,R@z4 indicates that z1, z2, and z3 are full-featured replicas, and z4 is a read-only replica. | | -s/--variables | No | string | ob_tcp_invited_nodes='%' | Sets the system variable value of the tenant. When setting system variables, you must enclose the variable in single quotation marks (''). | | -o/--optimize | No | string | Default value is consistent with the cluster scenario | Sets the load type of the tenant. If this option is not set, an interactive option is provided for users to select the load type. Valid values:
express_oltp: suitable for workloads such as trade and payment core systems and high-throughput internet applications. It has no restrictions such as foreign keys, stored procedures, long transactions, large transactions, complex joins, or complex subqueries.complex_oltp: suitable for workloads such as banking and insurance systems. These systems usually have complex joins, complex correlated subqueries, batch jobs written in PL, long transactions, and large transactions. Parallel execution is sometimes used for short-running queries.olap: suitable for real-time data warehouse analysis scenarios.htap: suitable for hybrid OLAP and OLTP workloads. It is usually used to obtain real-time insights from active operational data, fraud detection, and personalized recommendations.kv: suitable for key-value workloads and wide-column workloads similar to HBase. These workloads usually have very high throughput and are sensitive to latency.
Notice
This option is supported only when the OceanBase Database version is V4.2.5 or later.
obd cluster tenant create-standby
This command is used to create a standby tenant for the primary tenant. This command is valid only for OceanBase Database. It automatically creates resource units and pools, so you do not need to manually create them. For more information about how to use this command, see Create and manage primary and standby tenants by using obd.
obd cluster tenant create-standby <standby deploy name> <primary deploy name> <primary tenant name> [options]
# example
obd cluster tenant create-standby test-standby test-primary tenant_a
The standby deploy name parameter specifies the deployment name of the cluster where the standby tenant is located. The primary deploy name parameter specifies the deployment name of the cluster where the primary tenant is located. The primary tenant name parameter specifies the name of the primary tenant.
For more information about the options, see the table below:
Option |
Required |
Data type |
Default value |
Description |
|---|---|---|---|---|
| -p/--tenant-root-password | No | string | Empty | The password of the root user of the primary tenant, which is used to connect to the primary tenant to create the standbyro user. This option is required only when the standbyro user has not been created under the primary tenant. |
| --standbyro-password | No | string | A random string | The password of the standbyro user provided by the primary tenant. This option is required only when the standbyro user has been created under the primary tenant (not by the create-standby or switch-log-source command).
NoteThe password of the |
| -t/-n/--tenant-name | No | string | The same as that of the primary tenant | The name of the standby tenant. |
| --password | No | string | N/A | The password of the root user of the standby tenant. |
| --type | No | string | SERVICE | The data synchronization method of the standby tenant. Valid value: LOCATION (based on archive) or SERVICE (based on network). |
| -d/--data_backup_uri | No | string | The directory path of the data backup file set when the primary tenant is backed up. | The directory path for storing the data backup file. When the standby tenant is created, the data backup information of the primary tenant is obtained from this path. If --type is set to LOCATION and this option is not specified, obd automatically obtains the data backup file path set when the primary tenant is backed up (by executing the obd cluster tenant set-backup-config command).
NoteIf the standby tenant cannot access the backup information configured for the primary tenant, specify this option. For example, when the primary and standby tenants are in different IDCs, the standby tenant cannot access the NFS of the primary tenant. In this case, copy the data backup file to a path that can be accessed by the standby tenant and specify this option. In this scenario, after the standby tenant is created, switch the log synchronization method to network-based synchronization. For more information, see Switch the data synchronization method between primary and standby tenants. |
| -a/--archive_log_uri | No | string | The directory path of the log archive file set when the primary tenant is backed up. | The directory path for storing the log archive file. When the standby tenant is created, the log archive information of the primary tenant is obtained from this path. If --type is set to LOCATION and this option is not specified, obd automatically obtains the log archive file path set when the primary tenant is backed up (by executing the obd cluster tenant set-backup-config command).
NoteIf the standby tenant cannot access the backup information configured for the primary tenant, specify this option. For example, when the primary and standby tenants are in different IDCs, the standby tenant cannot access the NFS of the primary tenant. In this case, copy the log archive file to a path that can be accessed by the standby tenant and specify this option. In this scenario, after the standby tenant is created, switch the log synchronization method to network-based synchronization. For more information, see Switch the data synchronization method between primary and standby tenants. |
| -D/--decryption | No | []string | N/A | The password of the backup set. If multiple passwords are set, separate them with commas (,). |
| --max-cpu | No | float | The same as that of the primary tenant. | The maximum number of CPU cores available to the tenant. If the value is 0, all available CPU cores of the cluster are used. |
| --min-cpu | No | float | The same as that of the primary tenant. | The minimum number of CPU cores available to the tenant. If the value is 0, it is equivalent to --max-cpu. |
| --memory-size | No | int | The same as that of the primary tenant. | The size of memory units available to the tenant. If the value is 0, all available memory of the cluster is used. An error is returned if the value is less than 1G. |
| --log-disk-size | No | int | The same as that of the primary tenant. | The size of the unit log disk of the tenant. The minimum value is 2G. If the value is 0, all available LOG_DISK_CAPACITY of the cluster is used. You can log in to the sys tenant of the cluster as the root user and execute the SELECT * FROM oceanbase.GV$OB_SERVERS; statement to query the LOG_DISK_CAPACITY. | | --max-iops | No | int | The same as that of the primary tenant. | The maximum IOPS of the tenant. Valid value: [1024,+∞). |
| --min-iops | No | int | The same as that of the primary tenant. | The minimum IOPS of the tenant. The value range is the same as that of --max-iops. If the value is 0, it is equivalent to --max-iops . | | --iops-weight | No | int | The same as that of the primary tenant. | The weight of the IOPS of the tenant. | | --unit-num | No | int | The same as that of the primary tenant. | The number of units in a single zone. The value must be less than the number of OBServer nodes in a single zone. If the value is 0, the maximum value is automatically obtained. | | -z/--zone-list | No | string | Empty | The list of zones for the tenant. Multiple zones are separated by commas (,). If this parameter is empty, it means all zones in the cluster. | | --primary-zone | No | string | RANDOM | The primary zone for the tenant. | | --time-zone | No | varchar | +08:00 | The time zone for the tenant session. Valid values: +08:00 and Asia/Shanghai. | | --replica-num | No | int | 0 | The number of replicas for the tenant. If this parameter is 0, it means the number of zones. | | --locality | No | string | Empty | The distribution of replicas across zones. For example, F@z1,F@z2,F@z3,R@z4 indicates that z1, z2, and z3 are full-featured replicas, and z4 is a read-only replica. | | -o/--optimize | No | string | Default value is consistent with the cluster scenario | The load type of the tenant. If this parameter is not specified, an interactive option is provided for you to choose the load type. Valid values:
express_oltp: suitable for workloads such as trade and payment core systems and high-throughput internet applications. It has no foreign key constraints, stored procedures, long transactions, large transactions, complex connections, or complex subqueries.complex_oltp: suitable for workloads such as banking and insurance systems. They usually have complex joins, complex correlated subqueries, batch jobs written in PL, and long or large transactions. Parallel execution is sometimes used for short-running queries.olap: suitable for real-time data warehouse analysis scenarios.htap: suitable for hybrid OLAP and OLTP workloads. It is usually used to obtain real-time insights from operational data, fraud detection, and personalized recommendations.kv: suitable for key-value workloads and wide-column workloads similar to HBase. These workloads usually have very high throughput and are sensitive to latency.
Notice
This option is supported only when the OceanBase Database version is V4.2.5 or later.
obd cluster tenant switch-log-source
You can run this command to switch the synchronization mode between the primary and standby tenants.
obd cluster tenant switch-log-source <deploy name> <tenant name>
# example
obd cluster tenant switch-log-source test-standby tenant_a --type=LOCATION
The deploy name parameter specifies the deployment name of the cluster where the standby tenant resides, and the tenant name parameter specifies the name of the standby tenant.
Option |
Required |
Data type |
Default value |
Description |
|---|---|---|---|---|
| --type | No | string | SERVICE | Specifies the synchronization mode of the standby tenant. Valid values: LOCATION (based on archive) and SERVICE (based on network). |
| -a/--archive_log_uri | No | string | The directory path of the log archive file set when the primary tenant is backed up. | The directory path where the log archive files are stored. The standby tenant will obtain the log archive information from this path. If --type is set to LOCATION and this option is not specified, obd will automatically obtain the log archive file path set when the primary tenant is backed up (by using the obd cluster tenant set-backup-config command). |
| -p/--tenant-root-password | No | string | Empty string. | The login password of the root user of the primary tenant, which is used to connect to the primary tenant to create the standbyro user. If the standbyro user has not been created in the primary tenant, this option is required. |
| --standbyro-password | No | string | A random string | The password of the standbyro user provided by the primary tenant to the standby tenant. This option cannot be empty. If the standbyro user has been created before (not by using the create-standby or switch-log-source command), this option is required and must be set to the password of the existing standbyro user.
NoteThe password of the standbyro user cannot contain the following characters: single quotation mark ( |
obd cluster tenant recover
You can run this command to enable continuous log synchronization. When you create a standby tenant based on an archive, continuous synchronization of logs from the source tenant (the primary tenant or another standby tenant) is not enabled. You must manually enable the continuous log synchronization mode for the standby tenant.
obd cluster tenant recover <deploy name> <tenant name>
# example
obd cluster tenant recover test-standby tenant_a --unlimited
The deploy name parameter specifies the deployment name of the cluster where the standby tenant resides, and the tenant name parameter specifies the name of the standby tenant.
Option |
Required |
Data type |
Default value |
Description |
|---|---|---|---|---|
| -S/--scn | No | int | 0 | Specifies the SCN to which the data is recovered. After this option is set, the data is recovered up to and including the specified SCN. |
| -T/--timestamp | No | time.time | None | Specifies the timestamp to which the data is recovered. After this option is set, the data is recovered up to and including the specified timestamp. |
| -u/--unlimited | No | bool | None | Specifies whether to continuously replay the archived source logs. No value is required. If this option is specified in the command, continuous replay of the archived source logs is enabled. |
obd cluster tenant switchover
You can run this command to switch the roles of the primary tenant and one of the standby tenants if the primary tenant is available. For more information about the usage of this command, see Role switching and decoupling.
obd cluster tenant switchover <standby deploy name> <standby tenant name> [options]
# example
obd cluster tenant switchover test-standby tenant_a --tenant-root-password=******
The standby deploy name parameter specifies the deployment name of the cluster where the standby tenant resides, and the standby tenant name parameter specifies the name of the standby tenant.
Option |
Required |
Data type |
Default value |
Description |
|---|---|---|---|---|
| -p/--tenant-root-password | Yes | string | Empty string. | The login password of the root user of the primary tenant. |
| --standbyro-password | No | string | A random string | The password of the standbyro user provided by the primary tenant to the standby tenant. This option cannot be empty. If the standbyro user has been created before (not by using the create-standby or switch-log-source command), this option is required and must be set to the password of the existing standbyro user.
NoteThe password of the standbyro user cannot contain the following characters: single quotation mark ( |
| --standby_archive_log_uri | No | string | Empty string. | The directory path where the archived logs of the standby tenant are stored. If you configure OSS as the storage medium and obd cannot automatically obtain the OSS path (for example, if the primary and standby tenants are deployed in a commercial OceanBase cluster), you must specify the storage directory path by using this option. |
| --primary_archive_log_uri | No | string | Empty string. | The directory path where the archived logs of the primary tenant are stored. If you configure OSS as the storage medium and obd cannot automatically obtain the OSS path (for example, if the primary and standby tenants are deployed in a commercial OceanBase cluster), you must specify the storage directory path by using this option. |
obd cluster tenant failover
You can run this command to convert a standby tenant to a primary tenant when the primary tenant is unavailable. For more information about how to use this command, see Role switching and decoupling.
obd cluster tenant failover <standby deploy name> <standby tenant name> [options]
# example
obd cluster tenant failover test-standby tenant_a --tenant-root-password=******
The standby deploy name parameter specifies the name of the cluster where the standby tenant is located. The standby tenant name parameter specifies the name of the standby tenant.
The -p option specifies --tenant-root-password, which is the login password of the root user of the standby tenant. The information of the standby tenant is synchronized with that of the primary tenant, and the root user passwords of the primary and standby tenants are the same.
obd cluster tenant decouple
You can run this command to convert a standby tenant to an independent tenant. For more information about how to use this command, see Role switching and decoupling.
obd cluster tenant decouple <standby deploy name> <standby tenant name> [options]
# example
obd cluster tenant decouple test-standby tenant_a --tenant-root-password=******
The standby deploy name parameter specifies the name of the cluster where the standby tenant is located. The standby tenant name parameter specifies the name of the standby tenant.
The -p option specifies --tenant-root-password, which is the login password of the root user of the standby tenant. The information of the standby tenant is synchronized with that of the primary tenant, and the root user passwords of the primary and standby tenants are the same.
obd cluster tenant show
You can run this command to view the tenants in the cluster. This command is applicable only to OceanBase Database.
obd cluster tenant show <deploy name> [options]
# example
obd cluster tenant show test -g
The deploy name parameter specifies the name of the cluster, which can be considered an alias for the configuration file.
Option |
Required |
Data type |
Default value |
Description |
|---|---|---|---|---|
| -g/--graph | No | bool | false | Displays the primary and standby tenants in the cluster. |
| -t/--tenant | No | string | Empty | Specifies the tenant to be displayed. After you specify this option, only the information about the specified tenant is displayed. |
obd cluster tenant drop
You can run this command to drop a tenant. This command automatically drops the resource units and resource pools corresponding to the tenant. This command is applicable only to OceanBase Database.
Notice
For tenants that are configured as primary and standby tenants, you must perform the following steps to drop them:
- First, perform the decoupling operation to remove the association between the primary and standby tenants. For more information, see Decouple primary and standby tenants.
- After the decoupling is successful, execute the tenant drop operation.
obd cluster tenant drop <deploy name> -n <tenant name>
# example
obd cluster tenant drop test -n obmysql
The deploy name parameter specifies the name of the cluster, which can be considered an alias for the configuration file.
The following table describes the options.
Option |
Required |
Data type |
Default value |
Description |
|---|---|---|---|---|
| -t/-n/--tenant-name | Yes | string | N/A | The name of the tenant to be dropped. |
| --igs/--ignore-standby | No | bool | false | If this option is specified, the obd cluster tenant drop command is forcibly executed even if a standby tenant exists under the tenant. After the tenant is dropped, the standby tenant cannot be used. |
obd cluster tenant optimize
You can use this command to optimize an existing tenant for a specified workload. This command is applicable only to OceanBase Database of version V4.2.5 or later.
obd cluster tenant optimize <deploy name> <tenant name> [options]
# example
obd cluster tenant optimize test obmysql -o complex_oltp -p ******
The deploy name parameter specifies the deployment name, which can be considered an alias for the configuration file. The tenant name parameter specifies the tenant name, and you must ensure that the tenant exists when specifying it.
The following table describes the options.
Option |
Required |
Data type |
Default value |
Description |
|---|---|---|---|---|
| -p/--tenant-root-password | No | string | Empty | The login password of the root user of the tenant. If a password is set for the root user, this option is required. |
| -o/--optimize | No | string | Consistent with the cluster workload type | Specifies the workload type of the tenant. If this option is not specified, an interactive option will be provided for you to select the workload type. The valid values are as follows:
|
obd cluster tenant set-backup-config
You can use this command to configure the backup information of a specified tenant.
obd cluster tenant set-backup-config <deploy name> <tenant name> [options]
#example
obd cluster tenant set-backup-config test obmysql -d 'file:///data/nfs/backup/data' -a 'file:///data/nfs/backup/log'
The deploy name parameter specifies the deployment name, which can be considered an alias for the configuration file. The tenant name parameter specifies the tenant name, and you must ensure that the tenant exists when specifying it.
The following table describes the options.
Option |
Required |
Data type |
Default value |
Description |
|---|---|---|---|---|
| -d/--data_backup_uri | Yes | string | N/A | The directory path for storing data backup files. |
| -a/--archive_log_uri | Yes | string | N/A | The directory path for storing log archive files. |
| -c/--log_archive_concurrency | No | int | 0 | The total number of worker threads for log archiving. Valid values: [0, 100]. |
| -b/--binding | No | string | OPTIONAL | The priority mode for archiving and business operations. Valid values:
|
| -s/--ha_low_thread_score | No | int | 0 | The current number of worker threads for high-availability low-priority tasks such as backup and backup cleanup. Valid values: [0, 100]. |
| -i/--piece_switch_interval | No | string | 1d | The cycle for switching pieces. Valid values: [1d, 7d]. |
| -l/--archive_lag_target | No | string | 120s | The target delay time for log archiving. It specifies the maximum interval between two consecutive log archive I/O operations. Valid values: [0ms, 7200s]. |
| -D/--delete_policy | No | string | N/A | The strategy for deleting backup data. Tenants with a cleanup strategy will trigger automatic cleanup every hour to ensure timely cleanup of expired backups. Currently, only the default value is supported. |
| -r/--delete_recovery_window | No | time | N/A | The recovery window time for application data deletion strategies. After setting this option, data within the window time from the current time is guaranteed to be recoverable. |
obd cluster tenant backup
You can use this command to back up a specified tenant.
Note
You cannot use this command to back up the sys tenant.
obd cluster tenant backup <deploy name> <tenant name> [options]
#example
obd cluster tenant backup test obmysql -P true
The deploy name parameter specifies the deployment name, which can be considered an alias for the configuration file. The tenant name parameter specifies the tenant name, and you must ensure that the tenant exists when specifying it.
The following table describes the options.
Option |
Required |
Data type |
Default value |
Description |
|---|---|---|---|---|
| -m/--backup_mode | No | string | full | The backup mode. Valid values:
|
| -e/--encryption | No | string | N/A | The password for encrypting the backup set. |
| -P/--plus_archive | No | bool | false | Specifies whether to include archived logs in the backup process when performing a combined data and log backup. If this option is set to true, a complement_log directory will be created in the directory for data backup files. |
obd cluster tenant backup-cancel
This command is used to cancel a tenant backup.
obd cluster tenant backup-cancel <deploy name> <tenant name>
#example
obd cluster tenant backup-cancel test obmysql
The deploy name parameter specifies the deployment name, which can be considered an alias for the configuration file. The tenant name parameter specifies the name of the tenant to be backed up. Ensure that the tenant exists before specifying it.
obd cluster tenant backup-show
This command is used to query tenant backup tasks.
obd cluster tenant backup-show <deploy name> <tenant name>
#example
obd cluster tenant backup-show test obmysql
The deploy name parameter specifies the deployment name, which can be considered an alias for the configuration file. The tenant name parameter specifies the name of the tenant to be backed up. Ensure that the tenant exists before specifying it.
obd cluster tenant restore
You can run this command to restore the backup data in the specified path to the specified tenant. Currently, only tenant-level restore is supported.
obd cluster tenant restore <deploy name> <tenant name> <data backup uri> <archive log uri> [options]
#example
obd cluster tenant restore test obmysql 'file:///data/nfs/backup/data' 'file:///data/nfs/backup/log' -z zone1
The required parameters in the command are described as follows:
deploy name: the name of the deployment, which can be considered an alias for the configuration file.tenant name: the name of the tenant. Make sure that no tenant with the same name exists before you specify this parameter. obd creates the tenant based on the settings.data backup uri: the directory path of the original data backup file.archive log uri: the directory path of the original log archive file.
The following table describes the options.
Option |
Required |
Data Type |
Default Value |
Description |
|---|---|---|---|---|
| -z/--zone | No | string | None | The name of the zone to which the tenant to be restored belongs. If multiple zones are specified, separate them with commas (,). If this option is not specified, all zones are used by default. |
| --unit-num | No | int | 1 | The number of units for the tenant in a zone. |
| --replica-type | No | string | FULL | The replica type of the tenant in a zone. Valid values:
|
| -p/--primary-zone | No | string | random | The primary zone of the tenant to be restored. |
| -T/--timestamp | No | time.time | None | The timestamp to which the data is to be restored. If this option is specified, the data is restored to the specified timestamp, including the data at the specified timestamp. |
| -S/--scn | No | int | 0 | The SCN to which the data is to be restored. If this option is specified, the data is restored to the specified SCN, including the data at the specified SCN. |
| -s/--ha-high-thread-score | No | int | 10 | The number of working threads for high-priority threads of high availability. Valid value: [0, 100]. |
| -c/--concurrency | No | int | ${max-cpu} |
The concurrency level of data restore. If this option is not specified, the default value is equal to the MAX_CPU value of the tenant. |
| -D/--decryption | No | []string | None | The password of the backup set. If multiple passwords are set, all passwords must be specified, and they are separated with commas (,). |
| -k/--kms-encrypt-info | No | string | None | The key management information. If the data is not encrypted or the original key management service can be accessed during restore, you can omit this option. |
| --memory-size | No | string | None | The available memory size of the tenant to be restored. We recommend that you set this parameter to the same value as the source tenant. If this option is not specified, the system automatically creates the tenant to be restored based on the remaining resources of the cluster. |
| --max-cpu | No | string | None | The maximum available CPU cores of the tenant to be restored. The minimum value is 1. We recommend that you set this parameter to the same value as the source tenant. If this option is not specified, the system automatically creates the tenant to be restored based on the remaining resources of the cluster. |
| --min-cpu | No | int | None | The minimum available CPU cores of the tenant. The minimum value is 1. If this option is not specified, the default value is equivalent to --max-cpu. |
| --max-iops | No | int | None | The maximum IOPS of the tenant. The minimum value is 1024. The specified value must satisfy --max-iops >= --min-iops. If this option is not specified, the system automatically calculates the value of --max-iops based on the following rules:
|
| --min-iops | No | int | None | The minimum IOPS of the tenant. The minimum value is 1024. If this option is not specified, the system automatically calculates the value of --min-iops based on the following rules:
|
| --log-disk-size | No | int | None | The size of the log disk of the tenant's unit. If this option is not specified, the default value is three times the memory specification value. The minimum value is 2G. |
obd cluster tenant restore-cancel
You can run this command to cancel the tenant restore.
obd cluster tenant restore-cancel <deploy name> <tenant name>
#example
obd cluster tenant restore-cancel test obmysql
The deploy name parameter specifies the name of the deployment, which can be considered an alias for the configuration file. The tenant name parameter specifies the name of the tenant to be restored.
obd cluster tenant restore-show
You can run this command to query the tenant restore task.
obd cluster tenant restore-show <deploy name> <tenant name>
#example
obd cluster tenant restore-show test obmysql
The deploy name parameter specifies the name of the deployment, which can be considered an alias for the configuration file. The tenant name parameter specifies the name of the tenant to be restored.
obd cluster chst
You can run this command to convert the configuration style.
obd cluster chst <deploy name> --style <STYLE> [-c/--components]
# example
obd cluster chst test -c oceanbase-ce --style cluster
The deploy name parameter specifies the deployment name, which can be considered an alias for the configuration file.
The following table describes the options.
Option |
Required |
Data Type |
Default Value |
Description |
|---|---|---|---|---|
| --style | Yes | string | N/A | The target configuration style. Valid values: default and cluster. |
| -c/--components | No | string | Empty string | The component to convert the configuration style for. Only OceanBase Database components are supported. |
obd cluster check4ocp
You can run this command to check whether the current configuration meets the requirements for OCP to take over the cluster.
obd cluster check4ocp <deploy name> [-c/--components] [-V/--version]
# example
obd cluster check4ocp test -V 4.0.0
The deploy name parameter specifies the deployment name, which can be considered an alias for the configuration file.
The following table describes the options.
Option |
Required |
Data Type |
Default Value |
Description |
|---|---|---|---|---|
| -c/--components | No | string | Empty string | The component in the cluster. You can specify multiple components separated by commas (,). This option is used to check the status of the cluster to be taken over and the connectivity between the cluster and OCP. |
| -V/--version | Yes | string | 3.1.1 | The version of OCP. This option is used to check whether the OCP version meets the takeover requirements. The value must be V3.1.1 or later. |
obd cluster export-to-ocp
You can run this command to export the OceanBase cluster managed by obd to OCP for management.
obd cluster export-to-ocp <deploy name> [options]
# simple example
obd cluster export-to-ocp test -a http://10.10.10.1:8080 -u admin -p password
# full example
obd cluster export-to-ocp test -a http://10.10.10.1:8080 -u admin -p password --host_type=type1 --credential_name=credential1
The deploy name parameter specifies the deployment name, which can be considered an alias for the configuration file.
The following table describes the options.
Option |
Required |
Data Type |
Default Value |
Description |
|---|---|---|---|---|
| -a/--address | Yes | string | N/A | The address of OCP. The value is in the http://IP:Port format. |
| -u/--user | Yes | string | N/A | The username of OCP. The user must have the permissions to perform operations related to cluster takeover. |
| -p/--password | Yes | string | N/A | The password of the OCP user. |
| --host_type | No | string | "" | The type of the host. If this option is not specified, obd selects the first host type that is queried or creates a new host type. |
| --credential_name | No | string | "" | The name of the credential. If this option is not specified, obd creates a new credential in OCP. |
obd cluster takeover
You can run this command to take over an OceanBase cluster that is not managed by obd. For more information, see Take over a cluster.
Note
This command is applicable only to OceanBase clusters. If other tools such as ODP are deployed in the cluster, these tools will not be taken over together with the OceanBase cluster. In other words, only the OceanBase cluster will be retained after the takeover.
obd cluster takeover <deploy name>
# example
obd cluster takeover test -h 10.10.10.1 -P 2881 -p ****** --ssh-user=admin --ssh-password=*******
The deploy name parameter specifies the name of the cluster to be taken over. After the takeover, obd manages the OceanBase cluster by using the cluster name.
The following table describes the options.
Option |
Required |
Data Type |
Default Value |
Description |
|---|---|---|---|---|
| -h/--host | Yes | string | 127.0.0.1 | The IP address of the OceanBase cluster to be taken over. You must specify the IP address of an OBServer node. |
| -P/--mysql-port | Yes | int | 2881 | The port of the OceanBase cluster to be taken over. |
| -p/--root-password | No | string | Empty string | The login password of the root@sys user in the OceanBase cluster.
NoticeDo not enclose the password in quotation marks. Otherwise, obd will treat the quotation marks as part of the password. |
| --ssh-user | No | string | Current user | The user used to start the nodes in the OceanBase cluster. |
| --ssh-password | No | string | Empty string | The password corresponding to --ssh-user, which is used to remotely connect to the OBServer node. |
| --ssh-port | No | int | 22 | The SSH remote port. |
| -t/--ssh-timeout | No | int | 30 | The timeout period for SSH connection, in seconds. |
| --ssh-key-file | No | string | Empty string | The path of the private key file. You must specify an absolute path for this option to enable password-free SSH authentication based on the private key. |
obd cluster scale_out
You can use this command to scale out the specified component of a running cluster by specifying the YAML file that contains the configuration information. For more information, see Scale out a cluster in Scale out and change components.
obd cluster scale_out <deploy name> -c <yaml path> [-f] [-C] [-t]
# example
obd cluster scale_out test -c scale_out.yaml
The deploy name parameter specifies the name of the deployed cluster, which can be considered an alias for the configuration file.
The following table describes the options.
Option |
Required |
Data type |
Default value |
Description |
|---|---|---|---|---|
| -c/--config | Yes | string | Empty | Specifies the path of the YAML file that contains the configuration information of the component to be scaled out. |
| -f/--force | No | bool | false | If this option is specified, the working directory is forcibly cleared. If the component requires the working directory to be empty and this option is not specified, an error will be returned when the working directory is not empty. |
| -C/--clean | No | bool | false | If this option is specified, the working directory (home_path) is cleared if it belongs to the current user. |
| -t/--scale_out_timeout | No | int | 3600 | Specifies the timeout period for scaling out an OceanBase component, in seconds. |
obd cluster component add
You can use this command to add a new component to a running cluster by specifying the YAML file that contains the configuration information. For more information, see Add a component in Scale out and change components.
obd cluster component add <deploy name> -c addtional_component.yaml [-f] [-C]
# example
obd cluster component add test -c addtional_component.yaml
The deploy name parameter specifies the name of the deployed cluster, which can be considered an alias for the configuration file.
The following table describes the options.
Option |
Required |
Data type |
Default value |
Description |
|---|---|---|---|---|
| -c/--config | Yes | string | Empty | Specifies the path of the YAML file that contains the configuration information of the component to be added. |
| --confirm | No | bool | false | This option does not require a value. The configuration in the command takes effect immediately. If this option is not specified, an interactive prompt will appear when you execute the command to confirm whether to restart the cluster. |
| -f/--force | No | bool | false | This option does not require a value. The configuration in the command takes effect immediately. If this option is specified, obd forcibly clears the working directory. If the component requires the working directory to be empty and this option is not specified, an error will be returned when the working directory is not empty. |
| -C/--clean | No | bool | false | This option does not require a value. The configuration in the command takes effect immediately. If this option is specified, obd clears the working directory (home_path) if it belongs to the current user. |
obd cluster component del
You can use this command to delete the specified component (multiple components can be specified) from a cluster. The cluster must be running when you execute this command. For more information, see Delete a component in Scale out and change components.
obd cluster component del <deploy name> <component> [<component> ... <component>]
# example
obd cluster component del test obagent
The deploy name parameter specifies the name of the deployed cluster, which can be considered an alias for the configuration file. The component name parameter specifies the name of the component to be deleted. You can specify multiple component names, separated by spaces.
The following table describes the options.
Option |
Required |
Data type |
Default value |
Description |
|---|---|---|---|---|
| -f/--force | No | bool | false | If this option is specified, the obd cluster component del command is forcibly executed when a connection cannot be established with the node of the component to be deleted. |
| --igs/--ignore-standby | No | bool | false | If this option is specified, the obd cluster component del command is forcibly executed even if a standby tenant exists in another cluster for the tenant in the current cluster.
NoticeAfter the oceanbase-ce component is deleted, the standby tenant cannot be used. |
obd cluster init4env
You can use this command to automatically set system parameters. When an error occurs during the system parameter check for a deployed cluster, you can execute this command based on the output to automatically set the system parameters.
obd cluster init4env <deploy name>
#example
obd cluster init4env test
The deploy name parameter specifies the name of the deployed cluster, which can be considered an alias for the configuration file.