This topic describes how to use OceanBase Cloud Platform (OCP) to take over a cluster deployed by OceanBase Deployer (obd). The cluster named test, which is started by using the distributed-example.yaml configuration file, is used as an example.
Prerequisites
- The obd version is V1.3.0 or later.
- The OCP version is V3.1.1-ce or later.
Modify the OceanBase cluster
Check whether takeover conditions are met
Before using OCP to take over an OceanBase cluster deployed by obd, run the following command to check whether takeover conditions are met. If the conditions are not met, modify the cluster based on prompts as follows:
obd cluster check4ocp <deploy-name>
# Example
obd cluster check4ocp test
For information about the obd cluster check4ocp command, see obd cluster check4ocp.
Configure IDC information
The configuration file of default style does not support the configuration of Internet Data Center (IDC) information. You need to use the new feature of obd V1.3.0 to change the style of the configuration file to the cluster style.
Run the following command to change the style:
obd cluster chst <deploy name> --style <STYLE> [-c/--components]
# Example
obd cluster chst test -c oceanbase-ce --style cluster
For information about the obd cluster chst command, see obd cluster chst.
After changing the style of the configuration file, run the following command to enter the edit mode and add IDC information for the zone.
obd cluster edit-config <deploy name>
# Example
obd cluster edit-config test
For information about the obd cluster edit-config command, see obd cluster edit-config.
Configuration for reference:
## Only need to configure when remote login is required
# user:
# username: your username
# password: your password if need
# key_file: your ssh-key file path if need
# port: your ssh port, default 22
# timeout: ssh connection timeout (second), default 30
oceanbase-ce:
style: cluster
config:
devname: eth0
memory_limit: 64G
system_memory: 30G
datafile_disk_percentage: 20
syslog_level: INFO
enable_syslog_wf: false
enable_syslog_recycle: true
max_syslog_file_count: 4
skip_proxy_sys_private_check: true
enable_strict_kernel_release: false
mysql_port: 2881
rpc_port: 2882
home_path: /root/observer
root_password: ******
zones:
zone1:
idc: idc1
servers:
- name: server1
ip: xxx.xxx.xxx.xxx
zone2:
idc: idc2
servers:
- name: server2
ip: xxx.xxx.xxx.xxx
zone3:
idc: idc3
servers:
- name: server3
ip: xxx.xxx.xxx.xxx
Run the following command for the modification to take effect:
obd cluster reload <deploy name>
# Example
obd cluster reload test
For information about the obd cluster reload command, see obd cluster reload.
Configure the password
To use OCP to take over a cluster, you need to configure the password for the root user to connect to the cluster under the SYS tenant. Run the following command to enter the edit mode and use root_passwd to configure the password.
obd cluster edit-config <deploy name>
# Example
obd cluster edit-config test
Sample configuration file:
## Only need to configure when remote login is required
# user:
# username: your username
# password: your password if need
# key_file: your ssh-key file path if need
# port: your ssh port, default 22
# timeout: ssh connection timeout (second), default 30
oceanbase-ce:
servers:
- name: server1
# Please don't use hostname, only IP can be supported
ip: xxx.xxx.xxx.xxx
- name: server2
ip: xxx.xxx.xxx.xxx
- name: server3
ip: xxx.xxx.xxx.xxx
global:
# The working directory for OceanBase Database. OceanBase Database is started under this directory. This is a required field.
home_path: /root/observer
# External port for OceanBase Database. The default value is 2881. DO NOT change this value after the cluster is started.
mysql_port: 2881
# Internal port for OceanBase Database. The default value is 2882. DO NOT change this value after the cluster is started.
rpc_port: 2882
# The maximum running memory for an observer. When ignored, autodeploy calculates this value based on the current server available resource.
memory_limit: 64G
# The reserved system memory. system_memory is reserved for general tenants. The default value is 30G. Autodeploy calculates this value based on the current server available resource.
system_memory: 30G
# Password for root. The default value is empty.
root_password: ******
# Password for proxyro. proxyro_password must be the same as observer_sys_password. The default value is empty.
# proxyro_password:
server1:
zone: zone1
server2:
zone: zone2
server3:
zone: zone3
The preceding shows a sample configuration file of the default style. For a configuration file of the cluster style, see the configuration example in Configure IDC information.
Run the following command for the modification to take effect:
obd cluster reload <deploy name>
# Example
obd cluster reload test
Configure the user
OCP requires the process to be started by the admin user with the passwordless sudo permission. Therefore, you need to prepare an admin user as required. If this condition is already met, go to Change the user.
Create a user
On a server where OBServer is deployed, you can create the admin user as the root user.
# Create a user group
groupadd admin
# Create the admin user
useradd admin -g admin
Then, configure passwordless SSH logon for the admin user. For information about how to configure passwordless SSH logon, see Use SSH to log on without a password.
Note
- You need to configure passwordless SSH logon for the admin user.
- A private key needs to be configured here, that is,
id_rsa.
Grant the passwordless sudo permission to the admin user
Perform the following operations as the root user:
# Add the write permission on the sudoers file.
chmod u+w /etc/sudoers
# vi /etc/sudoers
echo 'admin ALL=(ALL) NOPASSWD: ALL' >> /etc/sudoers
# Revoke the write permission on the sudoers file.
chmod u-w /etc/sudoers
Change the user
Run the following command to enter the edit mode and modify the user field.
obd cluster edit-config <deploy name>
# Example
obd cluster edit-config test
Sample configuration after modification:
## Only need to configure when remote login is required
user:
username: admin
# password: your password if need
key_file: your ssh-key file path if need # Set it to the id_rsa file path of the admin user.
# port: your ssh port, default 22
# timeout: ssh connection timeout (second), default 30
Run the following command for the modification to take effect:
obd cluster restart <deploy name>
# Example
obd cluster restart test --wp
For information about the obd cluster restart command, see obd cluster restart.
Multiple OBServers on a single server
OCP requires that one server have only one OBServer installed. At present, the scenario with multiple OBServers running on a single server is not supported. To use OCP to take over a cluster with multiple OBServers running on a single server, you need to keep only one OBServer running and stop other OBServers.
Note
After all the preceding operations are completed, you can run the
obd cluster check4ocp <deploy name>command again to check whether takeover conditions are met. If not, you can make modifications based on prompts.
Use OCP to take over the cluster
Change the password of the proxyro user
Before you use OCP to take over a cluster, check whether the password of the proxyro user in the cluster is the default value. If not, change the password of the proxyro user in OCP to that of the proxyro user in the cluster.
- If you are using OCP V4.0.3 or later, change the password of the proxyro user by referring to Change the password of the proxyro user.
- If you are using OCP earlier than V4.0.3, change the password of the proxyro user by running the following command:
curl --user user:pass -X POST "http://ocp-site-url:port/api/v2/obproxy/password" -H "Content-Type:application/json" -d '{"username":"proxyro","password":"*****"}'
where
- `user:pass` specifies the username and password of OCP, and it is required that the calling user has admin privileges.
- The `password` following the `-d` parameter specifies the password of the proxyro user in the cluster to be taken over.
The operation of changing the password of the proxyro user will generate an operation and maintenance (O&M) task, which will not only change the password of the proxyro user for the existing OceanBase cluster in OCP but also update the corresponding configuration for the OBProxy cluster.
You must wait until the O&M task is successfully completed before performing the subsequent steps. If the task fails, you must retry it and ensure that the task is successfully executed before proceeding with the subsequent steps.
Use OCP to take over the OceanBase cluster
You can directly take over the OceanBase cluster on the GUI of OCP. For detailed steps, see Take over a cluster.
After using OCP to take over the OceanBase cluster, you need to create an OBProxy cluster and associate it with the OceanBase cluster that has been taken over. For detailed steps, see Create an OBProxy cluster.
If original OBProxies use a virtual IP address (VIP), add the OBProxies created in OCP to the VIP one by one, and then delete the original OBProxies from the VIP one by one.
FAQ
- Why do I need to change the password of the proxyro user in OCP?Typically, an OBProxy managed in OCP is started by ConfigServer and can theoretically connect to multiple OceanBase clusters. However, the password of the proxyro user can be changed only globally for OBProxies. This password is a global configuration in OCP. It is used by OBProxies to query metadata, and the change of it does not affect business tenants.
- When I switch to a new OBProxy, can I reuse the original server?If multiple OBProxies have been deployed and are accessed through a VIP, you can delete them from the VIP one by one, deploy new OBProxies in OCP by using the original servers, and add the new OBProxies back to the VIP, thereby reusing the servers.
- Can I choose not to switch to a new OBProxy?Yes, you can. The original OBProxy can still properly connect to the OceanBase cluster that has been taken over. However, we recommend that you create a new OBProxy in OCP to facilitate subsequent O&M management.