V4.3.5 BP3
Version information
Version number: V4.4.5 BP3
Previous version: V4.3.5 BP2
Version release date: April 17, 2025
Product behavior changes
Fixed security issues and upgraded the underlying framework and runtime environment for OCP.
V4.3.5 BP2
Version information
Version number: V4.3.5 BP2
Previous version: V4.3.5 BP1
Version release date: March 27, 2025
Behavior changes
Adapt to OceanBase standalone edition: standalone installation package (experimental feature).
V4.3.5 BP1
Version information
Version number: V4.3.5 BP1
Previous version: V4.3.5
Version release date: March 20, 2025
Product behavior changes
- Fixed the issue where the retry logic for the OBProxy upgrade RPM task was incorrect.
- Fixed the issue where, after logging in to OCP, it was redirected to the
xx.wofffile. - Fixed the issue where, after upgrading the Binlog cluster,
compute_host_servicewas not updated to the latest version. - Fixed the issue where a negative clock offset caused alert detection to fail.
- Fixed the issue where, during the migration of custom roles, some roles had incorrect resource permissions and object allocations.
- Optimized the number of metrics to reduce pressure on the Agent and Server, with default metrics collection for OBKV disabled.
- Optimized the original P99 metrics by configuring separate metrics and query SQL for each instance type.
V4.3.5
OCP V4.3.5 is officially released, fully compatible with OceanBase V4.3.5. This version introduces key features, including high availability of arbitration services, ensuring continuous and stable service for OceanBase. Additionally, this version supports monitoring capabilities for OBKV-Redis and includes over 20 improvements and optimizations in basic O&M, performance monitoring, inspection services, and platform features, enhancing product usability and helping users more easily manage OceanBase Database.
Version information
Version number: V4.3.5
Previous version: V4.3.4 BP2
Version release date: March 4, 2025
Supported upgrade path:
At present, you can directly upgrade OCP V3.2.4 and later to the current version.
For OCP V2.3.x and later versions, but earlier than V3.2.4, you need to upgrade OCP to V3.3.4 first.
For OCP earlier than V2.3.0, you need to upgrade OCP to V2.3.x first, and then to V3.3.4.
Supported OceanBase Database versions
OCP V4.3.5 supports OceanBase Database of the following versions:
OceanBase V2.2.76 & OceanBase V2.2.77
OceanBase V3.1.x
OceanBase V3.2.x
OceanBase V4.0.x
OceanBase V4.1.x
OceanBase V4.2.x
OceanBase V4.3.x
New Features
Basic O&M
Arbitration Service:
- Supports high availability of arbitration services through arbitration service groups to ensure continuous and stable service of OceanBase.
- Supports batch operations for arbitration services, including replacing arbitration services, associating new clusters, and disassociating, to improve user operation efficiency.
Cluster Management:
- In new zone scenarios, supports automatic tenant replica scaling to enhance user efficiency.
- Adds Start Time and Online Duration for clusters and OBServer nodes, facilitating database service observation. The startup time and online duration are not supported in cluster takeover scenarios.
- In Resource Management > Unit Distribution, displays System_Memory / 500 Tenants.
- When OceanBase is V4.X or later, Compaction Management supports displaying the last three major compaction records.
Tenant Management:
- Supports creating databases and users with two special characters:
-and_. The character_is a MySQL wildcard. Please note the authorization scope to prevent authorization leaks. - When OceanBase is V4.X or later, Compaction Management supports displaying the last three major compaction records.
- Supports creating databases and users with two special characters:
Performance Monitoring
- When OceanBase is V4.2.5 or later and the tenant is in MySQL mode, monitoring capabilities for OBKV-Redis instances are added, including QPS and Response Time.
- The monitoring dashboard supports importing and exporting Grafana/OCP monitoring metrics in JSON format, facilitating OceanBase database monitoring.
- When OBProxy is V4.3.0 or later, OBProxy RPC port monitoring capabilities are added, including RPC Sessions, RPC Requests, and RPC Request Latency.
Inspection Service
Supports comparing parameters between different OBProxies in the same OBProxy cluster to avoid production faults caused by parameter inconsistencies.
Backup and Restore
- When OceanBase Database is V4.X, log backup tasks can be paused or resumed.
- During data restore, the system supports displaying the restore interval, now extended from the last 7 days to the last 180 days.
- The restore task module adds a copy feature, allowing users to copy completed restore tasks and modify parameters as needed, reducing repetitive work and significantly improving convenience and efficiency.
Open API
- Opens two Open APIs: start and stop OBProxy.
- Opens over 20 Open APIs for arbitration services and service groups.
Platform features
- O&M Configuration: Visualizes the CPU and memory size of OCP Agent from the cluster and host dimensions.
- Software Package Management: Supports batch upload of software packages to improve the convenience and efficiency of operations.
- Log Service: When OceanBase is V4.2.3 or later (excluding V4.3.0), the
observer.loglog compression capability is added.
Product optimization
Cluster management
- When deleting a cluster, prompt the user to clean up all data and log backups in the cluster to avoid unnecessary data occupying storage space.
- When creating an OceanBase V4.X or later cluster, set the default value of system_memory/500 to 0Mib, allowing the system to allocate memory as needed.
- In the primary and standby tenant scenario, when upgrading the standby cluster, ensure that the standby tenant's database version is not more than two levels higher than the primary tenant's.
Tenant management
- When deleting a tenant, prompt the user to clean up all data and log backups in the tenant to avoid unnecessary data occupying storage space.
- Support the batch addition/ modification of IPv4 addresses in the tenant allowlist, such as
xxx.xxx.xxx.1-3, which representsxxx.xxx.xxx.1,xxx.xxx.xxx.2, andxxx.xxx.xxx.3. Only the last segment can have a range.
OBProxy management
- Add the parameter template feature, providing two default parameter templates: 4.2.1 Default Parameter Template and Columnar Replica Default Parameter Template.
- When creating an OBProxy cluster, display the selected version before prompting the user to enter the root@proxysys password, to prevent user errors in some scenarios.
- On the load balancing page, implement the ability to add notes, display notes, and edit notes.
Other updates
Host management: Support initializing hosts based on product type (OceanBase / OBProxy).
Binlog Service:
- Binlog Instance > Subscription Connection List: Display the real client IP.
- Add the parameter template feature, providing five default performance parameter templates: Default Performance Parameter Template, Intermediate Performance Parameter Template, Advanced Performance Parameter Template, Super Performance Parameter Template, and Top Performance Parameter Template.
Performance Monitoring:
- When the user selects a monitoring time greater than 3 days, display 1440 monitoring points on the monitoring chart to improve the accuracy of monitoring data trends and characteristics.
- Optimize the selection logic for Custom Time in Performance Monitoring, enhancing the ease of use for query time settings.
Alert Center:
- Alert Rules > Basic Settings: Add monitoring metrics to facilitate user troubleshooting based on these metrics.
- When muting alert targets, support muting specific metrics through Tag.
Feature highlights
High availability of arbitration service
OceanBase Database V4.1 provides arbitration services. The low resource consumption and support for multiple clusters make the arbitration services a cost-effective solution for high availability in OceanBase databases, such as the 2F1A/4F1A architecture. This architecture ensures high availability while controlling resource costs, significantly improving the value proposition. However, arbitration services can have a single point of failure. If the arbitration services fail, it can degrade high availability in OceanBase clusters, potentially affecting business continuity and stability. To address this challenge, arbitration service groups are created, enabling rapid failover to healthy arbitration service nodes within seconds if an arbitration service node fails and meets the replacement conditions. This ensures stable operation of OceanBase clusters under various complex situations, protecting business continuity.
Instructions:
- The arbitration service version must be the same within the same arbitration service group.
- It is recommended that each arbitration service group have at least two arbitration service endpoints.
- After the arbitration service switch is completed by the arbitration service group, please make sure to reconfigure the relationship between the cluster and the arbitration service based on the actual business situation, to avoid overloading any arbitration service.
- Consistency service group with the backup plan: When the OBServer process of the consistency service exits unexpectedly and is restarted, there is no functional conflict between the consistency service group and the backup plan. That is, when the consistency service fails, the backup plan can be automatically started and also trigger the replacement of the consistency service because it meets the replacement conditions for the consistency service group.
- Supports four main features: creating a service group, upgrading a service group, editing a service group, and deleting a service group.
Optimization of backup strategies in OceanBase Database V4.x
The ability to perform batch operations on tenant backup strategies through cluster backup strategies:
- A cluster-level backup strategy applies only to tenants without a tenant-level backup strategy set.
- When a cluster backup policy is deleted, the system automatically deletes the cluster and tenant backup policy and disables tenant-level log backup.
Log backup can be disabled in cluster or tenant backup strategies. By default, the system enables log backup before data backup and disables it after data backup, primarily addressing issues where log backup can be excessively large in certain business scenarios.
The operation to enable or disable log backup under the cluster/tenant backup policy takes the highest priority, even if the user manually enables or disables log backup, the system will still follow the backup policy to enable or disable log backup by default. When editing a cluster backup strategy or a tenant backup strategy, the storage configuration option is greyed out by default. This means that the storage path and access key (AK) and secret key (SK) of the object storage cannot be changed. This prevents log archiving or data backup failures.
When no cluster or tenant backup strategy exists, the system logs the enablement state of log backup. If log backup is not enabled, and a user manually initiates a backup, the system will enable log backup before performing data backup and disable it after data backup is completed. If log backup is already enabled, it remains enabled after data backup is finished.
Bug fixes
OCP V4.3.5 mainly fixes the following issues:
- Fixed the issue where the cluster list cannot be displayed when the cluster is unavailable.
- Fixed the issue where an alert is incorrectly triggered when the location cache fails.
- Fixed the issue where the data size displayed in table statistics is incorrect.
Known issues
| No. | Description | Workaround |
|---|---|---|
| 1 | After you create a tenant-level backup strategy, if you do not immediately back up data, the subsequent scheduled backup tasks will fail. | Manually perform an immediate backup, and the issue will be resolved. |
| 2 | After the cluster is upgraded, the Start Time and Online Duration fields are empty. | This is normal. |
| 3 | When you drill down to view tenant performance metrics, the RT99 and RT95 metrics are missing. | This is normal. |
| 4 | When you delete an arbitration service group, the group cannot be recreated because of residual garbage data. | This is normal. |
Limitations on versions
Hardware requirements
OCP-Server can be installed on a physical server or in a Docker container. OCP-Server supports multi-node high-availability deployment.
The following table describes the minimum hardware requirements for an OCP-Server node.
| Hardware | Requirement |
|---|---|
| CPU | |
| Memory | 16 GiB of available memory |
| NIC | 10 Gbit/s NIC |
OCP-Agent itself consumes few resources, so no special hardware resources are required for the installation node.
Operating system requirements
The following table describes the operating system requirements for installing OCP-Server (including OCP-Agent).
| Server type | Operating system | Supported version |
|---|---|---|
| x86_64 | RHEL | 7.2 and later |
| x86_64 | CentOS | 7.2 and later |
| x86_64 | AliOS | 7.2 and later |
| x86_64 | openSUSE | 12 SP3 and later |
| ARM aarch64 | AliOS | 7.2 and later |
| ARM aarch64 | NeoKylin | 7.6 |
| ARM aarch64 | Huawei EulerOS | 2.0 SP8 |
| x86_64 | Debian | Debian GNU/Linux 11 (bullseye) |
| x86_64 | Ubuntu | Ubuntu 18.04.6 LTS |
Client requirements
Generally, users access OCP services through web browsers. Therefore, the following client requirements apply.
| Browser | Minimum version |
|---|---|
| Chrome | 88 |
| Firefox | 78 |
| Edge | 88 |
If you need to access OCP through an iOS device, the following version requirements apply.
| Operating system | Minimum version |
|---|---|
| iOS | 10 |
For the best user experience, we recommend that you use a display with a resolution greater than 1440 x 810.