obd provides multiple-level commands. You can use the -h/--help option to view the help information of sub-commands. Similarly, you can also use -v/--verbose to view the detailed execution process of commands when the execution of sub commands reports an error.
A deployment configuration is the minimum unit for obd cluster commands. A deployment configuration is a yaml file. It contains all configuration information of a deployment, including the server login information, component information, component configuration information, and component server list.
To start a cluster by using obd, you must register the deployment configuration of your cluster to obd. You can run the obd cluster edit-config command to create an empty deployment configuration or run the obd cluster deploy -c config command to import a deployment configuration.
obd cluster autodeploy
When you pass a simple configuration file to obd, obd will automatically generate a complete configuration file with the maximum specifications based on the resources of the target server, and then deploy and start a cluster on the target server.
Note
After you modify the configuration file, if you use this command to deploy the cluster, the modifications are overwritten by the configurations automatically generated by obd based on the server resources. In other words, the cluster can only be deployed by using the configurations automatically 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 name of the deployed cluster. You can consider it as an alias for the configuration file.
The following table describes the corresponding options.
| Option | Required | Data type | Default value | Description |
|---|---|---|---|---|
| -c/--config | Yes | string | None | Specifies the yaml file used for deployment and registers the deployment configuration to obd. When the deploy name already exists, obd will check the status of the existing deployment configuration. If the existing deployment configuration has not been applied, it will be overwritten. If the existing deployment configuration is in use, an error will be returned. |
| -f/--force | No | bool | false | Specifies whether to forcibly clear the working directory. When the component requires an empty working directory but this option is disabled, an error will be returned if the working directory is not empty. |
| -C/--clean | No | bool | false | Specifies whether to clear the working directory. When the working directory (home_path) belongs to the current operating user and this option is true, the working directory will be cleared. |
| -U/--ulp/--unuselibrepo | No | bool | false | Specifies whether to prevent obd from automatically taking actions when dependencies are missing. If this option is disabled and obd detects that some dependencies are missing, obd will automatically search for the corresponding libs mirrors and install them. If this option is enabled, the unuse_lib_repository: true field will be added to the corresponding configuration file. You can also add the unuse_lib_repository: true field to the configuration file to enable this option. |
| -A/--act/--auto-create-tenant | No | bool | false | Specifies whether to enable obd to create the test tenant during the bootstrap by using all available resources of the cluster. If this option is enabled, the auto_create_tenant: true field will be added to the corresponding configuration file. You can also add the auto_create_tenant: true field to the configuration file to enable this option. |
| -s/--strict-check | No | bool | false | Some components will do relevant checks before starting. It will issue an alarm when the check fails, but it will not force the process to stop. Using this option can return an error and directly exit the process when the component pre-check fails. We recommend that you enable this option to avoid startup failures due to insufficient resources. |
| --gcc/--generate-consistent-config | No | bool | false | Specifies whether to generate consistent configurations if multiple servers are involved in a deployment. For example, if the configurable memory of server A and server B is 10 GB and 20 GB respectively, enabling this option will automatically set them to 10 GB (the smaller value). |
obd cluster edit-config
Modifies a deployment configuration or creates one when the specified deployment configuration does not exist.
obd cluster edit-config <deploy name>
# example
obd cluster edit-config test
The deploy name parameter specifies the name of the deployed cluster. You can consider it as an alias for the configuration file.
obd cluster deploy
Deploys a cluster based on the deployment configuration file. Based on the deployment configuration file, this command finds the matching mirror, then installs the mirror in a local repository. This process is called local installation. Then, obd distributes the components of the required version in the local repository to the target server. This process is called remote installation. During both local and remote installation, obd checks whether the server stores dependencies required for running the components. This command allows you to deploy a cluster based on a deployment configuration that has been registered to obd or by passing a yaml file.
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 deployed cluster. You can consider it as an alias for the configuration file.
The following table describes the corresponding options.
| Option | Required | Data type | Default value | Description |
|---|---|---|---|---|
| -c/--config | No | string | None | Specifies the yaml file used for deployment and registers the deployment configuration to obd. If this option is enabled and a deployment configuration of the specified deploy name already exists, the existing deployment configuration will be overwritten. If this option is not enabled, obd will search for the registered deployment configuration of the specified deploy name. |
| -f/--force | No | bool | false | Specifies whether to forcibly clear the working directory. When the component requires an empty working directory but this option is disabled, an error will be returned if the working directory is not empty. |
| -C/--clean | No | bool | false | Specifies whether to clear the working directory. When the working directory (home_path) belongs to the current operating user and this option is true, the working directory will be cleared. |
| -U/--ulp/--unuselibrepo | No | bool | false | Specifies whether to prevent obd from automatically taking actions when dependencies are missing. If this option is disabled and obd detects that some dependencies are missing, obd will automatically search for the corresponding libs mirrors and install them. If this option is enabled, the unuse_lib_repository: true field will be added to the corresponding configuration file. You can also add the unuse_lib_repository: true field to the configuration file to enable this option. |
| -A/--act/--auto-create-tenant | No | bool | false | Specifies whether to enable obd to create the test tenant during the bootstrap by using all available resources of the cluster. If this option is enabled, the auto_create_tenant: true field will be added to the corresponding configuration file. You can also add the auto_create_tenant: true field to the configuration file to enable this option. |
obd cluster start
Starts a deployed cluster. If the cluster is started, obd will return its status.
obd cluster start <deploy name> [flags]
# example
obd cluster start test -S
The deploy name parameter specifies the name of the deployed cluster. You can consider it as an alias for the configuration file.
This table describes the corresponding options.
| Option | Required | Data type | Default value | Description |
|---|---|---|---|---|
| -s/--servers | No | string | Empty | A list of machines, followed by the name value corresponding to servers in the yaml file, separated by ,. If the name value is not configured after servers, the ip value is used. Be used for specifying the machines need to be started. If this option is disabled, all machines under the component will start without executing bootstrap. |
| -c/--components | No | string | Empty | A list of components, separated by ,. Be used for specifying the components need to be started. If this option is disabled, all machines under the component will start without entering the running state. |
| --wop/--without-parameter | No | bool | false | Start without parameters. The node does not respond to this option when this node is starting for the first time. |
| -S/--strict-check | No | bool | false | Some components will do relevant checks before starting. obd will throw an error when the check fails, but obd will not force the process to stop. Using this option can return an error and directly exit the process when the component pre-check fails. We recommend that you enable this option to avoid startup failures due to insufficient resources. |
obd cluster list
Displays the state of all clusters (specified by the deploy name parameter) registered with obd.
obd cluster list
A cluster registered with obd may be in any of the following states:
configured: Indicates that the configuration file of this cluster is already included in obd, but the cluster has not been deployed. You can run theobd cluster deploycommand to deploy the cluster.deployed: Indicates that the cluster has been deployed but not yet started. You can run theobd cluster startcommand to start the cluster.running: Indicates that the cluster is running.stopped: Indicates that one or more components of the cluster have been stopped. You can run theobd cluster startcommand to start the cluster.upgrading: Indicates that one or more components of the cluster are being upgraded.destroyed: Indicates that the cluster has been destroyed.
obd cluster display
Shows the status of the specified cluster.
obd cluster display <deploy name>
# example
obd cluster display test
The deploy name parameter specifies the name of the deployed cluster. You can consider it as an alias for the configuration file.
obd cluster reload
Reloads a running cluster. After you modify the configuration information of a running cluster by using the edit-config command, you can run the reload command to let your modification take effect.
NOTE:
Some configuration items may not take effect after you run the
reloadcommand. You need to restart or even redeploy the cluster for these configuration items to take effect. Do operations based on the result returned by theedit-configcommand.
obd cluster reload <deploy name>
# example
obd cluster reload test
The deploy name parameter specifies the name of the deployed cluster. You can consider it as an alias for the configuration file.
obd cluster restart
Restarts a running cluster. By default, obd restarts without any parameters. After you run the edit-config command to modify the configuration information of a running cluster, you can run the restart command for the modification to take effect.
NOTE:
Some configuration items may not take effect after you run the
restartcommand. You even need to redeploy the cluster for some configuration items to take effect. Perform operations based on the result returned by the edit-config command.
obd cluster restart <deploy name>
# example
obd cluster restart test -c obproxy-ce --wp
The deploy name parameter specifies the name of the deployed cluster. You can consider it as an alias for the configuration file.
This table describes the corresponding options.
| Option | Required | Data type | Default value | Description |
|---|---|---|---|---|
| -s/--servers | No | string | Empty | A list of machines, followed by the name value corresponding to servers in the yaml file, separated by ,. If the name value is not configured after servers, the ip value is used. Be used to specify the machines need to be restarted. |
| -c/--components | No | string | Empty | A list of components, separated by ,. Be used to specify the components need to be restarted. If this option is disabled, all machines under the component will start without entering the running state. |
| --wp/--with-parameter | No | bool | false | Restarts obd with parameters. This option makes the parameters valid when you restart obd. |
obd cluster redeploy
Redeploys a running cluster. After you run the edit-config command to modify the configurations of a running cluster, you can run the redeploy command to apply the modifications.
Notice
This command will destroy and redeploy the cluster. The data in the cluster will be lost. Therefore, back up the data before you run this command.
obd cluster redeploy <deploy name> [-f]
# example
obd cluster redeploy test -f
The deploy name parameter specifies the name of the deployed cluster, which is the alias for the configuration file.
| Option | Required? | Data type | Default value | Description |
|---|---|---|---|---|
| -f/--force-kill | No | bool | false | Before executing the destroy command, obd will check whether any process is running. A running process may be retained because the start command fails, or because the process belongs to another cluster with the same configuration. Regardless of the reason for having running processes in the working directory, obd will directly stop executing the obd cluster redeploy command. After you enable the -f option, if a running process is found in the working directory, obd will forcibly stop the process and execute the obd cluster redeploy command. |
| --confirm | No | bool | false | During the execution of this command, you will be prompted to confirm whether to restart the cluster. Enabling this option will bypass the reconfirmation process and directly restart the cluster. |
| --igs/--ignore-standby | No | string | Empty | After you enable this option, obd will forcibly execute the obd cluster redeploy command if a tenant in the cluster has a standby tenant in another cluster. Once the cluster is destroyed, the standby tenant will become unavailable. |
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 name of the deployed cluster. You can consider it as an alias for the configuration file.
This table describes the corresponding options.
| Option | Required | Data type | Default value | Description |
|---|---|---|---|---|
| -s/--servers | No | string | Empty | A list of machines, followed by the name value corresponding to servers in the yaml file, separated by ,. If the name value is not configured after servers, the ip value is used. Be used to specify the machines need to be stopped |
| -c/--components | No | string | Empty | A list of components, separated by ,. Be used to specify the components need to be stopped. If not all components under the configuration start, this configuration will not enter the stopped state. |
obd cluster destroy
Destroys a deployed cluster. If the cluster is running, this command will first attempt to stop the cluster. If the stop operation is successful, it will then proceed to destroy the cluster.
obd cluster destroy <deploy name> [-f]
# example
obd cluster destroy test -f
The deploy name parameter specifies the name of the deployed cluster, which is the alias for the configuration file.
| Option | Required? | Data type | Default value | Description |
|---|---|---|---|---|
| -f/--force-kill | No | bool | false | Before executing the destroy command, obd will check whether any process is running. A running process may be retained because the start command fails, or because the process belongs to another cluster with the same configuration. Regardless of the reason for having running processes in the working directory, obd will directly stop executing the obd cluster destroy command. After you enable the -f option, if a running process is found in the working directory, obd will forcibly stop the process and execute the obd cluster destroy command. |
| --igs/--ignore-standby | No | bool | false | After you enable this option, obd will forcibly execute the obd cluster destroy command if a tenant in the cluster has a standby tenant in another cluster. Once the cluster is destroyed, the standby tenant will become unavailable. |
obd cluster upgrade
Update 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 name of the deployed cluster. You can consider it as an alias for the configuration file.
| Option | Required | Data type | Default value | Description |
|---|---|---|---|---|
| -c/--component | Yes | string | Empty | The component name you want to upgrade. |
| -V/--version | Yes | string | Empty | The target upgrade version number. |
| --skip-check | No | bool | false | Skip check. |
| --usable | No | string | Empty | The hash list for the mirrors that you use during upgrade. Separated with ,. |
| --disable | No | string | Empty | The hash list for the mirrors that you disable during upgrade. Separated with ,. |
| -e/--executer-path | No | string | /usr/obd/lib/executer | The executer path for the upgrade script. |
| -t/--script-query-timeout | No | int | None | If this option is not specified, the upgrade script determines whether the execution of a statement is timed out based on empirical values. Multiple upgrade scripts need to be executed for the upgrade process. If the upgrade is timed out due to poor server performance, you can specify a large value for this option and try again. This option is measured in seconds (s) by default. |
| --igs/--ignore-standby | No | bool | false | After you enable this option, obd will forcibly execute the obd cluster upgrade command upon detecting that the cluster of a standby tenant has not been upgraded. |
obd cluster reinstall
You can run this command to reinstall the repository of a deployed component. The new repository must have the same version number as the previous repository. If this command is used to replace the repository when the deployment status is 'running', the component is restarted after the replacement without loading 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 indicates the name of the deployed cluster, which is also the alias of the configuration file.
| Option name | Required | Data type | Default value | Description |
|---|---|---|---|---|
| -c/--component | Yes | string | Null | The name of the component whose repository is to be replaced. |
| --hash | Yes | string | Null | The hash value of the target repository. The target repository must be of the same version as the current repository. |
| -f/--force | No | Bool | false | Specifies whether to enable forced replacement even if the restart fails. |
obd cluster tenant create
Creates a tenant. This command applies only to an OceanBase cluster. This command automatically creates resource units and resource pools.
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 deployed cluster. You can consider it as an alias for the configuration file.
Note
If you use this command to create a tenant, the administrator password of the tenant is empty by default. For steps on connecting to a tenant after creating the tenant, see Connect to OceanBase Database in the OceanBase Database documentation.
This table describes the corresponding options.
| Option | Required | Data type | Default value | Description |
|---|---|---|---|---|
| -t/-n/--tenant-name | No | string | test | The tenant name. obd will automatically generate resource units and resource pools with unique names based on the tenant name. |
| --max-cpu | No | float | 0 | The maximum number of CPU cores available for the tenant. When this option is set to 0, all available CPU cores of the cluster can be used by the tenant. |
| --min-cpu | No | float | 0 | The minimum number of CPU cores available for the tenant. When this option is set to 0, the minimum number of CPU cores is the same as the maximum number of CPU cores. |
| --max-memory | No | int | 0 | The maximum memory capacity available for the tenant. When this option is set to 0, all available memory capacity of the cluster can be used by the tenant. When the actual value is less than 1 GB, an error is returned.
Not supported after the OceanBase database V4.0.0.0. You can use |
| --min-memory | No | int | 0 | The minimum memory capacity available for the tenant. When this option is set to 0, the minimum memory capacity is the same as the maximum memory capacity.
Not supported after the OceanBase database V4.0.0.0. You can use |
| --memory-size | No | int | 0 | The available memory unit size of the tenant. Supported since the OceanBase database V4.0.0.0. |
| --max-disk-size | No | int | 0 | The maximum disk space available for the tenant. When this option is set to 0, all available disk space of the cluster can be used by the tenant. If the actual value is less than 512 MB, an error is returned.
Not supported after the OceanBase database V4.0.0.0. |
| --log-disk-size | No | int | 0 | Specifies the tenant's Unit log disk size. The default value is 3 times the memory specification value. The minimum value is 2G. |
| --max-iops | No | int |
|
The maximum IOPS for the tenant. The value range of this parameter can be divided into the following two cases according to the OceanBase version.
|
| --min-iops | No | int | 0 | The minimum IOPS for the tenant. The value range is the same as --max-iops. When this option is set to 0, the minimum IOPS is the same as the maximum IOPS. |
| --iops-weight | No | int | 0 | Specifies the weight of the tenant's IOPS. Supported since the OceanBase database V4.0.0.0. |
| --max-session-num | No | int | 64 | The maximum number of sessions allowed for the tenant. Value range: [64, +∞).
Not supported after the OceanBase database V4.0.0.0. |
| --unit-num | No | int | 0 | The number of units to be created in a zone. It must be less than the number of OBServers in the zone. When this option is set to 0, the maximum value is used. |
| -z/--zone-list | No | string | Empty | Specifies the list of zones of the tenant. Separate multiple zones with commas (,). If this option is not specified, all zones of the cluster are included. |
| --primary-zone | No | string | RANDOM | The primary zone of the tenant. |
| --charset | No | string | Empty | The character set of the tenant. |
| --collate | No | string | Empty | The collation of the tenant. |
| --replica-num | No | int | 0 | The number of replicas of the tenant. When this option is set to 0, the number of replicas is the same as that of zones. |
| --logonly-replica-num | No | string | 0 | The number of log replicas of the tenant. When this option is set to 0, the number of log replicas is the same as that of replicas. |
| --tablegroup | No | string | Empty | The default table group of the tenant. |
| --locality | No | string | Empty | The distribution status of replicas across zones. For example, F@z1,F@z2,F@z3,R@z4 means that z1, z2, and z3 are full-featured replicas and z4 is a read-only replica. |
| -s/--variables | No | string | ob_tcp_invited_nodes='%' | The system variables of the tenant. When setting system variables, variables should be placed within single quotes (''). |
| -o/--optimize | No | String | Consistent with the cluster type | The load type of the tenant. If this option is not specified, obd provides interactive options for you to select a load type. Valid values:
NoticeThis parameter is available in OceanBase Database V4.3.0 and later. |
obd cluster tenant create-standby
Creates a standby tenant for the primary tenant. This command is only valid for OceanBase Database. This command automatically creates resource units and resource pools for the standby tenant, eliminating the need for manual creation. For more information about the command, see Deploy 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 name of the cluster where the standby tenant is located. The primary deploy name parameter specifies the name of the cluster where the primary tenant is located. The primary tenant name parameter specifies the name of the primary tenant.
The following table describes the options.
| Option | Required? | Data type | Default value | Description |
|---|---|---|---|---|
| -p/--tenant-root-password | No | string | Empty | The password for the root user of the primary tenant. If no standby tenant has ever been created in the cluster where the primary tenant is located, this option is required. |
| --standbyro-password | No | string | Random string | The password for the account (standbyro) provided by the primary tenant to the standby tenant. This option must not be left empty. If the standbyro account has been created before (not by using the create-standby command), this option is required.
Note |
| -t/-n/--tenant-name | No | string | Consistent with that of the primary tenant | The name of the standby tenant. |
| --max-cpu | No | float | Consistent with that of the primary tenant | The maximum number of CPU cores available for the standby tenant. If the value is set to 0, all remaining CPU cores in the cluster are available for the standby tenant. |
| --min-cpu | No | float | Consistent with that of the primary tenant | The minimum number of CPU cores available for the standby tenant. If the value is set to 0, the minimum number of CPU cores available for the standby tenant is the same as the value specified by --max-cpu. |
| --memory-size | No | int | Consistent with that of the primary tenant | The size of memory available for the standby tenant. If the value is set to 0, all remaining memory of the cluster is available for the standby tenant. An error is returned when the actual size of memory available for the standby tenant is less than 1 GB. |
| --log-disk-size | No | int | Consistent with that of the primary tenant | The size of log disk space available for the standby tenant. The default value is three times the memory size. The minimum value is 2 GB. |
| --max-iops | No | int | Consistent with that of the primary tenant | The maximum input/output operations per second (IOPS) allowed for the standby tenant. Value range: [1024,+∞). |
| --min-iops | No | int | Consistent with that of the primary tenant | The minimum IOPS allowed for the standby tenant. The value range is the same as that of --max-iops. If the value is set to 0, the minimum IOPS allowed for the standby tenant is the same as the value specified by --max-iops. |
| --iops-weight | No | int | Consistent with that of the primary tenant | The IOPS weight for the standby tenant. |
| --unit-num | No | int | Consistent with that of the primary tenant | The number of resource units for each zone, which must be less than the number of OBServer nodes in each zone. If the value is set to 0, resource units are created to the maximum extent possible. |
| -z/--zone-list | No | string | Empty | The zone list of the standby tenant. Separate multiple zones with commas (,). If this option is left empty, it indicates all zones of the cluster. |
| --primary-zone | No | string | RANDOM | The primary zone of the standby tenant. |
| --replica-num | No | int | 0 | The number of replicas for the standby tenant. If the value is set to 0, the number of replicas is equal to the number of zones. |
| --locality | No | string | Empty | The distribution of replicas among zones. For example, "F@z1,F@z2,F@z3,R@z4" indicate that zones z1, z2, and z3 are full-featured replicas, while zone z4 is a read-only replica. |
obd cluster tenant switchover
Switches roles between the primary tenant and one of the standby tenants when the primary tenant is available. For more information about the command, see Switch the roles of tenants and decouple a standby tenant from the primary tenant.
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 name of the cluster where the standby tenant is located. 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 | The password for the root user of the primary tenant. |
| --standbyro-password | No | string | Random string | The password for the account (standbyro) provided to the standby tenant by the primary tenant. This option must not be left empty. If the standbyro account has been created before (not by using the create-standby command), this option is required.
Note |
obd cluster tenant failover
Switches a standby tenant to the primary tenant in case the original primary tenant is unavailable. For more information about the command, see Switch the roles of tenants and decouple a standby tenant from the primary tenant.
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 option -p or --tenant-root-password specifies the password for the root user of the standby tenant. The information about the standby tenant is synchronized with the primary tenant, and the root user passwords of both the primary and standby tenants are the same.
obd cluster tenant decouple
Decouples a standby tenant from the primary tenant. After decoupling, the standby tenant becomes an independent regular tenant. For more information about the command, see Switch the roles of tenants and decouple a standby tenant from the primary tenant.
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 option -p or --tenant-root-password specifies the password for the root user of the standby tenant. The information about the standby tenant is synchronized with the primary tenant, and the root user passwords of both the primary and standby tenants are the same.
obd cluster tenant show
Displays the tenants in a cluster. This command is only valid for 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 deployed cluster, which is the alias for the configuration file.
| Option | Required? | Data type | Default value | Description |
|---|---|---|---|---|
| -g/--graph | No | bool | false | The information about the primary and standby tenants in the cluster. |
| -t/--tenant | No | string | Empty | The tenants to display. After this option is specified, only configured tenants are displayed. |
obd cluster tenant drop
Drops a tenant. This command is only valid for OceanBase Database.
This command automatically drops the resource units and resource pools of the specified tenant.
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 deployed cluster, which is the alias for the configuration file.
The following table describes the options.
| Option | Required? | Data type | Default value | Description |
|---|---|---|---|---|
| -t/-n/--tenant-name | Yes | string | None | The name of the tenant to be dropped. |
| --igs/--ignore-standby | No | bool | false | After you enable this option, obd will forcibly execute the obd cluster tenant drop command if the target tenant has a standby tenant. Once the target tenant is dropped, the standby tenant will become unavailable. |
obd cluster tenant optimize
You can use this command to optimize the performance of a tenant in a specified scenario. This command is available in OceanBase Database V4.3.0 and later.
obd cluster tenant optimize <deploy name> <tenant name> [options]
# example
obd cluster tenant optimize test obmysql -o complex_oltp
The deploy name parameter specifies the name of the deployed cluster, which is also the alias of the configuration file. The tenant name parameter specifies the name of an existing tenant.
You can use the -o or --optimize option to specify the load type of the tenant. By default, the load type of the tenant is consistent with the cluster type. If this option is not specified, obd provides interactive options for you to select a load type. Valid values:
express_oltp: suitable for workloads such as trading and core payment systems and high-throughput online applications. Such workloads do not involve restrictions such as foreign keys, stored procedures, long-running or large transactions, complex join operations, or complex subqueries.complex_oltp: suitable for workloads such as banking and insurance systems. These workloads often involve complex join operations, complex subqueries, batch processing jobs compiled in PL, long-running transactions, and large transactions. Short-running queries are sometimes executed in parallel.olap: suitable for real-time data warehouse analytics.htap: suitable for HTAP workloads. You can use it to quickly get insights from campaign operation data, fraud detection, and scenario-specific recommendations.kv: suitable for workloads that involve a high throughput and are sensitive to latency, such as key-value workloads and wide-column workloads of an HBase database.
obd cluster chst
You can run this command to change 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 name of the deployed cluster. You can consider it as an alias for the configuration file.
The following table describes details about the available options.
| Option | Required | Data type | Default value | Description |
|---|---|---|---|---|
| --style | Yes | string | N/A | The preferred configuration style. Valid values: default and cluster. |
| -c/--components | No | string | Empty | The components whose configuration style need to be changed. Separate multiple components with commas ,. |
obd cluster check4ocp
You can run this command to check whether the current configurations can be taken over by OceanBase Cloud Platform (OCP).
obd cluster check4ocp <deploy name> [-c/--components] [-V/--version]
# example
obd cluster check4ocp test -V 4.0.0
The deploy name parameter specifies the name of the deployed cluster. You can consider it as an alias for the configuration file.
can be understood as an alias for the configuration file
The following table describes details about the available options.
| Option | Required | Data type | Default value | Description |
|---|---|---|---|---|
| -c/--components | No | string | Empty | The components that need to be taken over by OCP. Separate multiple components with commas ,. |
| -V/--version | Yes | string | 3.1.0 | The OCP version. |
obd cluster export-to-ocp
Exports an OceanBase cluster managed in the current 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 name of the deployed cluster. You can consider it as an alias for the configuration file.
The following table describes the related options.
| Option | Required | Data type | Default value | Description |
|---|---|---|---|---|
| -a or --address | Yes | String | N/A | The URL for accessing the OCP console, for example, http://10.10.10.1:8080. |
| -u or --user | Yes | String | N/A | The OCP user with permissions to perform cluster-related operations. |
| -p or --password | Yes | String | N/A | The OCP user password. |
| --host_type | No | String | "" | The type of the host. If this option is not specified, obd will either select the first host type found or create a new host type. |
| --credential_name | No | String | "" | The name of the credential. If this option is not configured, obd will create a new credential in OCP. |
obd cluster takeover
You can run this command to take over an OceanBase database that is not deployed by using OceanBase Deployer (obd). For more information, see Use obd to take over a cluster.
Note
You can use this command to take over only an OceanBase database. If other tools, such as OceanBase Database Proxy (ODP), are deployed in the cluster to which the OceanBase database belongs, these tools are not taken over along with the OceanBase database. Only the OceanBase database is retained in the cluster 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=*******
deploy name specifies the name of the cluster after the takeover. After the takeover is successful, obd manages the OceanBase cluster based on 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 connection IP address of the OceanBase cluster to be taken over, which must be the IP address of an OBServer node. |
| -P/--mysql-port | Yes | Integer | 2881 | The connection port of the OceanBase cluster to be taken over. |
| -p/--root-password | No | String | Empty | The logon password for the root@sys user in the OceanBase cluster.
NoticeDo not enclose the password with quotation marks when you specify the password. Otherwise, obd will recognize the quotation marks as a part of the password. |
| --ssh-user | No | String | Name of the current user | The user used to start a node in the OceanBase cluster. |
| --ssh-password | No | String | Empty | The password of the user specified by --ssh-user, which is used to remotely connect to the OBServer node. |
| --ssh-port | No | Integer | 22 | The Secure Shell (SSH) remote port. |
| -t/--ssh-timeout | No | Integer | 30 | The timeout period for an SSH connection, in seconds. |
| --ssh-key-file | No | String | Empty | The path to the private key file, which must be an absolute path. The path is used for SSH password-free authentication based on a private key. |
obd cluster scale_out
You can run this command to scale out the specified components in a running cluster by specifying the configuration information in the YAML format. For more information about scale-out operations, see the Scale out a cluster section in the Scale out a cluster and change cluster components topic.
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 indicates the name of the deployed cluster, which is also the alias of the configuration file.
The following table describes the options.
| Option | Required? | Data type | Default value | Description |
|---|---|---|---|---|
| -c/--config | Yes | String | N/A | The path of the YAML file that contains the configuration information of the component to be scaled out. |
| -f/--force | No | Boolean | false | If you set the value to true, the working directory is force cleared. When the component requires an empty working directory and does not use this option, an error is returned when the working directory is not empty. |
| -C/--clean | No | Boolean | false | If you set the value to true, the working directory home_path is cleared if it belongs to the logged-on user. |
| -t/--scale_out_timeout | No | Integer | 3600 | The timeout period, in seconds, for the scale-out of an OceanBase component. |
obd cluster component add
You can run this command to add a new component to a running cluster by specifying the configuration information in the YAML format. For more information, see the Add a component section in the Scale out a cluster and change cluster 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 is also the alias of the configuration file.
The following table describes the options.
| Option | Required? | Data type | Default value | Description |
|---|---|---|---|---|
| -c/--config | Yes | String | N/A | The path of the YAML file that contains the configuration information of the component to be added. |
| -f/--force | No | Boolean | false | If you set the value to true, the working directory is force cleared. When the component requires an empty working directory and does not use this option, an error is returned when the working directory is not empty. |
| -C/--clean | No | Boolean | false | If you set the value to true, the working directory home_path is cleared if it belongs to the logged-on user. |
obd cluster component del
You can run this command to delete one or more specified components of a cluster in the running state. For more information, see the Delete a component section in Scale out a cluster and change cluster 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 is also the alias of the configuration file. The component name parameter specifies the name of the component to be deleted. You can specify multiple component names and separate them with spaces.
The following table describes the options in the command.
| Option | Required | Data type | Default value | Description |
|---|---|---|---|---|
| -f/--force | No | bool | false | Specifies whether to forcibly run the obd cluster component del command when obd cannot connect to the component to be deleted. |
| --igs/--ignore-standby | No | bool | false | Specifies whether to forcibly run the obd cluster component del command if a tenant in the cluster has a standby tenant in another cluster when you delete the oceanbase-ce component.
NoticeAfter the |