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 usage of OCP, 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 full 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 additional 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 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 paths:
Direct upgrades from OCP V3.2.4 and later to the current version are supported.
For OCP V2.3.x and later, V3.2.4 and earlier, you must first upgrade to OCP V3.3.4.
For OCP V2.3.0 and earlier, you must first upgrade to OCP V2.3.x and then to OCP V3.3.4.
Supported OceanBase Database versions
The following OceanBase Database versions are supported in OCP V4.2.0:
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
Supports full-link diagnostics at the tenant and session levels, enabling users to analyze transaction-level latency from the client > OBProxy > 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 link.
Backup & Recovery now supports Tencent Cloud COS storage type (OceanBase Database must be V4.2.1 or later).
Adapts the
__all_virtual_dump_tenant_infoview to monitor and alert on tenant queue usage.Adapts the tenant=all configuration option, which only applies to regular tenants and not to sys or Meta tenants.
Adapts changes to the RS job views, adding task types like
ALTER_TENANT_PRIMARY_ZONE,ALTER_TENANT_LOCALITY, andALTER_RESOURCE_TENANT_UNIT_NUM.Supports displaying OceanBase Database log disk usage.
Feature enhancements
OBProxy management
Supports hot restarts for OBProxy V3.2.8 and later, minimizing downtime during maintenance or upgrades.
Supports enabling, restarting, stopping OBProxy clusters, and batch operations on OBProxy nodes (including hot restarts), enhancing OBProxy management efficiency.
Monitoring and alerts
Supports custom monitoring through defined metrics and charts, linked to alerts, allowing users to tailor monitoring and alerts. This addresses scenarios where built-in OCP alerts are insufficient (only applicable to sys tenant metrics).
Supports alerts for OBLB and OBDNS, covering 16 metrics like process status and connectivity.
Supports monitoring the percentage of active Memstore usage, accessible via Tenant > Performance Monitoring > Performance and SQL > MEMStore Usage Percentage.
Supports monitoring tenant dump counts to prevent cluster-level major compactions due to exceeding the dump threshold in OceanBase V3.X.
Supports alerts when the total space occupied by the OceanBase recycle bin exceeds 100 GiB, reducing the impact of excessive partitions or delayed cleanup on customer operations.
Supports alerts for version mismatches between OCP agent and OCP, preventing abnormal behavior during maintenance and improving system stability.
Inspection
Supports connectivity checks between servers, including SQL and RPC ports, to quickly identify network or host-related business interruptions.
Supports macroblock usage checks in OceanBase Database, helping users identify tenant, table, and disk usage, and reduce disk space issues through major compactions.
Feature optimization
When the object (such as a cluster, a tenant, or an OBProxy) is unavailable, or the host is offline, an exception cause analysis is supported. Error message, error cause, and solutions are provided, so that users can quickly troubleshoot failures and ensure the stable business run.
Cluster Management:
Added support for specifying startup parameters (such as
memory_limitandsystem_memory) during the addition or replacement of an OBServer node, to address issues like cluster expansion failure and resource wastage when hardware resources among cluster nodes are inconsistent.You can specify the startup parameters, such as
cpu_countanddevname, when creating an arbitration service.Added support for the option to initiate a MemStore dump during cluster restart, cluster stop, zone restart, zone stop, OBServer restart, and OBServer stop. This addresses the issue of slow OBServer recovery when a dump is not executed.
Support path and size verification for cluster log and data disks. For example, it can detect the log disk size and check if data and log disks are deployed on the same physical disk. It will provide corresponding prompts to avoid subsequent database exceptions and improve system stability.
Added a prompt: It is not recommended to enable the feature in the production systems of OceanBase Database V3.x.
Detects and avoids deployment failure for OceanBase clusters when large system extensions (LSE) instructions are supported only in versions below ARM8.1.
Host Management
Supports associating host IP addresses with their respective OceanBase clusters or OBProxy clusters, and provides quick navigation to the associated clusters.
Supports quick jump to the corresponding task page for maintenance tasks such as deleting a host or reinstalling an OCP Agent.
Monitor and manage alerts:
Supports distinguishing active alerts, historical alerts, and displays a reminder on the status bar for active alerts to increase user awareness of current active alerts.
Alerts > Alert Events supports the classification option. This feature helps you identify the alert type and improves the product usability.
For example, in the alert information, the affected host IP address or the tenant name is provided to help users quickly identify the scope of impact of the faults.
The cluster name is modified to
Cluster Name:Cluster IDand the primary/standby tag for a cluster is added.
Restore and management of backup:
The cluster name is changed to
Cluster Name: Cluster IDand the primary/standby tag of the cluster is added.Log service management:
Trace Query > Search Add the query conditions of
sql_trace_id,trans_id,sess_id, andclient_info, so that you can associate user links to improve the query efficiency.Task Management:
Support for displaying exception information and locating to the first error log to help users efficiently identify the root cause of failures.
Enable the capability to retry failed tasks in batches, such as Restart or ReInstall OCP Agent in numerous failure scenarios, which can greatly enhance user operations efficiency.
You can quickly associate a service object such as a cluster, a tenant, an OBProxy, and a server to a task. This enables you to view the status of the task and perform subsequent O&M operations.
Product behavioral changes
Cluster management: Deadlock Analysis is now called View Deadlock History.
Tenant Management: Tenant (MySQL) > User Management > Users does not support displaying users whose names do not meet the rules.
Alarm and alert management: Remove the upload capability in the Alert Channel > Channel Type (custom script) configuration file to prevent file loss during upgrades.
Key features interpretation
Cross-tenant and Session-level end-to-end diagnostics
OceanBase is a distributed database. Therefore, the call chain between client and server is extremely complex. When timeout or performance issues occur in the business system, the root cause might be either an issue in OceanBase Database or network issues. In such a situation, you can analyze logs of the OBServer nodes based on your experience. However, this analysis process may take a long time, which may affect the stability of the business. Therefore, OCP provides a full-link diagnostic mechanism to monitor the time required for the entire call chain from Client > OBProxy > OBServer, to help you quickly locate the root cause of the issue.
To view relevant logs in the OCP console, first configure the middleware parameters, link query collection, and OpenSearch (ES) parameters. If you need to enable only for specific tenants or sessions, you must disable the full-link diagnostics feature for other tenants. Navigate to Log Service > Trace Query and filter logs by time, tenant, search content (such as sql_id, trans_id, and sess_id), and link duration. The full-link diagnostics tracking is based on database transactions, which will collect data on link duration, driver duration, OBProxy duration, and OB duration. By analyzing the durations, you can identify the main issues and view the specific durations (Span/Tag) in the corresponding trace to quickly locate the real problem.
Important
- The end-to-end monitoring is enabled by default. By default, the monitoring feature has a slight impact of about 2% on tenant performance. We recommend that you disable this feature in performance testing and POC scenarios.
- The following limits apply to this feature:
- 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 specific business scenarios. This helps users promptly detect changes within the system, enabling them to make quick and informed decisions. The entire feature module is divided into three tabs: collection items, metric items, and charts. These tabs include the following:
Metrics refer to the raw monitored data collected from various data sources. The system currently includes 50+ metric types.
Metric items are calculated based on the collected items. These items include more than 200 algorithms such as maximum value, minimum value, and average value. You can also create an expression to calculate a custom metric.
Charts can be composed of one or more metric items. You can select where to place the charts and preview them before they are displayed. You can also set up custom alerts based on metric items for monitoring purposes.
Note
You can only create data input items through the Open API.
Fixed issues
OCP V4.2.1 fixes the following issues:
- Fixed the issue where non-admin users cannot access the details of alerts.
- 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 from OCP V3.3.x to V4.2.x when there is a large amount of monitoring data.
- Optimized the data collection volume, improving the performance and stability of data collection.
- Optimized the timeout logic for O&M SQL, which now supports setting and is more stable.
- Optimized the monagent logs to avoid generating a large amount of unnecessary debug logs.
Improved the alert display when MetaDB is unavailable.
Known issues
No. |
Description |
Workaround |
|---|---|---|
| 1 | After creating an OBProxy cluster on OCP, OBProxy V4.1.x cannot connect due to its own issues. | We recommend that you use OBProxy V4.2.1 or later. |
| 2 | After the upgrade, historical tenant resource trend monitoring data will be lost due to format incompatibility. | Ensure that the tenant resource trend historical data can be discarded before the upgrade. |
Version limitations
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 minimum hardware requirements for OCP-Server nodes are as follows:
Hardware |
Requirement |
|---|---|
| CPU | |
| Memory | 16 GB of available memory |
| NIC | 10 GbE NIC |
OCP-Agent consumes very little resources and has no special hardware requirements for the installation node.
Operating system requirements
The following table lists the operating system requirements for installing the OCP server (including OCP-Agent).
Server type |
Operating system |
Supported versions |
|---|---|---|
| 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
General users access OCP services through a web browser. The following table lists the client requirements.
Browser |
Minimum version |
|---|---|
| Chrome | 88 |
| Firefox | 78 |
| Safari | 14 |
| Edge | 88 |
If you need to access OCP services from an iOS device, the operating system requirements are as follows:
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.
