OCP V4.2.0

V4.2.0 BP2

Version information

• Version: V4.2.0 BP2

• Previous version: V4.2.0 BP1

• Version release date: September 27, 2023

Bug fixes

• Fixed the issue where the autonomous service page cannot be accessed when an exception event occurs.

• Fixed the issue where an error occurs after clicking All after modifying the cluster parameters.

V4.2.0 BP1

OCP V4.2.0 BP1 supports seven scenarios for automatic recovery of OBServer and arbitration services, tenant and OBProxy scaling, and SQL-level throttling based on alert rules. It provides actionable emergency response plans based on alert rules and offers quick access to emergency response plans on mobile devices, thereby enhancing the stability of OceanBase Database services.

Version information

• Version: V4.2.0 BP1

• Previous version: V4.2.0

• Version release date: September 22, 2023

New features

• Provides actionable emergency response plans based on alert rules. The main features include:

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

    • In the scenario where OBServer and arbitration services crash, OCP automatically restarts OBServer and arbitration services (only once within 12 hours).

    • In the ob_tenant_request_queue_over_threshold alert scenario, OCP automatically scales up tenant CPU resources by 120%.

    • In the tenant_memstore_percent_over_threshold alert scenario, OCP automatically scales up tenant memory resources by 120%.

    • In the scenario where the client connection ratio of OBProxy exceeds the threshold, OCP automatically scales up client connections (client_max_connections) and memory (proxy_mem_limited) by 120%.

    • In scenarios where SQL execution plans are abnormal, SQL performance degrades, or CPU usage 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 such as "Feishu," "DingTalk," and "Enterprise WeChat." Users can quickly handle emergencies using their mobile devices.

  • Supports marking alerts with emergency response plans for quick query.

  • Supports recording and querying Open API calls for traceability.

  • Supports setting alert rules at the cluster, tenant, and OBServer levels.

• Adds tenant queue backlog alert capabilities to help users promptly identify and resolve tenant performance issues.

• Adds disk unavailability alerts to help users quickly detect hardware failures and avoid affecting normal business operations.

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

Security enhancements

• Proxyro@sys password security fix

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

• Root@proxysys password security fix

  Supports setting the password for the OBProxy administrator root@proxysys and adding compliance with the Level 3 security rules.

Bug fixes

• Optimizes data latency in monitoring drill-down.

• Optimizes the issue where OCP agent errors can cause the agent to exit.

• Fixes the issue where multiple identical alerts are sent in some scenarios in multi-node OCP.

V4.2.0

OCP V4.2.0 officially supports OceanBase Database V4.2.0 and OceanBase Database V4.x. It supports three major features of OceanBase Database V4.x: tenant-level physical primary-standby databases, resource isolation within a tenant, and IOPS isolation between tenants. In addition, OCP V4.2.0 supports custom deployment of OBServer, OBProxy, and arbitration service nodes, including user configuration and installation path. This meets the O&M management requirements of different users and improves the monitoring and alerting capabilities for OBProxy and arbitration service nodes, as well as the SQL diagnostic capabilities of the autonomous service module. OCP V4.2.0 also completes more than 20 usability optimizations, such as optimizing the CPU utilization at the tenant level and enabling automatic restart of OBServer and OBProxy services. These optimizations reduce the operational complexity for users and make it easier for them to manage and maintain OceanBase Database.

Version information

• Version: V4.2.0

• Previous version: V4.1.0

• Version release date: August 30, 2023

• Supported upgrade path:

  • You can directly upgrade from OCP V3.2.4 to the current version.

  • If you use OCP V2.3.x or earlier and earlier than V3.2.4, you must upgrade to OCP V3.3.4 first.

  • If you use OCP V2.3.0 or earlier, you must upgrade to OCP V2.3.x first, 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

• Limitations on log disk size and IOPS for tenants

  You can limit the log disk size and IOPS for tenants by using resource specifications (Unit).

• Management of physical standby tenants

  • You can build a primary-standby tenant pair by using archiving or networking (only supported in OceanBase Database V4.2.0 and later).
  • You can perform a daily switchover or disaster recovery failover between a primary and a standby tenant to meet the requirements of local and remote disaster recovery.

