Deploy a Community Edition cluster by using an obd configuration file

This topic describes how to prepare resources and configure the environment before deployment and how to quickly deploy a Community Edition distributed cluster by using an obd configuration file.

Server configuration

The server configuration in this example is as follows:

Deployment mode

This example uses a three-replica deployment mode. We recommend that you use four servers, and you can choose a suitable deployment mode based on your actual situation. The usage of the four servers is as follows:

Check the server's hardware and software configurations

Before you deploy OceanBase Database, check the server's hardware and software configurations to ensure that the deployment can be completed.

Hardware

Check whether the CPU supports the AVX instruction

OceanBase Database requires that the CPU supports the AVX instruction. You can run the following command to check whether the CPU supports the AVX instruction.

lscpu | grep Flags | grep avx

The following example shows the command output. If the avx field is present in the output, the CPU supports the AVX instruction. If the avx field is not present, the CPU does not support the AVX instruction. In this case, you must use a server that supports the AVX instruction.

Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq monitor ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs_enhanced fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves avx_vnni avx512_bf16 wbnoinvd ida arat hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req avx512vbmi umip pku ospke waitpkg avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid bus_lock_detect cldemote movdiri movdir64b enqcmd fsrm md_clear serialize tsxldtrk avx512_fp16 flush_l1d arch_capabilities

Check the memory

Run the following command to check whether the available memory of the server meets the requirements specified in the Software and hardware requirements topic of the OceanBase Database documentation.

[root@test001 ~]# free -g

The following example shows the command output. The value of the Mem column in the available column is 32, which meets the memory requirements.

              total        used        free      shared  buff/cache   available
Mem:             36           4          32           0           0          32
Swap:             0           0           0

If the memory check result does not meet the memory requirements for deploying OceanBase Database, you can run the following command to clear the Linux cache: PageCache, dentries, and inodes.

sudo sysctl -w vm.drop_caches=3
# or
sudo echo 3 > /proc/sys/vm/drop_caches

Software

Check the operating system

Run the following command to check the operating system information. The operating system must meet the requirements specified in the Software and hardware requirements topic of the OceanBase Database documentation.

[root@test001 ~]# cat /etc/os-release

The following example shows the command output. The operating system is CentOS Linux (the value of the NAME field), and the version is 8 (the value of the VERSION field).

NAME="CentOS Linux"
VERSION="8"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="8"
PLATFORM_ID="platform:el8"
PRETTY_NAME="CentOS Linux 8"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:8"
HOME_URL="https://centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-8"
CENTOS_MANTISBT_PROJECT_VERSION="8"

Check the kernel

OceanBase Database provides installation packages for the x86 architecture (el7 and el8) and the ARM architecture (el7 and el8). Before deployment, check the kernel of the server to obtain the correct installation package.

Run the following command to check the kernel information:

[root@test001 ~]# uname -a

The following example shows the command output. The kernel is 4.18.0-348.7.1, the operating system version is el8, and the CPU architecture is x86_64. Therefore, you must use an installation package with the el8.x86_64 suffix, for example, oceanbase-ce-4.3.5.2-102020032025070315.el8.x86_64.rpm.

Linux test001 4.18.0-348.7.1.el8_5.x86_64 #1 SMP Wed Dec 22 13:25:12 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Pre-deployment configuration

Before you deploy OceanBase Database Community Edition, you must perform the following configurations.

Plan the directories

To deploy OceanBase Database Community Edition, you need to plan the following three directories. The file system type must be XFS or EXT4.

• Installation directory: the directory for storing the software of OceanBase Database and the system logs generated during the running of OceanBase Database. The size of the directory must be at least 25 GB.
• Log directory: the directory for storing the logs of OceanBase Database. The size of the directory must be at least twice the size of the memory. We recommend that you configure the size of the directory to be three times the size of the memory.
• Data directory: the directory for storing data. The size of the directory must be at least twice the size of the memory. The size of the directory depends on the size of the data to be stored.

To ensure the stability of the system, we recommend that you use different physical disks for the three directories. If physical resources are limited, OceanBase Database supports the use of the same physical disk for the data directory and the log directory. However, we do not recommend that you use this configuration for business scenarios with high write pressure.

The IOPS requirements for the disks are as follows:

• If the installation directory, log directory, and data directory are stored on different disks, the IOPS of each disk must be at least 1000.
• If the installation directory, log directory, and data directory are stored on the same disk, the IOPS of the disk must be at least 3000.

Mount disks

If your server does not have any disks that need to be mounted, or if all disks have been mounted, you can skip this step and proceed to the next step Prepare directories.

As the root user, perform the following steps to mount the disks:

1. View the disk information

   1. Use the fdisk -l command to identify the available disks and partitions.

      [root@test001 ~]# fdisk -l
      

      The output is as follows:

      Disk /dev/nvme0n1: 3.5 TiB, 3840755982336 bytes, 7501476528 sectors
      Units: sectors of 1 * 512 = 512 bytes
      Sector size (logical/physical): 512 bytes / 512 bytes
      I/O size (minimum/optimal): 4096 bytes / 4096 bytes
      
      Disk /dev/nvme1n1: 3.5 TiB, 3840755982336 bytes, 7501476528 sectors
      Units: sectors of 1 * 512 = 512 bytes
      Sector size (logical/physical): 512 bytes / 512 bytes
      I/O size (minimum/optimal): 4096 bytes / 4096 bytes
      
      Disk /dev/sda: 60 GiB, 64424509440 bytes, 125829120 sectors
      Units: sectors of 1 * 512 = 512 bytes
      Sector size (logical/physical): 512 bytes / 512 bytes
      I/O size (minimum/optimal): 512 bytes / 512 bytes
      Disklabel type: gpt
      Disk identifier: 3DC9B58D-90DC-4B90-869A-33592EA28B9E
      
      Device      Start       End   Sectors  Size Type
      /dev/sda1    2048      6143      4096    2M BIOS boot
      /dev/sda2    6144    415743    409600  200M EFI System
      /dev/sda3  415744 125829086 125413343 59.8G Linux filesystem
      
      
      Disk /dev/sdb: 200 GiB, 214748364800 bytes, 419430400 sectors
      Units: sectors of 1 * 512 = 512 bytes
      Sector size (logical/physical): 512 bytes / 512 bytes
      I/O size (minimum/optimal): 512 bytes / 512 bytes
      

   2. Use the lsblk command to view the disk information.

      [root@test001 ~]# lsblk
      

      The output is as follows:

      NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
      sda       8:0    0   60G  0 disk
      ├─sda1    8:1    0    2M  0 part
      ├─sda2    8:2    0  200M  0 part /boot/efi
      └─sda3    8:3    0 59.8G  0 part /
      sdb       8:16   0  200G  0 disk /home
      sr0      11:0    1    4M  0 rom
      nvme0n1 259:0    0  3.5T  0 disk
      nvme1n1 259:0    0  3.5T  0 disk
      

   Based on the above query, the disks to be mounted are /dev/nvme0n1 and /dev/nvme1n1.

