OCP V4.2.1

#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 during deployment of 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 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 now supports Tencent Cloud COS, further expanding support for storage media from major domestic cloud service providers. Additionally, this version includes 17 optimizations across cluster management, tenant management, monitoring and alerting, and task management, focusing on improving usability and creating 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 the current version.

  • If you are using OCP V2.3.x and later, but earlier than V3.2.4, you must first upgrade to OCP V3.3.4.

  • If you are using 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

OCP V4.2.0 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

• Supports full-link diagnostics at the tenant and session levels, enabling users to analyze transaction-level latency across three layers: client > OBProxy > OceanBase cluster. This helps quickly identify and resolve the root cause of issues. Note that this feature requires deploying the OpenSearch service and has version restrictions on components along the chain. For more information, see Query trace.

• Backup & Recovery now supports integration with Tencent Cloud COS storage (OceanBase Database must be V4.2.1 or later).

• Adapts the __all_virtual_dump_tenant_info view to monitor and alert on tenant queue usage.

• Adapts the tenant=all configuration parameter, which only applies to regular tenants and not to sys or Meta tenants.

• Adapts changes to the RS job views, adding task types such as ALTER_TENANT_PRIMARY_ZONE, ALTER_TENANT_LOCALITY, and ALTER_RESOURCE_TENANT_UNIT_NUM.

• Supports displaying information about the usage of OceanBase Database's log disk.

Feature enhancements

• OBProxy management

  • Supports hot restarts for OBProxy V3.2.8 and later, minimizing downtime during maintenance or upgrades.

  • Supports enabling, restarting, and stopping OBProxy clusters, as well as batch starting, restarting (including hot restarts), and stopping OBProxy nodes, enhancing management capabilities and improving user efficiency.

• Monitoring and alerts

  • Supports custom monitoring by defining collection items and monitoring items, and linking them to monitoring charts and alerts. This addresses scenarios where built-in OCP alerts do not meet customer needs (only applicable for sys tenant metrics).

  • Supports alerts for OBLB&OBDNS with 16 metrics, such as process status and connectivity, providing comprehensive alerting across the OceanBase architecture.

  • Supports monitoring the percentage of active Memstore usage, accessible via Tenant > Performance Monitoring > Performance and SQL > MEMStore Usage Percentage.

  • Supports monitoring the number of tenant dumps to help prevent business impact from cluster-level major compactions triggered by 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 and delayed cleanup on customer operations.

  • Supports alerts when the OCP agent version is inconsistent with the OCP version, preventing abnormal behavior during subsequent maintenance and improving system stability.

• Inspection

  • Supports connectivity checks between servers, including SQL and RPC ports, helping users quickly identify business interruptions caused by network or host failures.

  • Supports checking the usage of OceanBase macroblocks, helping users identify tenant, table, and disk usage, and reducing disk space issues 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 information, error reasons, and solutions to help users resolve the issue and ensure business stability.

• Cluster management:

  • When you add an OBServer or replace an OBServer, you can specify startup parameters such as memory_limit and system_memory to address issues such as failed expansion and resource waste when the hardware resources of the servers in the cluster are inconsistent.

  • When you create an arbitration service, you can specify startup parameters such as cpu_count and devname.

  • When you restart a cluster, stop a cluster, restart a zone, stop a zone, restart an OBServer, or stop an OBServer process, you can choose to perform a MemStore dump. This helps address the issue of slow OBServer recovery when a dump is not performed.

  • You can validate the paths and sizes of the log disk and data disk of a cluster. For example, you can check the size of the log disk and whether the data disk and log disk are deployed on the same physical disk. The system provides corresponding prompts to avoid database runtime exceptions and improve system stability.

  • The system adds a prompt that recommends that you do not enable the deadlock detection feature in production systems of OceanBase Database V3.x.

  • The system provides a check for the support of Large System Extensions (LSE) instructions with versions lower than ARM8.1 to avoid deployment failures of OceanBase clusters.

• Host management:

  • You can associate the IP address of a host with the OceanBase cluster or OBProxy cluster to which it belongs and quickly jump to the corresponding cluster.

  • You can quickly jump to the corresponding task for a host in the maintenance state (such as a host deletion task or an OCP Agent reinstallation task).