• Resource isolation within a tenant

  OCP provides the following three dimensions of resource control based on the features of OceanBase Database:

  • User resource isolation: You can limit the CPU and IOPS resources used by users based on the types of their applications.
  • Background task resource isolation: You can limit the resources used by eight types of background tasks, such as storage, migration, major compaction, and backup.
  • SQL resource isolation: You can limit the resources used by SQL statements by specifying WHERE clauses.

• New features in OceanBase Database V4.2

  • OCP V4.2.0 supports read-only replicas for tenants. In addition to universal replicas, OCP V4.2.0 supports read-only replicas.
  • You can reduce the number of resource units for a tenant.
  • You can start an OBServer node by specifying an IP address. This way, you can avoid selecting an incorrect IP address when multiple IP addresses are configured for a single network card.
  • You must specify the unit of capacity parameters such as memory_limit and system_memory. This way, you can avoid incorrectly configuring these parameters.
  • You can monitor the number of physical read I/O operations, the time consumed by these operations, and the traffic of incremental logs (Clogs). This way, you can diagnose the performance of the log disk in real time.
  • You can monitor the hit rate of five types of transaction table caches, such as SSTables, MEMTables, and KV caches. This way, you can diagnose the performance of transactions.
  • In the Resource Management > Unit Distribution section of a cluster, you can view the role and primary/standby status of a tenant.

Feature enhancements

• OceanBase Autonomy Service

  • When an exception occurs in a node (such as an abnormal CPU usage), OCP automatically performs SQL diagnostics at the node or cluster level.
  • You can create an optimization center. In the optimization center, you can review the top SQL statements in a specified period of time to see whether they can be optimized and how. You can also review the table and index structures corresponding to these SQL statements to see whether they can be optimized and obtain optimization suggestions.

• Monitoring and alerts

  • OCP supports five types of alerts for OBProxy: process status, connectivity, client connection count, server connection count, and memory usage. This enhances the end-to-end monitoring capabilities of OCP.
  • When a critical alert such as a server crash or CPU usage spike occurs, OCP automatically collects the failure information and downloads the report. This facilitates failure diagnosis based on the failure information.

• Installation and deployment

  • You can specify a user to install and deploy OBServer, OBProxy, and the arbitration node and their installation directories by using the ocp.operation.default.os.user system parameter. This meets the O&M management requirements of different enterprises.
  • You can use Systemd to automatically start OBProxy and OBServer after a host restart. This reduces manual operations and improves O&M efficiency.
  • You can specify the CPU architecture (x86 or ARM) of the software installation package. This reduces the probability of incorrect software package selection.

Feature optimizations

• Cluster management

  • In the Take over Cluster scenario, you can enter the proxyro password. This solves the problem of difficulty in taking over a cluster caused by inconsistent proxyro passwords.
  • The term root server is changed to root service in OceanBase Database.
  • In the Overview > System Events section, you can collect OBServer events. This facilitates troubleshooting.
  • The loading speed of the cluster management page is optimized. This enables O&M of large-scale clusters.

• Tenant management

  • The Tenant ID column is removed from the tenant list. The Cluster column is added to the tenant list. You can sort the tenant list by the Cluster column.
  • The OBServer attribute is added to the Session List. You can filter the session list by the OBServer attribute. This facilitates quick troubleshooting.

• Monitoring and alerts

  • The monitoring name CPU Utilization is changed to CPU Consumption of Tenant. The data calculation logic is updated to more accurately reflect the resource usage of a tenant.
  • The Thread Usage of Tenant monitoring metric is added. This facilitates quick identification of the running status of a tenant.
  • Based on industry standards, 10+ monitoring names are standardized. For example, IO Time is changed to Physical Read I/O Time in Tenant > Performance Monitoring > Storage and Cache, and Transactions per Second is changed to TPS in OBProxy Cluster > Service Monitoring.

• Inspection

  • The system parameters ocp.inspection.report.expired.days and ocp.inspection.report.expired.cleanup.enabled are added to control the expiration strategy of inspection reports. This reduces the disk space occupied by inspection reports.

• Major compaction management

  • When the system parameter enable_manual_merge is set to true, a prompt is displayed to inform you that you must manually perform a partition major compaction.

• Task management

  • You can jump between a task and its operation object, such as a cluster, tenant, or OBProxy. This facilitates O&M of objects and tasks.