2. Install the LVM tools

   [root@test001 ~]# yum install lvm2
   

3. Create physical volumes (PVs)

   1. Initialize the partitions as PVs.

      Notice

      When you initialize a partition as a PV, the partition will be reformatted (data will be lost). Proceed with caution.

      [root@test001 ~]# pvcreate /dev/nvme0n1
      [root@test001 ~]# pvcreate /dev/nvme1n1
      

      The output is as follows:

      Physical volume "/dev/nvme0n1" successfully created.
      Physical volume "/dev/nvme1n1" successfully created.
      

   2. Verify the PV creation result.

      [root@test001 ~]# pvs
      

      The output is as follows:

      PV           VG Fmt  Attr PSize PFree
      /dev/nvme0n1    lvm2 ---  3.49t 3.49t
      /dev/nvme1n1    lvm2 ---  3.49t 3.49t
      

4. Create volume groups (VGs)

   1. Merge multiple PVs into one VG.

      [root@test001 ~]# vgcreate vgob1 /dev/nvme0n1
      [root@test001 ~]# vgcreate vgob2 /dev/nvme1n1
      

      The output is as follows:

      Volume group "vgob1" successfully created
      Volume group "vgob2" successfully created
      

   2. View the VG information.

      [root@test001 ~]# vgs  
      

      The output is as follows:

      VG   #PV #LV #SN Attr   VSize VFree
      vgob1  1   0   0 wz--n- 3.49t 3.49t
      vgob2  1   0   0 wz--n- 3.49t 3.49t
      

5. Create logical volumes (LVs)

   1. Divide the VG into logical volumes.

      • Create a data logical volume.

        [root@test001 ~]# lvcreate -L 2t -n data vgob1
        

        The output is as follows:

        Logical volume "data" created.
        

      • Create a log logical volume.

        [root@test001 ~]# lvcreate -L 2t -n log vgob2
        

        The output is as follows:

        Logical volume "log" created.
        

   2. View the LV information.

      [root@test001 ~]# lvs
      

      The output is as follows:

      LV   VG    Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
      data vgob1 -wi-a----- 2.00t
      log  vgob2 -wi-a----- 2.00t
      

6. Format and mount the disks

   1. Format the disks as EXT4 file systems.

      • Format the data logical volume as an EXT4 file.

        [root@test001 ~]# mkfs.ext4 /dev/vgob1/data
        

        The output is as follows:

        mke2fs 1.46.0 (29-Jan-2020)
        Discarding device blocks: done
        Creating filesystem with 268435456 4k blocks and 67108864 inodes
        Filesystem UUID: eb4708c8-e3e3-49b4-9444-b9c81d4be84e
        Superblock backups stored on blocks:
              32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
              4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
              102400000, 214990848
        
        Allocating group tables: done
        Writing inode tables: done
        Creating journal (262144 blocks): done
        Writing superblocks and filesystem accounting information: done
        

      • Format the log logical volume as an EXT4 file.

        [root@test001 ~]# mkfs.ext4 /dev/vgob2/log
        

        The output is as follows:

        mke2fs 1.46.0 (29-Jan-2020)
        Discarding device blocks: done
        Creating filesystem with 536870912 4k blocks and 134217728 inodes
        Filesystem UUID: c48c39cd-bdb9-4635-9304-721dcf013492
        Superblock backups stored on blocks:
              32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
              4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
              102400000, 214990848, 512000000
        
        Allocating group tables: done
        Writing inode tables: done
        Creating journal (262144 blocks): done
        Writing superblocks and filesystem accounting information: done
        

   2. Create mount points.

      [root@test001 ~]# mkdir -p /data/log1
      [root@test001 ~]# mkdir -p /data/1
      

   3. Temporarily mount the disks.

      [root@test001 ~]# mount /dev/vgob2/log /data/log1
      [root@test001 ~]# mount /dev/vgob1/data /data/1
      

7. Set up automatic mounting at boot.

   Edit the /etc/fstab file and add the mount configuration.

   [root@test001 ~]# vim /etc/fstab
   

   Add the following content to the configuration file:

   /dev/vgob2/log /data/log1  ext4  defaults,noatime,nodiratime,nodelalloc,barrier=0  0  0
   /dev/vgob1/data /data/1  ext4  defaults,noatime,nodiratime,nodelalloc,barrier=0  0  0
   

8. View the disk mounting status.

   Use the following command to view the disk mounting status.

   [root@test001 ~]# df -h
   

   The output is as follows, indicating that the disks have been mounted to the directories /data/1 and /data/log1.

   Filesystem             Size  Used Avail Use% Mounted on
   devtmpfs               4.8G     0  4.8G   0% /dev
   tmpfs                  4.8G     0  4.8G   0% /dev/shm
   tmpfs                  4.8G  500K  4.8G   1% /run
   tmpfs                  4.8G     0  4.8G   0% /sys/fs/cgroup
   /dev/sda3               59G  4.8G   52G   9% /
   /dev/sda2              200M  5.8M  195M   3% /boot/efi
   /dev/sdb               196G  3.2G  183G   2% /home
   tmpfs                  970M     0  970M   0% /run/user/1001
   /dev/mapper/vgob1-data 2.0T   28K  1.9T   1% /data/1
   /dev/mapper/vgob2-log  2.0T   28K  1.9T   1% /data/log1
   

Prepare the directories

• Check the file system type, which is EXT4 or XFS.

  [root@test001 ~]# df -Th
  

  The returned result is as follows:

  Filesystem             Type      Size  Used Avail Use% Mounted on
  devtmpfs               devtmpfs  4.8G     0  4.8G   0% /dev
  tmpfs                  tmpfs     4.8G     0  4.8G   0% /dev/shm
  tmpfs                  tmpfs     4.8G  512K  4.8G   1% /run
  tmpfs                  tmpfs     4.8G     0  4.8G   0% /sys/fs/cgroup
  /dev/sda3              ext4       59G  5.0G   52G   9% /
  /dev/sdb               ext4      196G  113G   74G  61% /home
  /dev/sda2              vfat      200M  5.8M  195M   3% /boot/efi
  /dev/mapper/vgob2-log  ext4     2.0T  2.1G  1.9T   1% /data/log1
  /dev/mapper/vgob1-data ext4      2.0T  2.1G  1.9T   1% /data/1
  tmpfs                  tmpfs     970M     0  970M   0% /run/user/1001
  

  Based on the above directory check, when you deploy the service, set the installation directory to /home, the log storage directory to /data/log1, and the data storage directory to /data/1.

