OCP V4.2.0

V4.2.0 BP2

Version information

• Version: V4.2.0 BP2

• Previous version: V4.2.0 BP1

• Release date: September 27, 2023

Bug fixes

• Fixed the issue where the Autonomous Service page became inaccessible when an exception occurred.

• Fixed the issue where an error was reported after clicking All while modifying cluster parameters.

V4.2.0 BP1

OCP V4.2.0 BP1 supports seven scenario-based alert rules, including automatic startup of OBServer and arbitration services, tenant and OBProxy scaling, and SQL-level throttling. These rules provide actionable emergency response solutions and offer quick access to these solutions via mobile apps, thereby enhancing the overall stability of OceanBase Database services.

Version information

• Version: V4.2.0 BP1

• Previous version: V4.2.0

• Release date: September 22, 2023

New features

• Provides actionable emergency response solutions based on alert rules. Key features include:

  • Solves specific problems in seven scenarios based on specific alert types:

    • In cases where OBServer or arbitration services crash abnormally, OCP automatically restarts the affected service (with a limit of one restart within 12 hours).

    • For the ob_tenant_request_queue_over_threshold alert indicating tenant queue backlog, OCP defaults to scaling up tenant CPU by 120%.

    • For the tenant_memstore_percent_over_threshold alert indicating tenant memory usage exceeds the threshold, OCP defaults to scaling up tenant memory by 120%.

    • For the alert indicating the proportion of client connections to OBProxy exceeds the threshold, OCP defaults to scaling up cluster-level client connections (client_max_connections) and memory (proxy_mem_limited) by 120%.

    • For alerts indicating abnormal SQL execution plans, SQL performance degradation, or CPU spikes, OCP provides emergency solutions such as refreshing the plan cache, binding execution plans, and SQL-level throttling.

  • Supports pushing alert information and solutions to external tools like Lark, DingTalk, and WeCom, enabling users to quickly handle critical faults via mobile apps.

  • Supports marking alerts with available solutions for quick querying.

  • Supports recording and querying OpenAPI calls for later investigation.

  • Supports configuring alert settings at three levels: cluster, tenant, and OBServer.

• Added the ob_tenant_request_queue_over_threshold alert to help users promptly troubleshoot tenant performance issues.

• Added the disk unavailable alert to help users quickly identify hardware failures and avoid impacting normal business operations.

• If arbitration service is enabled at the cluster level and the sys tenant replicas meet the 2F/4F requirement, arbitration service is automatically enabled.

Security improvements

• Password security enhancement for proxyro@sys

  For OceanBase clusters of version V4.0 or later and OBProxy clusters of version V4.0 BP2 (obproxy-4.0.0-20230130103527) or later, you can set the proxyro@sys account password to a random value.

• Password security enhancement for root@proxysys

  Supports user-defined password for the OBProxy administrator root@proxysys, with additional compliance verification against Level 3 of the Cybersecurity Classified Protection Scheme.

Bug fixes

• Optimized data latency in drill-down monitoring.

• Fixed an issue where incorrect configuration of the OCP agent could cause it to exit.

• Resolved an issue where the same alert was sent multiple times in some scenarios of a multi-node OCP deployment.

V4.2.0

OCP V4.2.0 officially supports OceanBase Database V4.2.0 and incorporates three key features of OceanBase Database V4.x: tenant-level physical primary/standby databases, resource isolation within a tenant, and IOPS isolation between tenants. Additionally, starting from this version, OCP allows users to customize the deployment user and installation path for OBServer, OBProxy, and arbitration service nodes. This meets the operational management requirements of different users and enhances the monitoring and alerting capabilities for OBProxy and arbitration services, as well as the SQL diagnostics capability of the autonomous service module. Meanwhile, OCP V4.2.0 introduces over 20 usability optimizations, such as optimizing tenant-level CPU usage and enabling automatic restart of OBServer and OBProxy services upon restart. These improvements significantly reduce user operation complexity, making it easier for users to manage and maintain OceanBase Database.

Version information

• Version: V4.2.0

• Previous version: V4.1.0

• Release date: August 30, 2023

• Supported upgrade path:

  • Currently, only direct upgrades from OCP V3.2.4 and later versions to the current version are supported.

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

  • For OCP versions earlier than V2.3.0, you must first upgrade to OCP V2.3.x, 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 product features

OceanBase V4.x compatibility

• Tenant-level log disk size limits and IOPS isolation

  Resource specifications (Units) are used to limit the size of the log disk and the disk IOPS for a tenant, enabling IOPS isolation.

