#RNDate#2023-11-21
V4.2.1 BP1
Version information
Version: V4.2.1 BP1
Previous version: V4.2.1
Version release date: December 8, 2023
Bug fixes
Fixed the performance issue where the sys tenant resources are excessively consumed when the data volume is large.
Fixed the issue where the frontend page becomes unresponsive when any time component is clicked.
Fixed the dependency issue on the MySQL client when deploying a single-node centralized cluster.
Optimized the speed of retrieving Alerts information on the Backup & Recovery page.
Optimized the overall performance of OCP. Reduced the CPU and memory resource consumption, and significantly improved the response speed of the GUI pages.
V4.2.1
OCP V4.2.1 officially supports OceanBase Database V4.2.1 and provides monitoring and alerting capabilities for all components of OceanBase Database. This includes support for user-defined monitoring, enhanced tenant and session-level end-to-end tracing, and added monitoring and alerting capabilities for OBLB and OBDNS. In terms of backup and restore, this version supports Tencent Cloud COS, further expanding support for storage media from major domestic cloud service providers. Additionally, this version includes 17 optimizations in areas such as cluster management, tenant management, monitoring and alerting, and task management, aiming to improve the product's usability and create a more user-friendly database management platform.
Version information
Version: V4.2.1
Previous version: V4.2.0
Version release date: November 21, 2023
Supported upgrade path:
You can directly upgrade from OCP V3.2.4 and later to this version.
If you use OCP V2.3.x or later but earlier than V3.2.4, you must upgrade to OCP V3.3.4 first.
If you use OCP earlier than V2.3.0, you must upgrade to OCP V2.3.x first, and then to OCP V3.3.4.
Supported OceanBase Database versions
This version of OCP supports the following OceanBase Database versions:
OceanBase V1.4.x
OceanBase V2.1.x
OceanBase V2.2.x
OceanBase V3.1.x
OceanBase V3.2.x
OceanBase V4.x
New features
OceanBase V4.x compatibility
You can enable full-link diagnostics at the tenant and session levels. This feature allows you to analyze transaction-level latency from the client, OBProxy, and OceanBase cluster. This feature requires the deployment of OpenSearch and has version restrictions on the components along the chain. For more information, see Query the trace.
Backup & Recovery now supports Tencent Cloud COS storage (OceanBase Database must be V4.2.1 or later).
The view
__all_virtual_dump_tenant_infois adapted to monitor and alert on tenant queue usage.The tenant configuration option tenant=all is adapted. This option only applies to regular tenants and does not apply to sys or meta tenants.
The views for RS jobs are adapted. New task types such as
ALTER_TENANT_PRIMARY_ZONE,ALTER_TENANT_LOCALITY, andALTER_RESOURCE_TENANT_UNIT_NUMare added.You can view the usage of OceanBase logs.
Feature enhancements
OBProxy management
You can perform a hot restart of OBProxy V3.2.8 and later to avoid service interruption during maintenance or upgrades.
You can enable, restart, stop, and batch start, restart (including hot restart), and stop OBProxy nodes in an OBProxy cluster. This enhances OBProxy management capabilities and improves user efficiency.
Monitoring and alerts
You can customize monitoring capabilities by defining metrics and associating them with monitoring charts and alerts. This allows you to create customized monitoring and alerting solutions. This feature is only available for sys tenants.
You can monitor and alert on OBLB and OBDNS. This includes 16 metrics such as process status and connectivity, providing comprehensive alerting across the OceanBase architecture.
You can monitor the percentage of active Memstore. The path is Tenant > Performance Monitoring > Performance and SQL > MEMStore Usage Percentage.
You can monitor tenant dump counts to prevent business impact from cluster-level major compactions triggered by exceeding the dump threshold in OceanBase V3.X.
You can be alerted when the total space occupied by OceanBase recycle bins exceeds 100 GiB. This helps prevent business impact from excessive partitions and delayed cleanup in OceanBase V3.X recycle bins.
You can be alerted if the OCP agent version is inconsistent with the OCP version. This helps avoid unexpected behavior during maintenance and improves system stability.
Inspection
You can check server connectivity, including SQL and RPC ports, to quickly identify business interruptions caused by network or host failures.
You can check the usage of OceanBase macroblocks to identify tenant, table, and disk usage. This helps reduce disk fragmentation through major compactions.
Feature enhancements
When an object such as a cluster, tenant, or OBProxy is unavailable or a host is offline, the system supports root cause analysis and provides error messages, reasons, and solutions to help users resolve issues and ensure business stability.
Cluster management:
Supports specifying startup parameters, such as
memory_limitandsystem_memory, when adding or replacing an OBServer node to address issues like failed expansion and resource waste due to inconsistent hardware resources within the cluster.Supports specifying startup parameters, such as
cpu_countanddevname, when creating an arbitration service.Added support for providing the option to perform a Memstore dump during cluster restart, cluster stop, zone restart, zone stop, OBServer restart, and OBServer process stop. This helps address the issue of slow OBServer recovery when a dump is not performed.
Supports validating the paths and sizes of cluster log and data disks, including checking the size of the log disk and whether the data and log disks are deployed on the same physical disk. Corresponding prompts are provided to avoid database runtime issues and improve system stability.
Added a prompt for deadlock detection: It is not recommended to enable this feature in production systems of OceanBase Database V3.X.
Provides a check for support of Large System Extensions (LSE) instructions below ARM8.1 to prevent OceanBase cluster deployment failures.
Host management:
Supports associating a host IP address with its corresponding OceanBase cluster or OBProxy cluster and provides quick navigation to the respective cluster.
Supports quick navigation to the corresponding task for hosts in maintenance mode (such as deletion or reinstalling the OCP agent).
Monitoring and alert management:
Supports distinguishing between active and historical alerts and displaying active alerts in the status bar to increase user attention to current active alerts.
In Alerts > Alert Events, added an alert classification option to help users quickly identify alert types and improve product usability.
In alert information (such as cluster, tenant, and OBServer alerts), provides affected host IP addresses or tenant names to help users quickly identify the scope of impact.
Changed the cluster name format to
Cluster Name: Cluster IDand added primary/standby cluster tags.
Backup and restore management:
- Changed the cluster name format to
Cluster Name: Cluster IDand added primary/standby cluster tags.
- Changed the cluster name format to
Log service management:
- In Trace Query > Search, added conditions such as
sql_trace_id,trans_id,sess_id, andclient_infoto help associate user links and improve query efficiency.
- In Trace Query > Search, added conditions such as
Task management:
Supports displaying error information for failed tasks and locating to the first error log to help users efficiently identify the root cause of failures.
Supports batch retrying failed tasks, such as restarting or reinstalling the OCP agent, significantly improving user O&M efficiency.
Supports quick association of clusters, tenants, OBProxies, and hosts in maintenance mode with tasks for users to quickly view task status for subsequent O&M operations.
Product behavior changes
Cluster management: Changed Deadlock Analysis to View Deadlock History.
Tenant management: In Tenant (MySQL) > User Management > Users, no longer supports displaying usernames that do not meet the rules.
Monitoring and alert management: In Alert Channel > Channel Type (Custom Script), removed the ability to upload configuration files to prevent file loss during upgrades.
Key feature interpretation
End-to-end diagnostics at the tenant and session levels
OceanBase Database is a distributed database with highly complex front-end and back-end call chains. When business issues such as timeouts or performance anomalies occur, users often cannot determine whether the issue lies within OceanBase Database or in the network. They can only analyze the issue based on experience and OBServer logs, which can be time-consuming and affect business stability. To address this, OCP provides an end-to-end diagnostics mechanism to monitor the entire chain from Client > OBProxy > OBServer, helping users quickly identify the root cause of issues.
To view related log information in OCP, you need to set the parameters for the data middleware module, link query collection, and OpenSearch (ES). If you only need to enable this feature for specific tenants or sessions, disable the end-to-end diagnostics feature for other tenants and navigate to Log Service > Trace Query. Use filters based on time, tenant, search content (such as sql_id, trans_id, sess_id, etc.), and link duration. The current end-to-end diagnostics tracking is based on database transactions and collects data such as link duration, driver duration, OBProxy duration, and OB duration. By analyzing these durations, you can identify the main issue and view the specific durations (Span/Tag) in the corresponding trace to quickly pinpoint the problem.
Notice
- The end-to-end diagnostics feature is enabled by default. Under default parameters, it has a performance impact of about 2% on tenants. Please disable this feature in performance testing or POC scenarios.
- The feature has the following version restrictions:
- OB-Server >= V4.0.0.0
- OBProxy >= V4.0.0
- OB-JDBC >= V2.4.0
- OCP >= V4.0.3
- OBClient >= V2.2.0
Custom monitoring
Custom monitoring allows users to create customized monitoring charts and alerts tailored to their business scenarios when the built-in monitoring features of OCP do not meet their needs. This helps users promptly perceive changes within the system and make timely and effective decisions. The feature module is divided into three tabs: data collection items, metrics, and charts. Specifically:
Data collection items represent the raw monitoring data collected from various data sources. The system currently provides over 50 data collection items.
Metrics represent calculated indicators based on data collection items, such as maximum, minimum, or average values, among dozens of algorithms. You can select or customize expressions based on your monitoring data usage. The system currently provides over 200 monitoring items.
Charts can consist of one or more metrics and support selecting the chart placement and previewing the chart. Additionally, users can create custom alerts based on metrics to monitor corresponding indicators.
Notice
You can only create data collection items through the Open API.
Fixed issues
OCP V4.2.1 fixes the following issues:
- Fixed the issue where non-admin users cannot access alert details.
- Fixed the issue where rolling back the creation of an OBProxy task does not roll back completely, causing the re-deployment of OBProxy to fail.
- Fixed the issue where the
max_allowed_packettenant variable cannot be modified on OCP. - Fixed the issue where the tenant session count statistics are incorrect.
- Optimized the upgrade speed of OCP from V3.3.x to V4.2.x when there is a large amount of monitoring data.
- Optimized the data collection volume, improving the collection performance and stability.
- Optimized the timeout logic for O&M SQL statements. Currently, you can set the timeout and the performance is more stable.
- Optimized the monagent logs to avoid generating a large amount of unnecessary debug logs.
The alert display is optimized when MetaDB is unavailable.
Known issues
Number |
Known issue |
Workaround |
|---|---|---|
| 1 | After you create an OBProxy cluster on OCP, you cannot connect to the OBProxy cluster because of an issue with OBProxy V4.1.x. | We recommend that you use OBProxy V4.2.1 or later. |
| 2 | After you upgrade OCP, historical tenant resource trend monitoring data is lost because of incompatibility. | Make sure that you can discard the historical tenant resource trend data before you upgrade OCP. |
Version limitations
Hardware requirements
OCP-Server can be installed on a physical server or a Docker container. OCP-Server supports multi-node high availability deployment.
The following table describes the minimum hardware requirements for OCP-Server nodes.
Hardware |
Requirement |
|---|---|
| CPU | |
| Memory | 16 GB of available memory |
| NIC | 10 GbE NIC |
OCP-Agent consumes very little resources and has no special requirements on the hardware resources of the installation node.
Operating system requirements
The following table describes the operating systems that are supported 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 | 12SP3 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
General users access OCP services through a Web browser. The following table describes the minimum browser versions.
Browser |
Minimum version |
|---|---|
| Chrome | 88 |
| Firefox | 78 |
| Safari | 14 |
| Edge | 88 |
If you want to access OCP services on an iOS device, the minimum operating system version is as follows:
Operating system |
Minimum version |
|---|---|
| iOS | 10 |
We recommend that you use a display with a resolution greater than 1440 x 810 for the best user experience.