• Check whether the IOPS of the directory meets the requirements.

  Note

  • Since the installation directory, log storage directory, and data storage directory are located on different disks, you need to query the IOPS of each directory. If the installation directory, log storage directory, and data storage directory are located on the same disk, you only need to switch to the mount directory of the disk and query the IOPS.

  • If the fio tool is not installed on the server, run the yum install -y fio command to install it.

  • Query the IOPS of the installation directory.

    Switch to the installation directory and run the following command:

    [root@test001 /home]# fio -filename=./testfile -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=4k -size=20G -numjobs=1 -runtime=180 -group_reporting -name=sqe_100write_4k --fsync=1 --fallocate=posix
    

    The returned result is as follows:

    sqe_100write_4k: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
    fio-3.34
    Starting 1 thread
    Jobs: 1 (f=1): [W(1)][100.0%][w=6648KiB/s][w=1662 IOPS][eta 00m:00s]
    sqe_100write_4k: (groupid=0, jobs=1): err= 0: pid=145805: Thu May  8 10:39:32 2025
    write: IOPS=2012, BW=8051KiB/s (8244kB/s)(1415MiB/180001msec); 0 zone resets
       clat (usec): min=84, max=3732, avg=174.51, stdev=71.93
       lat (usec): min=84, max=3732, avg=174.77, stdev=71.98
       clat percentiles (usec):
       |  1.00th=[   89],  5.00th=[   90], 10.00th=[   91], 20.00th=[   95],
       | 30.00th=[  100], 40.00th=[  141], 50.00th=[  184], 60.00th=[  210],
       | 70.00th=[  221], 80.00th=[  231], 90.00th=[  265], 95.00th=[  285],
       | 99.00th=[  351], 99.50th=[  371], 99.90th=[  441], 99.95th=[  515],
       | 99.99th=[  824]
       bw (  KiB/s): min= 3432, max=17608, per=100.00%, avg=8056.18, stdev=4234.76, samples=359
       iops        : min=  858, max= 4402, avg=2014.04, stdev=1058.69, samples=359
    lat (usec)   : 100=30.58%, 250=57.09%, 500=12.28%, 750=0.04%, 1000=0.02%
    lat (msec)   : 2=0.01%, 4=0.01%
    fsync/fdatasync/sync_file_range:
       sync (usec): min=64, max=5690, avg=319.43, stdev=230.86
       sync percentiles (usec):
       |  1.00th=[   68],  5.00th=[   69], 10.00th=[   70], 20.00th=[   72],
       | 30.00th=[   95], 40.00th=[  194], 50.00th=[  379], 60.00th=[  412],
       | 70.00th=[  457], 80.00th=[  474], 90.00th=[  578], 95.00th=[  685],
       | 99.00th=[  996], 99.50th=[ 1205], 99.90th=[ 1336], 99.95th=[ 1385],
       | 99.99th=[ 1713]
    cpu          : usr=0.86%, sys=11.80%, ctx=714705, majf=0, minf=0
    IO depths    : 1=200.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
       submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
       complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
       issued rwts: total=0,362308,0,362308 short=0,0,0,0 dropped=0,0,0,0
       latency   : target=0, window=0, percentile=100.00%, depth=1
    
    Run status group 0 (all jobs):
    WRITE: bw=8051KiB/s (8244kB/s), 8051KiB/s-8051KiB/s (8244kB/s-8244kB/s), io=1415MiB (1484MB), run=180001-180001msec
    
    Disk stats (read/write):
    sdb: ios=0/935811, merge=0/335611, ticks=0/164939, in_queue=217509, util=99.97%
    

    After you complete the above operation, delete the testfile file in the directory to prevent the disk space from being insufficient.

    [root@test001 /home]# rm -rf testfile
    

  • Query the IOPS of the log storage directory.

    Switch to the log storage directory and run the following command:

    [root@test001 /data/log1]# fio -filename=./testfile -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=4k -size=20G -numjobs=1 -runtime=180 -group_reporting -name=sqe_100write_4k --fsync=1 --fallocate=posix
    

    The returned result is as follows:

    sqe_100write_4k: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
    fio-3.34
    Starting 1 thread
    Jobs: 1 (f=1): [W(1)][100.0%][w=6648KiB/s][w=1662 IOPS][eta 00m:00s]
    sqe_100write_4k: (groupid=0, jobs=1): err= 0: pid=145805: Thu May  8 10:39:32 2025
    write: IOPS=2012, BW=8051KiB/s (8244kB/s)(1415MiB/180001msec); 0 zone resets
       clat (usec): min=84, max=3732, avg=174.51, stdev=71.93
       lat (usec): min=84, max=3732, avg=174.77, stdev=71.98
       clat percentiles (usec):
       |  1.00th=[   89],  5.00th=[   90], 10.00th=[   91], 20.00th=[   95],
       | 30.00th=[  100], 40.00th=[  141], 50.00th=[  184], 60.00th=[  210],
       | 70.00th=[  221], 80.00th=[  231], 90.00th=[  265], 95.00th=[  285],
       | 99.00th=[  351], 99.50th=[  371], 99.90th=[  441], 99.95th=[  515],
       | 99.99th=[  824]
       bw (  KiB/s): min= 3432, max=17608, per=100.00%, avg=8056.18, stdev=4234.76, samples=359
       iops        : min=  858, max= 4402, avg=2014.04, stdev=1058.69, samples=359
    lat (usec)   : 100=30.58%, 250=57.09%, 500=12.28%, 750=0.04%, 1000=0.02%
    lat (msec)   : 2=0.01%, 4=0.01%
    fsync/fdatasync/sync_file_range:
       sync (usec): min=64, max=5690, avg=319.43, stdev=230.86
       sync percentiles (usec):
       |  1.00th=[   68],  5.00th=[   69], 10.00th=[   70], 20.00th=[   72],
       | 30.00th=[   95], 40.00th=[  194], 50.00th=[  379], 60.00th=[  412],
       | 70.00th=[  457], 80.00th=[  474], 90.00th=[  578], 95.00th=[  685],
       | 99.00th=[  996], 99.50th=[ 1205], 99.90th=[ 1336], 99.95th=[ 1385],
       | 99.99th=[ 1713]
    cpu          : usr=0.86%, sys=11.80%, ctx=714705, majf=0, minf=0
    IO depths    : 1=200.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
       submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
       complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
       issued rwts: total=0,362308,0,362308 short=0,0,0,0 dropped=0,0,0,0
       latency   : target=0, window=0, percentile=100.00%, depth=1
    
    Run status group 0 (all jobs):
    WRITE: bw=8051KiB/s (8244kB/s), 8051KiB/s-8051KiB/s (8244kB/s-8244kB/s), io=1415MiB (1484MB), run=180001-180001msec
    
    Disk stats (read/write):
    sdb: ios=0/935811, merge=0/335611, ticks=0/164939, in_queue=217509, util=99.97%
    

    After you complete the above operation, delete the testfile file in the directory to prevent the disk space from being insufficient.

    [root@test001 /data/log1]# rm -rf testfile
    

  • Query the IOPS of the data storage directory.

    Switch to the data storage directory and run the following command:

    [root@test001 /data/1]# fio -filename=./testfile -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=4k -size=20G -numjobs=1 -runtime=180 -group_reporting -name=sqe_100write_4k --fsync=1 --fallocate=posix
    

    The returned result is as follows:

    sqe_100write_4k: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
    fio-3.34
    Starting 1 thread
    Jobs: 1 (f=1): [W(1)][100.0%][w=6648KiB/s][w=1662 IOPS][eta 00m:00s]
    sqe_100write_4k: (groupid=0, jobs=1): err= 0: pid=145805: Thu May  8 10:39:32 2025
    write: IOPS=2012, BW=8051KiB/s (8244kB/s)(1415MiB/180001msec); 0 zone resets
       clat (usec): min=84, max=3732, avg=174.51, stdev=71.93
       lat (usec): min=84, max=3732, avg=174.77, stdev=71.98
       clat percentiles (usec):
       |  1.00th=[   89],  5.00th=[   90], 10.00th=[   91], 20.00th=[   95],
       | 30.00th=[  100], 40.00th=[  141], 50.00th=[  184], 60.00th=[  210],
       | 70.00th=[  221], 80.00th=[  231], 90.00th=[  265], 95.00th=[  285],
       | 99.00th=[  351], 99.50th=[  371], 99.90th=[  441], 99.95th=[  515],
       | 99.99th=[  824]
       bw (  KiB/s): min= 3432, max=17608, per=100.00%, avg=8056.18, stdev=4234.76, samples=359
       iops        : min=  858, max= 4402, avg=2014.04, stdev=1058.69, samples=359
    lat (usec)   : 100=30.58%, 250=57.09%, 500=12.28%, 750=0.04%, 1000=0.02%
    lat (msec)   : 2=0.01%, 4=0.01%
    fsync/fdatasync/sync_file_range:
       sync (usec): min=64, max=5690, avg=319.43, stdev=230.86
       sync percentiles (usec):
       |  1.00th=[   68],  5.00th=[   69], 10.00th=[   70], 20.00th=[   72],
       | 30.00th=[   95], 40.00th=[  194], 50.00th=[  379], 60.00th=[  412],
       | 70.00th=[  457], 80.00th=[  474], 90.00th=[  578], 95.00th=[  685],
       | 99.00th=[  996], 99.50th=[ 1205], 99.90th=[ 1336], 99.95th=[ 1385],
       | 99.99th=[ 1713]
    cpu          : usr=0.86%, sys=11.80%, ctx=714705, majf=0, minf=0
    IO depths    : 1=200.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
       submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
       complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
       issued rwts: total=0,362308,0,362308 short=0,0,0,0 dropped=0,0,0,0
       latency   : target=0, window=0, percentile=100.00%, depth=1
    
    Run status group 0 (all jobs):
    WRITE: bw=8051KiB/s (8244kB/s), 8051KiB/s-8051KiB/s (8244kB/s-8244kB/s), io=1415MiB (1484MB), run=180001-180001msec
    
    Disk stats (read/write):
    sdb: ios=0/935811, merge=0/335611, ticks=0/164939, in_queue=217509, util=99.97%
    

    After you complete the above operation, delete the testfile file in the directory to prevent the disk space from being insufficient.

    [root@test001 /data/1]# rm -rf testfile
    

  Based on the above query results, the IOPS of each disk meets the requirements.