• Operation audit

  • You can record the call information of Open APIs. This enhances security control.
  • You can associate an operation event of a single user with multiple resources, such as hosts and tenants.

Key features

Tenant-Level IOPS Isolation

In OceanBase Database V4.0, disk bandwidth (IOPS) is virtualized to address the issue of disk contention between tenants. This allows N tenants to run as if each were on a separate physical disk, achieving top-tier resource isolation for tenants. You can specify the maximum IOPS when creating a unit specification. All business requests under the corresponding user will then be subject to this IOPS limit, effectively isolating I/O between tenants.

Physical standby feature at the tenant level

Before OceanBase Database V4.1.0, clusters were either primary or standby. A standby cluster was a data backup of a primary cluster that ensured transaction consistency. A primary cluster automatically transmitted redo logs to a standby cluster, which then applied the redo logs. Data and schema were physically consistent between a primary and its standby cluster. Starting with OceanBase Database V4.1.0, physical standby instances were provided on a tenant level. A primary or standby role belongs to a tenant, which can be a primary tenant or a standby tenant. The cluster itself has no primary or standby role. Rather, it serves as a container for hosting tenants. A primary tenant is a business tenant created by a user. It supports complete database services, such as queries, DML, and DDL operations. A standby tenant supports only disaster recovery and read-only services. A primary tenant and several standby tenants form a high-availability solution for physical standby instances.

Physical standby database can be set up using log-based archiving and network-based methods:

1. Physical standby based on logs and archiving

   In a physical standby database based on log archiving, the physical standby database acquires redo logs from the archive logs of the primary tenant or another standby tenant. This is similar to the far sync feature in Oracle Database. The standby tenant interacts only with the archive logs and does not communicate with the primary or upstream standby tenants in any other form. In this deployment mode, the standby tenant does not need a network connection with the upstream tenant, but its synchronization performance and availability are affected by the archive log media.

2. Standby database on network

   In the online physical standby instance, the standby tenant directly connects to the primary tenant or other standby tenants over the network to read the logs, similar to MySQL replication. In this deployment mode, the network must be accessible between the standby tenant and the primary tenant. The standby tenant will send RPC requests over the network to read redo logs from the primary tenant cluster. To ensure high availability of the standby tenant in scenarios such as primary tenant node failure or log recycling, the standby tenant also requires limited access permissions to system views of the primary tenant. In this mode, the standby tenant can read either online logs or archived logs (if enabled for the primary tenant). The standby tenant supports automatic switching between the two log sources, without the need for manual intervention. This ensures transparency for both the standby tenant and business users.

OceanBase Database clusters have two types of tenant roles: PRIMARY and standby tenants. (STANDBY). You can dynamically change the tenant roles through routine switchover and disaster recovery switchover between the primary and standby instances.

1. Routine master-slave switching: allow the primary tenant to exchange roles with one of the slave tenants to ensure data is not lost.
2. In case of a primary-tenant unavailability, you can use a standby tenant as the primary tenant.

Limitations: This feature is supported in OceanBase Database V4.2.0 and later.

Resource isolation within a tenant

The DBMS_RESOURCE_MANAGER system package of PL is used in OceanBase Database to isolate resources and manage resource allocation within a database. However, this configuration is complex. OCP simplifies this process by offering user-level and SQL-level resource isolation.

1. Optimize the process for creating an Isolated Instance Plan, with three steps: configuring a resource isolation plan > configuring a resource group > setting up resource isolation limits, making it easy to create an Isolated Instance Plan.

2. Enhance the semantics for viewing resource isolation, such as CPU, IOPS upper and lower limits and weight conversion and SQL expressions.

3. Support dynamic adjustment of resource isolation plans, such as enabling, disabling, modifying, and deleting resource isolation plans.

Fixing the Bug

• Optimize the alerting experience when MetaDB is unavailable.

• Optimized the parameter settings of OBProxy and allowed modifications to some read-only parameters.

• Fixed the issue where the archive time parameter for alerts is not taking effect.

• Fix an issue where host monitoring alerts were not being recognized when being pushed to Prometheus.

• Fixed the issue of host standardization failure in specific scenarios.

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

Known issues

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:

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 OCP Server (including OCP-Agent) are as follows:

Client requirements

General users access OCP services through web browsers. The client requirements are as follows:

If you need to access OCP services from an iOS device, the minimum operating system version is as follows:

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