What are the system requirements for installing an OceanBase Server?
The server must meet the following minimum configuration requirements.
| Server type | Number | Minimum functional configuration | Minimum performance configuration |
|---|---|---|---|
| OCP management server | 1 | 16C, 32G, 1.5TB storage | 32C, 128G, 1.5TB SSD storage, 10Gbps NIC |
| OceanBase Database computing server | 3 | 4C, 16G,
NoteThe log disk must be at least three times the size of the memory, and the data disk must be able to store the target data volume. |
32C, 256G,
NoteThe log disk must be at least three times the size of the memory, and the data disk must be able to store the target data volume. |
If you need the OCP management service to provide high availability, you need 3 management servers and load balancing software or hardware, such as F5, Alibaba Cloud SLB, or the ob_dns soft load balancing component provided by OceanBase Database, for three-node deployment.
OceanBase Database can be installed on the Linux operating systems listed in the following table.
| Linux operating system | Version | Server architecture |
|---|---|---|
| Rocky Linux | 9 | x86_64 (including Hygon), ARM_64 (Kunpeng, Phytium) |
| Alibaba Cloud Linux | 2, 3 | x86_64 (including Hygon), ARM_64 (Kunpeng, Phytium) |
| Anolis OS | 8 | x86_64 (including Hygon), ARM_64 (Kunpeng, Phytium) |
| Kylin OS | V10, V11 | x86_64 (including Hygon), ARM_64 (Kunpeng, Phytium) |
| UOS | V20 | x86_64 (including Hygon), ARM_64 (Kunpeng, Phytium) |
| NFSChina | 4.0 | x86_64 (including Hygon), ARM_64 (Kunpeng, Phytium) |
| Inspur KOS | 5.8 | x86_64 (including Hygon), ARM_64 (Kunpeng, Phytium) |
| CentOS / Red Hat Enterprise Linux | 7, 8, 9 | x86_64 (including Hygon), ARM_64 (Kunpeng, Phytium) |
| SUSE Enterprise Linux | 12SP5 | x86_64 (including Hygon) |
| Debian | 12 | x86_64 (including Hygon) |
| openEuler | 20.03 LTS, 22.03 LTS | x86_64 (including Hygon), ARM_64 (Kunpeng, Phytium) |
| NeoKylin Linux | V6.0.99, V6.0.100 | x86_64 (including Hygon), ARM_64 (Kunpeng, Phytium) |
| Ubuntu | 22.04 LTS, 24.04 LTS | x86_64 (including Hygon) |
Note
The operating system must be configured with a network and a software manager (yum or zypper source).
How is OceanBase Database deployed in a production environment?
The deployment options are as follows:
| Option | Features | Infrastructure requirements | Scenarios |
|---|---|---|---|
| 3 replicas in a single IDC | RPO=0, RTO is low, and automatic failover is supported. It can withstand individual hardware failures but cannot withstand IDC-level or city-level disasters. | A single IDC | No requirements for IDC-level or city-level disaster recovery. |
| 3 replicas across 3 IDCs in the same city | RPO=0, RTO is low, and automatic failover is supported. It can withstand individual hardware failures and IDC-level disasters but cannot withstand city-level disasters. | 3 IDCs in the same city with low network latency between them. | IDC-level disaster recovery is required, but city-level disaster recovery is not. |
| 5 replicas across 5 IDCs in 3 cities | RPO=0, RTO is low, and automatic failover is supported. It can withstand individual hardware failures, IDC-level disasters, and city-level disasters. | 5 IDCs across 3 cities, with 2 cities having low network latency. | IDC-level and city-level disaster recovery are required. |
| 2 IDCs in the same city, with data replication between clusters | RPO>0, RTO is high, and manual failover is required. It can withstand individual hardware failures and IDC-level disasters but cannot withstand city-level disasters. | 2 IDCs in the same city. | 2 IDCs in the same city, with IDC-level disaster recovery required. |
| 3 IDCs across 2 cities, with 5 replicas and data replication between clusters | For IDC-level failures: RPO=0, RTO is low, and automatic failover is supported. For city-level failures: RPO>0, RTO is high, and manual failover is required. It can withstand individual hardware failures, IDC-level disasters, and city-level disasters. | 3 IDCs across 2 cities. | 2 cities with 3 IDCs each, with IDC-level and city-level disaster recovery required. |
What is LSE?
LSE is a feature introduced in ARMv8.1, which stands for "Large System Extensions" (Large System Extensions). LSE provides a set of atomic operations to support synchronization and mutual exclusion in a multi-processor environment. These atomic operations include Load-Exclusive (LDE), Store-Exclusive (STE), and Conditional Compare Exchange (CCXE). LSE also provides new instructions and memory barriers to maintain data consistency and ordering.
Using LSE instructions, you can efficiently access shared memory and implement fine-grained locking mechanisms with lower overhead. Compared to traditional synchronization instructions, LSE instructions reduce lock contention, improve concurrency performance, and provide better scalability.
From which version of OCP does it support installing OceanBase packages with the nolse attribute?
OCP supports installing OceanBase RPM packages with the nolse attribute starting from V4.3.0. This primarily addresses the issue of identifying Large System Extensions (LSE) extension instructions in ARM architecture.
Considerations for OBD deployment
You can upload both OceanBase RPM packages with and without the nolse attribute. OBD will adaptively deploy them based on the system's support. Alternatively, you can upload only the supported packages as needed.
Considerations for OCP deployment
Although you can upload both OceanBase RPM packages with and without the nolse attribute to OCP, adaptive installation is not supported. When selecting the version for a cluster deployment, you must choose whether to use the LSE-supported package as needed.
Can an OBServer node support both IPv4 and IPv6?
For example, can an OBServer node use IPv4 for RPC communication with other OBServer nodes and IPv6 for SQL communication with external clients, or vice versa?
No. The reasons are as follows:
- If IPv6 is not enabled, the OBServer node will not listen on IPv6.
- If IPv6 is enabled, the OBServer node will set the IPV6_V6ONLY option when listening on the SQL port, preventing IPv4 connections.
Can an OceanBase cluster support both IPv4 and IPv6 addresses?
In other words, can IPv4 and IPv6 addresses be mixed in a cluster, where some OBServer nodes are started with IPv4 addresses and others with IPv6 addresses?
Yes.
Notice
For an OBServer node started with IPv4, its underlying operating system and network must support IPv6. Otherwise, the node cannot communicate normally with other OBServer nodes started with IPv6.