Configure time synchronization

When you deploy a distributed OceanBase cluster, you must ensure that the time of all servers in the cluster is synchronized. Otherwise, the cluster cannot be started, and exceptions will occur when the service is running. The maximum allowed time deviation in an OceanBase cluster is 2 seconds. If the time deviation exceeds 2 seconds, no leader will be elected. After the time synchronization is restored, you can restart the OceanBase cluster to restore the normal operation.

1. Install the chrony service.

   [root@test001 ~]# yum -y install chrony
   

2. Configure the chrony file.

   [root@test001 ~]# vim /etc/chrony.conf
   

   Here is an example:

   # Use Alibaba NTP server
   # Public NTP
   # Alicloud NTP
   ##Use multiple NTP servers of Alibaba Cloud to synchronize time, which improves the reliability and fault tolerance of time synchronization.
   ##minpoll 4 specifies that the minimum synchronization interval between the NTP client and server is 16 seconds (when the time deviation is small).
   ##maxpoll 10 specifies that the maximum synchronization interval between the NTP client and server is 1024 seconds (when the time deviation is large).
   ##iburst specifies that four NTP packets are sent quickly (every 2 seconds) when the client connects to or reconnects with the server for the first time, which accelerates time synchronization and reduces the initial synchronization time deviation.
   server ntp.cloud.aliyuncs.com minpoll 4 maxpoll 10 iburst
   server ntp.aliyun.com minpoll 4 maxpoll 10 iburst
   server ntp1.aliyun.com minpoll 4 maxpoll 10 iburst
   server ntp1.cloud.aliyuncs.com minpoll 4 maxpoll 10 iburst
   server ntp10.cloud.aliyuncs.com minpoll 4 maxpoll 10 iburst
   server ntp11.cloud.aliyuncs.com minpoll 4 maxpoll 10 iburst
   server ntp12.cloud.aliyuncs.com minpoll 4 maxpoll 10 iburst
   server ntp2.aliyun.com minpoll 4 maxpoll 10 iburst
   server ntp2.cloud.aliyuncs.com minpoll 4 maxpoll 10 iburst
   server ntp3.aliyun.com minpoll 4 maxpoll 10 iburst
   server ntp3.cloud.aliyuncs.com minpoll 4 maxpoll 10 iburst
   server ntp4.aliyun.com minpoll 4 maxpoll 10 iburst
   server ntp4.cloud.aliyuncs.com minpoll 4 maxpoll 10 iburst
   server ntp5.aliyun.com minpoll 4 maxpoll 10 iburst
   server ntp5.cloud.aliyuncs.com minpoll 4 maxpoll 10 iburst
   server ntp6.aliyun.com minpoll 4 maxpoll 10 iburst
   server ntp6.cloud.aliyuncs.com minpoll 4 maxpoll 10 iburst
   server ntp7.cloud.aliyuncs.com minpoll 4 maxpoll 10 iburst
   server ntp8.cloud.aliyuncs.com minpoll 4 maxpoll 10 iburst
   server ntp9.cloud.aliyuncs.com minpoll 4 maxpoll 10 iburst
   
   # Ignore stratum in source selection.
   stratumweight 0.05
   
   # Record the rate at which the system clock gains/losses time.
   ##Calculate the rate at which the server gains or loses time based on the actual time and record it to /var/lib/chrony/drift. After the system is restarted, the system makes the best time compensation adjustment.
   driftfile /var/lib/chrony/drift
   
   # Enable kernel RTC synchronization.
   ##Enable a kernel mode in which the system time is copied to the real-time clock (RTC) every 11 minutes.
   rtcsync
   
   # In the first three updates, the system clock is set instead of slew
   # if the adjustment is larger than 10 seconds.
   makestep 10 3
   
   # Allow NTP client access from local network.
   #allow 192.168/16
   
   # Listen for commands only on localhost.
   bindcmdaddress 127.0.0.1
   bindcmdaddress ::1
   
   # Disable logging of client accesses.
   noclientlog
   
   # Send a message to syslog if a clock adjustment is larger than 0.5 seconds.
   logchange 0.5
   
   ##Specify the directory of the log file.
   logdir /var/log/chrony
   #log measurements statistics tracking
   