• Monitoring and alert management:

  • The system distinguishes between active and historical alerts and displays active alerts in the status bar to increase user attention to current active alerts.

  • In the Alerts > Alert Events page, you can select an alert category to help you quickly identify the type of alert and improve product usability.

  • In the alert information (such as cluster alerts, tenant alerts, and OBServer alerts), the IP address of the affected host or the name of the affected tenant is provided to help you quickly identify the scope of the failure.

  • The system changes the cluster name to Cluster Name:Cluster ID and adds a primary/standby tag for the cluster.

• Backup and restore management:

  The system changes the cluster name to Cluster Name:Cluster ID and adds a primary/standby tag for the cluster.

• Log service management:

  In the Trace Query > Search page, you can specify sql_trace_id, trans_id, sess_id, and client_info as search conditions to help associate user links and improve query efficiency.

• Task management:

  • If a task fails, the system displays the error information and locates the first error log to help you quickly identify the cause of the failure.

  • You can retry a failed task in batches. For example, you can retry a failed task such as restarting or reinstalling the OCP Agent. This significantly improves your O&M efficiency.

  • You can quickly associate a cluster, tenant, OBProxy, or host in the maintenance state with a task to view the task status for subsequent O&M operations.

Changes in product behavior

• Cluster management: Deadlock Analysis is changed to View Deadlock History.

• Tenant management: In the Tenant (MySQL) > User Management > Users page, you cannot view usernames that do not conform to the rules.

• Monitoring and alert management: In the Alert Channel > Channel Type (Custom Script) page, you cannot upload a configuration file to avoid the risk of file loss during upgrades.

Key features

End-to-end diagnostics at the tenant and session levels

OceanBase Database is a distributed database. The call chain between the client and the database is extremely complex. When a timeout or performance issue occurs in the business, users often cannot determine whether the issue is caused by an internal component of OceanBase Database or a network issue. They can only analyze the issue based on experience and OBServer logs, which results in a long time to analyze and resolve the issue, thus affecting business stability. Therefore, OCP provides an end-to-end diagnostics mechanism to monitor the time consumption of the entire Client > OBProxy > OBServer chain, helping you quickly identify the root cause of the issue.

To view the relevant log information in OCP, you must first set the parameters of the Data Hub module, link query collection, and OpenSearch (ES). If you want to enable the feature for only some tenants or sessions, you must disable the feature for other tenants and go to the Log Service > Trace Query page. On this page, you can filter the logs by time, tenant, search content (such as sql_id, trans_id, sess_id, and client_info), and link time consumption. The current end-to-end diagnostics tracking is based on database transactions. It collects data such as link time consumption, driver time consumption, OBProxy time consumption, and OB time consumption. By analyzing the time consumption data, you can identify the main issue and view the specific time consumption (Span/Tag) in the corresponding trace to quickly locate the real issue.

Custom monitoring

Custom monitoring allows you to create custom monitoring charts and alerts based on your business scenarios when the built-in monitoring features of OCP do not meet your requirements. This helps you promptly perceive changes in the system and make timely and effective decisions. The feature module consists of three tabs: data collection items, metrics, and charts. Specifically:

1. Data collection items represent the original monitoring data collected from different data sources. The system provides 50+ data collection items by default.

2. Metrics represent the calculated metrics generated based on data collection items. For example, you can calculate the maximum, minimum, or average value of the data. You can select or customize expressions based on your monitoring data usage. The system provides 200+ metrics by default.

3. Charts can be composed of one or more metrics. You can select the chart placement and preview the chart. You can also create custom alerts based on the metrics to monitor the corresponding metrics.

Fixed issues

OCP V4.2.1 mainly 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, leading to a failed OBProxy re-deployment.
• Fixed the issue where the max_allowed_packet tenant variable cannot be modified on the OCP console.
• 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 amount of data collected, 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 behavior when MetaDB is unavailable.

Known issues

Version usage 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 following table lists the minimum hardware requirements for OCP-Server nodes.

OCP-Agent consumes very few resources and has no special requirements on the hardware resources of the installation node.

Operating system requirements

The following table lists the operating system requirements for installing OCP Server (including OCP-Agent).

Client requirements

General users usually access OCP services through a web browser. The following table lists the client requirements.

If you want to access OCP services on an iOS device, the following table lists the operating system requirements.

For the best user experience, we recommend that you use a display with a resolution greater than 1440 x 810.