• Tenant-level physical standby database management

  • Supports setting up primary and standby tenants via archive-based or network-based methods (only available in OceanBase V4.2.0 and later).
  • Supports using the daily switchover or disaster recovery failover feature between primary and standby databases to meet business scenarios requiring local or geo-distributed disaster recovery.

• Resource isolation within a tenant

  Leveraging OceanBase's kernel capabilities, OCP provides resource management and control across the following three dimensions, allowing users to achieve maximum resource efficiency based on their business characteristics.

  • User resource isolation: Limits user access to resources such as CPU and IOPS based on the application type.
  • Background task isolation: Limits the resource usage of eight background tasks, including minor compaction, migration, major compaction, and backup.
  • SQL resource isolation: Restricts resource usage for specific businesses by specifying SQL conditions such as WHERE clauses.

• OceanBase Database V4.2 features

  • Added tenant-level read-only replicas. In OceanBase Database V4.2.0, OceanBase supports full-featured replicas and read-only replicas.
  • Added tenant-level unit scaling capability.
  • Supports starting OBServer nodes by specifying an IP address, resolving the issue of selecting the wrong IP address in scenarios where a single network interface card has multiple IPs.
  • Reduced the likelihood of incorrect parameter configuration by mandating that capacity-related parameters such as memory_limit and system_memory have unit information.
  • Supports monitoring the number of physical reads, time consumed, and traffic of incremental logs (Clogs), facilitating real-time disk performance diagnostics.
  • Supports monitoring five transaction table cache hits (such as SSTable, MEMTable, KV Cache, etc.), assisting users in transaction-related performance diagnostics.
  • In the cluster Resource Management > Unit Distribution section, the Unit page displays tenant roles and primary replica information.

Feature enhancements

• OceanBase Autonomy Service

  • When a cluster exposes an exception event (e.g., node CPU exception), it directly performs SQL diagnostics at the node level (or cluster level).
  • Added an Optimization Center, which supports reviewing TopSQL statements within a specified time period to determine if optimization is possible and how to optimize them. It also reviews the corresponding table and index structures to identify optimization points and provides suggestions.

• Monitoring and Alerts

  • Supports five alert capabilities for OBProxy process status, connectivity, client connections, server connections, and memory usage, enhancing the product's end-to-end monitoring capability.
  • Supports automatic failure information collection and report downloading in critical alert scenarios such as downtime or sudden CPU exception spikes, facilitating user fault diagnosis based on the collected information.

• Installation and Deployment

  • Allows customization of user installation and deployment for OBServer, OBProxy, and arbitration nodes via the system parameter ocp.operation.default.os.user, meeting the operational management specifications of different enterprise customers.
  • Achieves automatic startup of OBProxy and OBServer after host restart through Systemd, reducing manual operations and improving operational efficiency.
  • Supports identifying the CPU architecture (X86 or ARM) of software installation packages, reducing the probability of incorrect package selection.

Feature optimizations

• Cluster Management Module:

  • In the Take over Cluster scenario, supports user entry of the proxyro password, resolving the issue of difficult cluster takeover caused by inconsistent proxyro passwords.
  • Optimized OceanBase Database terminology: changed root server to root service.
  • Added OBServer event collection in Overview > System Events, facilitating user troubleshooting.
  • Optimized the loading speed of the cluster management page, enabling large-scale cluster management.

• Tenant Management Module:

  • Optimized the tenant list by removing the Tenant ID column and adding Cluster sorting functionality.
  • Added OBServer attributes to the Session List and supported filtering, facilitating quick problem diagnosis.

• Monitoring and Alerts Module:

  • Optimized the monitoring name, changing CPU Utilization to CPU Consumption of Tenant, and updated the data calculation logic to more accurately reflect tenant resource usage.
  • Added the Thread Usage of Tenant monitoring metric to help users quickly identify tenant runtime status.
  • Standardized over 10 monitoring names according to industry standards. For example, IO Time in Tenant > Performance Monitoring > Storage and Cache was changed to Physical Read IO Time, and TPS replaced Transactions Per Second in OBProxy Cluster > Service Monitoring.

• Inspection Module:

  Added system parameters ocp.inspection.report.expired.days and ocp.inspection.report.expired_cleanup.enabled to control the inspection report expiration strategy, reducing disk usage for inspection reports.

• Major Compaction Management Module:

  When the system parameter enable_manual_merge is set to true, users are explicitly prompted that manual partition major compaction is required.

• Task Management Module:

  Implemented navigation logic between tasks and their operation targets (such as clusters, tenants, OBProxy), facilitating object and task management.

• Operation Audit Module:

  • Supports recording Open API call information for comprehensive security control.
  • Supports associating multiple resources (such as hosts, tenants) with a single user operation event.

Key Feature Interpretation

Tenant-Level IOPS Isolation