3. Start the chronyd service.

   Set the service to start automatically:

   [root@test001 ~]# systemctl enable chronyd
   

   Start the chronyd service:

   [root@test001 ~]# systemctl start chronyd
   

4. Force synchronization of time

   You must execute the following command after the initial configuration.

   [root@test001 ~]# chronyc makestep
   

5. View the time tracking status

   [root@test001 ~]# chronyc tracking
   

   The following example shows the return result. You must pay attention to the Last offset (the time deviation of the last synchronization) and RMS offset (the root mean square of the average time deviation) fields. You can compare the values of these fields in the execution results of each server to determine the time deviation of each server.

   Reference ID    : 64643D58 (xx.xx.xx.xx)
   Stratum         : 2
   Ref time (UTC)  : Fri Jul 18 09:44:59 2025
   System time     : 0.000022816 seconds fast of NTP time
   Last offset     : -0.000012218 seconds
   RMS offset      : 0.000051287 seconds
   Frequency       : 6.951 ppm slow
   Residual freq   : -0.000 ppm
   Skew            : 0.010 ppm
   Root delay      : 0.000890165 seconds
   Root dispersion : 0.011471443 seconds
   Update interval : 1041.4 seconds
   Leap status     : Normal
   

User and parameter configuration

Before deployment, you also need to configure the following items:

• Create a user

  Note

  It is not recommended to deploy OceanBase Database as the root user. We recommend that you create another user for deployment. We recommend that you use the admin user. The user must be the owner of the directories related to the database.

• Configure limits.conf

• Configure sysctl.conf

• Disable the firewall and SELinux

obd supports using the host commands to initialize the host and the corresponding user. You can choose to configure the preceding items by using the obd commands or manually. We recommend that you configure the preceding items by using the obd commands.

[admin@test001 ~]# sudo vim /etc/sysctl.conf

# for oceanbase

## Modify the kernel's asynchronous I/O limit

fs.aio-max-nr = 1048576

## Optimize the network

net.core.somaxconn = 2048
net.core.netdev_max_backlog = 10000
net.core.rmem_default = 16777216
net.core.wmem_default = 16777216
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_slow_start_after_idle=0

vm.swappiness = 0
vm.min_free_kbytes = 2097152
vm.overcommit_memory = 0

fs.file-max = 6573688
fs.pipe-user-pages-soft = 0

# Modify the number of virtual memory areas that can be allocated to a process

vm.max_map_count = 655360

# Set the file name format and directory for core files

kernel.core_pattern = /data/core-%e-%p-%t

[admin@test001 ~]# sudo sysctl -p

Configure password-free SSH login

As the admin user, configure password-free SSH login from the host where obd is located (the control node) to the local host and to each component node.

1. Check whether the key exists on the control node.

   [admin@test001 ~]# ls ~/.ssh/id_rsa.pub
   

2. (Optional) Generate an SSH public key and private key

   If no key exists on the host where obd is located, run the following command to generate an SSH public key and private key. Press the keyboard Enter key to use the default values.

   [admin@test001 ~]# ssh-keygen -t rsa
   

