Use OCP to take over a cluster deployed by OBD

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

1. You need to configure passwordless SSH logon for the admin user.

2. 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 using OCP to take over the 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.

You can call an OCP API to change the password.

curl --user user:pass -X POST "http://ocp-site-url:port/api/v2/obproxy/password" -H "Content-Type:application/json" -d '{"username":"proxyro","password":"*****"}'

Note:

• user:pass represents the username and password of OCP. The caller must have the admin permissions.

• password after -d represents the password of the proxyro user in the cluster to be taken over.

This operation produces an O&M task to change the password of the proxyro user in the existing OceanBase cluster in OCP, as well as the corresponding configuration of the OBProxy cluster.

You can proceed with subsequent steps only after the O&M task succeeds. If the task fails, you need to try it again and ensure that it is successful so that you can execute 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

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

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

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