OceanBase Database V4.0 addresses the issue of disk contention among different tenants by virtualizing disk bandwidth (IOPS). It enables N tenants to operate as if they were on N separate physical disks, providing top-tier resource isolation for OceanBase tenants. You can specify the maximum IOPS when creating a unit specification, so all business requests under the corresponding user will be limited by this IOPS, achieving I/O isolation between tenants.

Tenant-Level Physical Standby Database Functionality

In OceanBase Database versions prior to V4.1.0, a cluster had two roles: primary cluster and standby cluster. The standby cluster served as a data backup for the primary cluster, ensuring transaction consistency. The primary cluster automatically transmitted redo logs to the standby cluster, which then automatically applied them, ensuring physical consistency of data and schemas between the primary and standby clusters. Starting from V4.1.0, the physical standby database product form changed to tenant-level primary/standby, where the primary or standby role belongs to a tenant, divided into primary tenant and standby tenant. The concept of primary/standby roles no longer exists at the cluster level; instead, a cluster is merely a container for tenants. A primary tenant is a business tenant created by users and supports full database service capabilities, including queries, DML, DDL, etc.; a standby tenant provides only disaster recovery and read-only services. A primary tenant and several standby tenants together form a tenant-level physical standby database high availability solution.

Physical standby databases can be set up based on log archiving or over the network:

1. Log-Archiving-Based Physical Standby Database

   In a log-archiving-based physical standby database, the redo logs for the physical standby database come from the log archive of the primary tenant or other standby tenants, similar to Far Sync in Oracle Database. The standby tenant interacts only with the log archive and does not engage in any other interaction with upstream primary or standby tenants. In this deployment mode, the standby tenant does not require network connectivity to upstream tenants, but its synchronization performance and availability are affected by the log archive media.

2. Network-Based Physical Standby Database

   In a network-based physical standby database, the standby tenant directly reads logs from the primary tenant or other standby tenants over the network, similar to Replication in MySQL Database. In this deployment mode, the networks of the standby and primary tenants must be connected. The standby tenant sends RPC requests over the network to read redo logs from the primary tenant cluster. To support high availability for the standby tenant in scenarios such as primary tenant node failure or log recycling, the standby tenant also requires limited query permissions on primary tenant system views. In this mode, the logs read by the standby tenant from the primary tenant can be either online logs or archived logs (provided the primary tenant has enabled log archiving mode). Automatic switching between these two log sources is supported and transparent to the standby tenant and business users.

OceanBase clusters support two tenant roles: Primary Tenant (PRIMARY) and Standby Tenant (STANDBY). You can dynamically change tenant roles through routine primary/standby switchover and disaster recovery switchover.

1. Routine Primary/Standby Switchover: Allows the primary tenant to swap roles with one of its standby tenants, ensuring data integrity.
2. Disaster Recovery Switchover: When the primary tenant is unavailable, a standby tenant can be switched to primary.

Product limitation: Only supported in OceanBase Database V4.2.0 and later.

Resource Isolation Within a Tenant

In OceanBase Database, the DBMS_RESOURCE_MANAGER system package is used to manage resource allocation and implement resource isolation, but the overall configuration is complex. OCP simplifies this complexity through a streamlined approach, enabling user-level and SQL-level resource isolation.

1. The creation process has been optimized. You can easily create a resource isolation plan by following these three steps: configure the resource isolation plan > configure the resource group > apply resource isolation restrictions.

2. The semantics for viewing resource isolation metrics have been improved, such as the conversion of CPU and IOPS limits and weights into SQL expressions.

3. Dynamic adjustment of resource isolation plans is supported, including enabling, disabling, modifying, and deleting resource isolation plans.

Bug fixes

• Optimized the alert behavior when MetaDB is unavailable.

• Optimized the parameter configuration of OBProxy and made some read-only parameters modifiable.

• Fixed the issue where the alert archiving time parameter does not take effect.

• Fixed the issue where host monitoring data is pushed to Prometheus but not recognized.

• Fixed the issue where standardization of hosts fails in specific scenarios.

• Fixed the issue where the database name and username are occasionally inconsistent in Autonomous Service > SQL Details.

Known issues

Version requirements

Hardware requirements

OCP-Server can be installed on a physical server or run in a Docker container. OCP-Server supports high-availability deployment with multiple nodes.

The minimum hardware requirements for an OCP-Server node are listed in the following table.

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

Operating system requirements

The operating system requirements for installing the OCP server (including OCP-Agent) are listed in the following table.

Client requirements

Users typically access OCP services through a web browser. The client requirements are as follows.

If you need to access OCP from a device running iOS, the version requirements are listed in the following table.

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