3. Copy the public key to the authorized_keys file on the OBServer node host.

   [admin@test001 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub admin@10.10.10.1
   

   You need to copy the public key to the control node host and to the host of each cluster node. In this example, the public key is copied to the 10.10.10.1 host.

Configure load balancing

Starting from V3.3.0, obd supports configuring load balancing (VIP/DNS) when deploying ODP through the graphical interface. If you plan to deploy multiple ODP nodes, you can configure load balancing for ODP as described in this section.

F5 BIG-IP Local Traffic Manager (LTM) is an application traffic management system that allows you to connect multiple ODP nodes to F5 to achieve load balancing for ODP. Follow the steps below to use LTM's Layer 4 functionality to configure the port for ODP's external service.

1. Log in to F5 BIG-IP by entering the username and password. The default username and password are admin/admin.

   

2. Create Pools :

   1. Click Local Traffic>Monitors and add a Monitor of the TCP Half Open type.

      

   2. Click Local Traffic>Pools and click + to create a new Pool.

      

   3. In the Available list, select the Monitor created in step a and add it to the Active list.

      

   4. Scroll down and click New Node. Enter the IP address and port of the ODP server in the Address and Service Port fields, respectively.

   5. Click Add to add multiple nodes. After you add all the nodes, click Finished.

      

   6. On the Local Traffic>Pools>Pool List page, check whether the Status column of each Member is green. If so, the nodes are added successfully.

      

3. Click Local Traffic>Profiles>FastL4 and add a new Profile. Set the Type to Performance(Layer 4) for the Layer 4 mode. Do not enable session persistence. Set Idle Timeout to a value greater than or equal to 1800 seconds.

   

4. Click Local Traffic>Virtual Servers and add a new Server.

   

   1. Enter the following information.

      Parameter	Description
      Type	Performance(Layer 4)
      Source Address	0.0.0.0/0
      Destination Address/Mask	F5 VIP or Self IP, for example, 10.10.10.5
      Service Port	Port, which is customer-defined.
      Protocol Profile(Client)	The profile added in step 3.

   2. In the drop-down list, select Auto Map for Source Address Translation.

      

   3. In the Default Pool drop-down list, select the pool created in step 2.

      

   4. Click Finished.

   5. On the Local Traffic>Virtual Servers page, check whether the icon in the Status column of the Virtual Server List tab is green. If so, the virtual server is created.

      

5. After the cluster is created, select a host that is connected to the network of F5 and ODP. Run the telnet 10.10.10.1 2883 and telnet 10.10.10.5 3306 commands. If the following content is returned, ODP is successfully connected to F5.

   Connected to xx.xx.x.xxx.Escape character is '^]'.
   

Deploy the cluster by using the obd configuration file

1. (Optional) Install obd.

   Note

   If the user and parameter configuration section is configured manually, you must install obd by following this step.

   Run the following command to install obd online. You can also download the obd package from OceanBase Download Center and install it from the package. For more information about how to install obd, see Install obd.

   Install yum-utils:

   [admin@test001 ~]$ sudo yum install -y yum-utils
   

   Add the OceanBase image source:

   [admin@test001 ~]$ sudo yum-config-manager --add-repo https://mirrors.aliyun.com/oceanbase/OceanBase.repo
   

   Install obd. By default, the latest version is installed:

   [admin@test001 ~]$ sudo yum install -y ob-deploy
   

   Configure the application environment:

   [admin@test001 ~]$ source /etc/profile.d/obd.sh
   

   Note

   If you want to deploy OceanBase Database Enterprise Edition, contact Technical Support to obtain the installation package and run the obd mirror clone command to upload it to the local image library of obd. After the package is uploaded, you can run the obd mirror list local command to view the installation packages in the local image library.

2. Create a configuration file.

   [admin@test001 ~]$ vim obtest.yaml
   

   Enter the following content in the configuration file:

   user:
     username: admin
     # password: ********
     key_file: /home/admin/.ssh/id_rsa
   oceanbase-ce:
     # version: 4.3.4.2
     # package_hash: 0778757f3625ec77948e28c741829d60ea89e29b3292986dd087350955306669
     servers:
       - name: server1
         # Please don't use hostname, only IP can be supported
         ip: 10.10.10.1
       - name: server2
         ip: 10.10.10.2
       - name: server3
         ip: 10.10.10.3
     global:
       memory_limit: 32G # The maximum running memory for an observer
       system_memory: 10G
       datafile_size: 200G # Size of the data file. 
       datafile_next: 200G # the auto extend step. Please enter an capacity, such as 2G
       datafile_maxsize: 1T # the auto extend max size. Please enter an capacity, such as 20G
       log_disk_size: 1T # The size of disk space used by the clog files.
       scenario: htap
       production_mode: true
       enable_syslog_wf: false # Print system logs whose levels are higher than WARNING to a separate log file. The default value is true.
       max_syslog_file_count: 16 # The maximum number of reserved log files before enabling auto recycling. The default value is 0.
       enable_auto_start: true
       install_utils: true
       root_password: ****** # root user password
       proxyro_password: ****** # proxyro user password, consistent with obproxy's observer_sys_password, can be empty
     server1:
       mysql_port: 2881 # External port for OceanBase Database. The default value is 2881. DO NOT change this value after the cluster is started.
       rpc_port: 2882 # Internal port for OceanBase Database. The default value is 2882. DO NOT change this value after the cluster is started.
       obshell_port: 2886 # Operation and maintenance port for OceanBase Database.
       # The working directory for OceanBase Database. OceanBase Database is started under this directory. This is a required field.
       home_path: /home/admin/obtest/observer
       # The directory for data storage. The default value is $home_path/store.
       data_dir: /data/1/obtest
       # The directory for clog, ilog, and slog. The default value is the same as the data_dir value.
       redo_dir: /data/log1/obtest
       zone: zone1
     server2:
       mysql_port: 2881 # External port for OceanBase Database. The default value is 2881. DO NOT change this value after the cluster is started.
       rpc_port: 2882 # Internal port for OceanBase Database. The default value is 2882. DO NOT change this value after the cluster is started.
       #  The working directory for OceanBase Database. OceanBase Database is started under this directory. This is a required field.
       home_path: /home/admin/obtest/observer
       # The directory for data storage. The default value is $home_path/store.
       data_dir: /data/1/obtest
       # The directory for clog, ilog, and slog. The default value is the same as the data_dir value.
       redo_dir: /data/log1/obtest
       zone: zone2
     server3:
       mysql_port: 2881 # External port for OceanBase Database. The default value is 2881. DO NOT change this value after the cluster is started.
       rpc_port: 2882 # Internal port for OceanBase Database. The default value is 2882. DO NOT change this value after the cluster is started.
       #  The working directory for OceanBase Database. OceanBase Database is started under this directory. This is a required field.
       home_path: /home/admin/obtest/observer
       # The directory for data storage. The default value is $home_path/store.
       data_dir: /data/1/obtest
       # The directory for clog, ilog, and slog. The default value is the same as the data_dir value.
       redo_dir: /data/log1/obtest
       zone: zone3
   obproxy-ce:
     # version: 4.3.4.0
     # package_hash: 5c5dca3a355cc7286146ed978ebb26a6342e42e02cd3ca8b9739d300519a449f
     depends:
       - oceanbase-ce
     servers:
       - name: server1
         # Please don't use hostname, only IP can be supported
         ip: 10.10.10.1
       - name: server2
         ip: 10.10.10.2
       - name: server3
         ip: 10.10.10.3
     global:
       prometheus_listen_port: 2884
       listen_port: 2883
       rpc_listen_port: 2885
       # vip_address: "10.10.10.5"
       # vip_port: 3306
       enable_obproxy_rpc_service: true
       home_path: /home/admin/obtest/obproxy
       obproxy_sys_password: ********
       observer_sys_password: ********
       skip_proxy_sys_private_check: true
       enable_strict_kernel_release: false
       enable_cluster_checkout: false
       proxy_id: 822
       client_session_id_version: 2
   obagent:
     depends:
       - oceanbase-ce
     # The list of servers to be monitored. This list is consistent with the servers in oceanbase-ce.
     servers:
       - name: server1
         ip: 10.10.10.1
       - name: server2
         ip: 10.10.10.2
       - name: server3
         ip: 10.10.10.3
     global:
       monagent_http_port: 8088
       mgragent_http_port: 8089
       home_path: /home/admin/obagent
       http_basic_auth_password: ********
   prometheus:
     servers:
       - 10.10.10.4
     depends:
       - obagent
     global:
       port: 9090
       # The working directory for prometheus. prometheus is started under this directory. This is a required field.
       home_path: /home/admin/prometheus
       basic_auth_users: #<username>: <password>, the key is the user name and the value is the password.
         admin: ********
   grafana:
     servers:
       - 10.10.10.4
     depends:
       - prometheus
     global:
       port: 3000
       login_password: ********
       home_path: /home/admin/grafana
   

   During the deployment, pay attention to the following configurations:

   Module	Parameter	Required	Default value	Description
   General	version	Optional	The latest version in the image library.	If you want to deploy a specific version of the component, you can specify the component version through this parameter.
   	package_hash	Optional	The latest version in the image library.	If you want to deploy a specific component installation package, you can specify the hash of the component installation package through this parameter.
   	depends	Optional	N/A	Specify the dependencies of the component. If the component has dependencies, this parameter is required.
   	servers	Required	N/A	For each server, specify - name: server name (press Enter) ip: server IP address. If you specify multiple servers, specify this parameter multiple times. Server names must be unique. If server IP addresses are unique, you can also specify - <ip> (press Enter) - <ip>. In this case, - <ip> is equivalent to - name: server IP address (press Enter) ip: server IP address. Notice If you plan to deploy the obagent component, the servers parameter under the obagent component must be consistent with those of OceanBase Database.
   	home	Required	N/A	Specify the installation path of each component.
   user	username	Required	N/A	Specify the username for deployment. The obd tool uses this username to deploy the component on the planned OBServer node. Make sure that the username exists on the OBServer node and has execution and read/write permissions on all directories specified in the configuration file.
   	password	Optional	N/A	password and key_file are both used to verify the user. Only one of them can be specified. If you specify password, make sure that the password of the corresponding user on the planned OBServer node is the same as the specified one.
   	key_file	Optional	N/A	password and key_file are both used to verify the user. Only one of them can be specified. If you specify key_file, make sure that the SSH password-free login from the central control server to the corresponding user on the OBServer node is configured.
   oceanbase-ce	memory_limit	Optional	0	Specify the maximum memory that the observer process can obtain from the environment. If this parameter is not specified, the value of the memory_limit_percentage parameter is used. For more information, see memory_limit and memory_limit_percentage.
   	system_memory	Optional	0M	Specify the reserved memory capacity for the system. The reserved memory cannot be allocated to ordinary tenants. The value of this parameter occupies the memory specified by memory_limit. If this parameter is not specified, OceanBase Database automatically adapts to the system.
   	datafile_size	Optional	0	Specify the size of the data file (block_file) of the corresponding node. If this parameter is not specified, the value of the datafile_disk_percentage parameter is used. For more information, see datafile_size and datafile_disk_percentage. Note OceanBase Database supports automatic expansion of disk data files. To use this feature, you must set datafile_next (the expansion step) and datafile_maxsize (the maximum space for expansion). For more information, see Configure dynamic expansion of disk data files.
   	log_disk_size	Optional	0	Specify the size of the Redo log disk, that is, the total space available for the OBServer node. If this parameter is not specified, the value of the log_disk_percentage parameter is used. For more information, see log_disk_size and log_disk_percentage.
   	production_mode	Required	true	Specify whether to set the cluster to production mode. The default value is true, indicating that the cluster is in production mode. If you set this parameter to true, the value of memory_limit must be at least 16G, and the value of __min_full_resource_pool_memory (the minimum memory limit for resource pools) must be at least 2147483648. If the resources of the server cannot meet the requirements, set this parameter to false.
   	enable_auto_start	Optional	0	Specify whether to enable the auto-start feature of the observer process. If you set this parameter to true, the observer process is automatically started when the OBServer node restarts. Note To enable the auto-start feature of the observer process, make sure that the deployment user has sudo privileges.
   	install_utils	Optional	false	Specify whether to install the oceanbase-ce-utils package. After you install the oceanbase-ce-utils package, you can view the directories of OceanBase Utils (such as ob_admin, ob_error, and oblogminer) in the bin directory of the installation directory of OceanBase Database. If you set this parameter to true, you cannot modify it to false by using the obd cluster edit-config command. In other words, you cannot uninstall the oceanbase-ce-utils package by using the obd command.
   	root_password	Optional	A random string	The password of the super administrator (root@sys) of the OceanBase cluster. We recommend that you set a complex password. If you deploy OceanBase Database by using obd V2.1.0 or later, a random string is automatically generated if this parameter is not specified. After the deployment is completed, you can run the obd cluster edit-config command to view the corresponding parameter in the configuration file and obtain the password.
   	proxyro_password	Optional	A random string	The password of the account (proxyro@sys) used to connect to the OceanBase cluster by using ODP. After you specify this parameter, a proxyro user is created in the sys tenant of OceanBase Database. If you deploy OceanBase Database by using obd V2.1.0 or later, a random string is automatically generated if this parameter is not specified. After the deployment is completed, you can run the obd cluster edit-config command to view the corresponding parameter in the configuration file and obtain the password.
   	mysql_port	Required	2881	Specify the port number of the SQL service protocol. The value ranges from [1025, 65535]. The default value is 2881. If you want each OBServer node to use the same port, you can directly specify this parameter in the global module. Otherwise, you can specify this parameter separately for each OBServer node, as shown in the example in this topic.
   	rpc_port	Required	2882	Specify the port number of the remote access protocol. This is the RPC communication port between the observer process and the processes of other nodes. The value ranges from [1025, 65535]. The default value is 2882. If you want each OBServer node to use the same port, you can directly specify this parameter in the global module. Otherwise, you can specify this parameter separately for each OBServer node, as shown in the example in this topic.
   	obshell_port	Required	2886	Specify the port number of the OceanBase Database O&M service. The value ranges from [1025, 65535]. The default value is 2886. If you want each OBServer node to use the same port, you can directly specify this parameter in the global module. Otherwise, you can specify this parameter separately for each OBServer node, as shown in the example in this topic.
   	data_dir	Optional	$home_path/store	Specify the directory for storing data such as SSTables. We recommend that you configure an independent disk for this parameter and make sure that the deployment user has execution and read/write permissions on the directory. If you want each OBServer node to use the same directory, you can directly specify this parameter in the global module. Otherwise, you can specify this parameter separately for each OBServer node, as shown in the example in this topic.
   	redo_dir	Optional	The same as data_dir by default	Specify the directory for storing clogs. We recommend that you configure an independent disk for this parameter and make sure that the deployment user has execution and read/write permissions on the directory. If you want each OBServer node to use the same directory, you can directly specify this parameter in the global module. Otherwise, you can specify this parameter separately for each OBServer node, as shown in the example in this topic.
   obproxy-ce	listen_port	Required	2883	Specify the listening port of ODP. The value ranges from [1025, 65535]. The default value is 2883.
   	prometheus_listen_port	Required	2884	Specify the listening port of ODP for Prometheus. The value ranges from [1025, 65535]. The default value is 2884.
   	rpc_listen_port	Required	2885	Specify the listening port of the RPC service of ODP. The value ranges from [1025, 65535]. The default value is 2885. Note This parameter takes effect only when you deploy ODP V4.3.0 or later and set enable_obproxy_rpc_service to true.
   	vip_address	Optional	N/A	If you deploy multiple ODP nodes, you can specify the IP address of the VIP through this parameter. Notice obd does not support load balancing. If you want to set up load balancing, deploy and configure the corresponding load balancer in advance.
   	vip_port	Optional	N/A	If you deploy multiple ODP nodes, you can specify the access port of the VIP through this parameter. Notice obd does not support load balancing. If you want to set up load balancing, deploy and configure the corresponding load balancer in advance.
   	enable_obproxy_rpc_service	Optional	true	Specify whether to enable the RPC service of ODP. The default value is true, indicating that the RPC service is enabled. Note This parameter takes effect only when you deploy ODP V4.3.0 or later. If you do not specify this parameter, the default value of this parameter is set to false after ODP is upgraded.
   	obproxy_sys_password	Optional	A random string	The password of the ODP administrator account (root@proxysys). If you deploy OceanBase Database by using obd V2.1.0 or later, a random string is automatically generated if this parameter is not specified. After the deployment is completed, you can run the obd cluster edit-config command to view the corresponding parameter in the configuration file and obtain the password.
   	observer_sys_password	Optional	When OceanBase Database is deployed together with ODP, the default value is the same as that of proxyro_password. When ODP is deployed separately, the default value is a random string.	The password of the account (proxyro@sys) used to connect to the OceanBase cluster by using ODP. The password must be the same as the value of proxyro_password in OceanBase Database. If the password is different from that of proxyro_password, ODP cannot connect to OceanBase Database after the cluster is deployed.
   	proxy_id	Optional	0	Specify the ID of ODP to ensure that the Client Session IDs generated by different ODPs do not conflict. If multiple ODPs connect to the same OceanBase cluster, the proxy_id parameters of different ODPs cannot be set to the same value. If the value of the client_session_id_version parameter is 1, the value of this parameter ranges from [0,255]. If the value of the client_session_id_version parameter is 2, the value of this parameter ranges from [0,8191].
   	client_session_id_version	Optional	2	Specify whether to use the new Client Session ID generation logic. The value can be set to 1 or 2. If you set this parameter to 2, the new Client Session ID generation logic is used.

3. Deploy an OceanBase cluster

   obd cluster deploy obtest -c obtest.yaml
   

4. Start the OceanBase cluster

   obd cluster start obtest
   

   After the cluster is started, the information of each component in the cluster is output. Here is an example:

   Connect to observer 10.10.10.1:2881 ok
   Wait for observer init ok
   +------------------------------------------------+
   |                  oceanbase-ce                  |
   +--------------+---------+------+-------+--------+
   | ip           | version | port | zone  | status |
   +--------------+---------+------+-------+--------+
   | 10.10.10.1   | 4.3.5.2 | 2881 | zone1 | ACTIVE |
   | 10.10.10.2   | 4.3.5.2 | 2881 | zone2 | ACTIVE |
   | 10.10.10.3   | 4.3.5.2 | 2881 | zone3 | ACTIVE |
   +--------------+---------+------+-------+--------+
   obclient -h10.10.10.1 -P2881 -uroot@sys -p'********' -Doceanbase -A
   
   cluster unique id: 5a2629da-50e6-5b61-b326-113b4874dc12-1981c9dd30d-02050304
   
   Connect to obproxy ok
   +------------------------------------------------------------------+
   |                            obproxy-ce                            |
   +--------------+------+-----------------+-----------------+--------+
   | ip           | port | prometheus_port | rpc_listen_port | status |
   +--------------+------+-----------------+-----------------+--------+
   | 10.10.10.1   | 2883 | 2884            | 2885            | active |
   | 10.10.10.2   | 2883 | 2884            | 2885            | active |
   | 10.10.10.3   | 2883 | 2884            | 2885            | active |
   +--------------+------+-----------------+-----------------+--------+
   obclient -h10.10.10.1 -P2883 -uroot@proxysys -p'********' -Doceanbase -A
   
   Connect to Obagent ok
   +-----------------------------------------------------------------+
   |                             obagent                             |
   +--------------+--------------------+--------------------+--------+
   | ip           | mgragent_http_port | monagent_http_port | status |
   +--------------+--------------------+--------------------+--------+
   | 10.10.10.1   | 8089               | 8088               | active |
   | 10.10.10.2   | 8089               | 8088               | active |
   | 10.10.10.3   | 8089               | 8088               | active |
   +--------------+--------------------+--------------------+--------+
   Connect to Prometheus ok
   +----------------------------------------------------------+
   |                        prometheus                        |
   +--------------------------+-------+--------------+--------+
   | url                      | user  | password     | status |
   +--------------------------+-------+--------------+--------+
   | http://10.10.10.4:9090   | admin | '********'   | active |
   +--------------------------+-------+--------------+--------+
   Connect to grafana ok
   +----------------------------------------------------------------------+
   |                               grafana                                |
   +--------------------------------------+-------+--------------+--------+
   | url                                  | user  | password     | status |
   +--------------------------------------+-------+--------------+--------+
   | http://10.10.10.4:3000/d/oceanbase   | admin | '********'   | active |
   +--------------------------------------+-------+--------------+--------+
   obtest running
   Trace ID: d9d62110-63af-11f0-948d-00163e1c7562
   If you want to view detailed obd logs, please run: obd display-trace d9d62110-63af-11f0-948d-00163e1c7562
   

5. Verify the deployment result

   Connect to the OceanBase cluster by using the connection string in the output result:

   obclient -h10.10.10.1 -P2881 -uroot@sys -p'********' -Doceanbase -A
   

   If the following result is returned, it indicates that the OceanBase cluster is connected normally, and the deployment is completed.

   Welcome to the OceanBase.  Commands end with ; or \g.
   Your OceanBase connection id is 3221544680
   Server version: OceanBase_CE 4.3.5.2 (r102020032025070315-563ee271f78ff8521c8e0e09ae682065b065a046) (Built Jul  3 2025 15:53:52)
   
   Copyright (c) 2000, 2018, OceanBase and/or its affiliates. All rights reserved.
   
   Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
   
   obclient(root@sys)[oceanbase]>
   

References

• For more information about the configuration file, see Configuration file description.

• For more information about how to connect to OceanBase Database, see the Connect to OceanBase Database chapter.