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 error that occurred after clicking Select All when modifying cluster parameters.

V4.2.0 BP1

OCP V4.2.0 BP1 supports implementing seven contingency plan scenarios based on alert rules, including automatic startup of OBServer and arbitration services, tenant and OBProxy scaling, and SQL-level throttling. It provides actionable emergency response solutions based on alert rules and offers quick operation entry points for users through 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. The main implemented features include:

  • Solves specific problems in seven scenarios based on specific types of alerts:

    • In cases where OBServer or arbitration services crash abnormally, OCP automatically restarts the OBServer and arbitration services (only one restart is supported within 12 hours).

    • In the ob_tenant_request_queue_over_threshold alert scenario, OCP defaults to scaling the tenant's CPU by 120%.

    • When the tenant memory tenant_memstore_percent_over_threshold exceeds the threshold, OCP defaults to scaling the tenant's memory by 120%.

    • When the proportion of client connections to OBProxy exceeds the threshold, OCP defaults to scaling the cluster-level client connection count (client_max_connections) and memory (proxy_mem_limited) by 120%.

    • In abnormal scenarios such as detected SQL execution plan anomalies, SQL performance degradation, or CPU spikes, OCP provides emergency solutions like refreshing the Plan Cache, binding execution plans, and SQL-level throttling.

  • Supports pushing alert information and solutions to external tools such as "Feishu," "DingTalk," and "WeCom," allowing users to quickly handle urgent faults via mobile devices.

  • Supports marking alerts with contingency plans for easy quick querying of related alert information.

  • Supports recording/querying Open API calls for later investigation.

  • Supports setting alert functionality at three levels: cluster, tenant, and OBServer.

• Added the tenant queue backlog alert capability to help users promptly troubleshoot tenant performance-related 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

• ProxyRO@SYS password security remediation

  For OceanBase clusters above V4.0 and OBProxy clusters above V4.0 BP2 (obproxy-4.0.0-20230130103527), setting the proxyro@sys account to a random password is supported.

• Root@proxysys password security remediation

  Users can now set the password for the OBProxy administrator root@proxysys, and additional compliance verification rules have been added for Level 3 of the Cybersecurity Classified Protection Scheme.

Bug fixes

• Optimized data latency when drilling down on monitoring metrics.

• Fixed an issue where an incorrectly configured OCP agent could cause the system to exit.

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

V4.2.0

OCP V4.2.0 officially supports OceanBase Database V4.2.0 and also supports the three major 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 supports custom deployment of user accounts and installation paths 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 databases.

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 tenants to meet local and geo-distributed disaster recovery business scenarios.

• Resource isolation within a tenant

  Leveraging OceanBase's kernel capabilities, OCP provides resource management 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 through SQL statements (e.g., by specifying WHERE conditions).

• OceanBase Database V4.2 features

  • Added tenant-level read-only replicas. In OceanBase Database V4.2.0, OceanBase Database 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 for logs.
  • Supports monitoring cache hits for five transaction tables (such as SSTables, MEMTables, and KV caches), 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

• Autonomous services

  • When an exception is exposed in the cluster (e.g., abnormal node CPU), SQL diagnostics are performed directly at the node level (or cluster level).
  • A new Optimization Center has been added, supporting the review of 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 processes, including status, connectivity, client connections, server connections, and memory usage, enhancing the product's end-to-end monitoring capability.
  • Supports automatic fault information collection and report downloading in critical alert scenarios such as outages or sudden spikes in abnormal CPU, facilitating fault diagnosis based on the collected information.

• Installation and deployment

  • The system parameter ocp.operation.default.os.user supports customizing the installation directory for users deploying OBServer nodes, OBProxy nodes, and arbitration nodes, meeting the operational management specifications of different enterprise customers.
  • Achieves automatic startup of OBProxy and OBServer after host restart via 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 entering 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 troubleshooting.
  • Optimized the loading speed of the cluster management page, enabling large-scale cluster management.

• Tenant management module:

  • Optimized the tenant list, removing the Tenant ID column and adding a Cluster sorting function.
  • Added OBServer attributes to the Session List and supported filtering, facilitating quick troubleshooting.

• Monitoring and alert module:

  • Optimized the monitoring name, changing CPU Usage to Tenant CPU Consumption, and updated the data calculation logic to more accurately reflect tenant resource usage.
  • Added the Tenant Thread Usage 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 objects (such as clusters, tenants, OBProxy), facilitating object and task management.

• Operation Audit Module:

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

Key Feature Interpretation

Tenant-level IOPS Isolation

OceanBase Database V4.0 addresses the issue of disk contention between different tenants by virtualizing disk bandwidth (IOPS). It enables N tenants to operate as if they were running 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 information belongs to the tenant. This is divided into primary tenant and standby tenant. The concept of primary/standby roles no longer exists at the cluster level; instead, the cluster is merely a container for the tenant. 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 support deployment based on log archiving or network-based methods:

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 Oracle Database's Far Sync. The standby tenant interacts only with the log archive and does not engage in any other form of 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 MySQL Database's Replication. 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 deployment 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). These two log sources support automatic switching, which is transparent to the standby tenant and its 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 V4.2.0 and later.

Resource Isolation Within a Tenant

In OceanBase Database, the DBMS_RESOURCE_MANAGER system package of PL is used to manage resource allocation in the database and achieve resource isolation, but the overall configuration is relatively complex. OCP simplifies this configuration process through a highly refined 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 performing three steps: configuring a resource isolation plan, configuring a resource group, and applying resource isolation restrictions.

2. The semantics for viewing resource isolation metrics have been improved, such as the conversion between upper and lower limits and weights for CPU and IOPS, as well as 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 for OBProxy, allowing modification of some read-only parameters.

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

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

• Fixed the issue where host standardization failed in specific scenarios.

• Fixed the issue where the database name and username were 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 specific 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 × 810.