OCP V4.2.0

#RNDate#2023-09-22

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 there are abnormal events.

• 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, including automatic startup of OBServer and arbitration services, tenant and OBProxy scaling, and SQL-level throttling, based on alert rules. It provides actionable emergency response solutions based on alert rules and offers quick access to emergency response features on mobile devices, thereby improving 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 solutions based on alert rules, with the following main features:

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

    • In the case of an OBServer or arbitration service crash, OCP automatically restarts the OBServer and arbitration service (only once within 12 hours).

    • In the case of a tenant request queue backlog (ob_tenant_request_queue_over_threshold alert), OCP automatically scales the tenant's CPU by 120%.

    • In the case of tenant memory exceeding the threshold (tenant_memstore_percent_over_threshold), OCP automatically scales the tenant's memory by 120%.

    • In the case of client connection ratio exceeding the threshold for OBProxy, OCP automatically scales the cluster-level client connections (client_max_connections) and memory (proxy_mem_limited) by 120%.

    • In the case of SQL execution plan exceptions, 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 "Feishu," "DingTalk," and "WeCom," allowing users to handle emergencies quickly from their mobile devices.

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

  • Supports recording and querying Open API calls for future reference.

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

• Adds tenant request queue backlog alerts to help users promptly identify tenant performance issues.

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

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

Security improvements

• Proxyro@sys password security fix

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

• Root@proxysys password security fix

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

Bug fixes

• Optimizes data latency in drill-down monitoring.

• 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 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. In addition, OCP V4.2.0 supports custom deployment of OBServer, OBProxy, and arbitration service nodes. It allows you to specify users and installation paths for these nodes to meet different O&M requirements. It also enhances monitoring and alerting capabilities for OBProxy and arbitration service nodes, and improves the SQL diagnostics capability of the autonomous service module. In terms of usability, OCP V4.2.0 provides 20+ optimizations, such as optimizing CPU usage at the tenant level and enabling automatic restart of OBServer and OBProxy services. These optimizations reduce the operational difficulty 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:

  • Only 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 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 features

OceanBase V4.x compatibility

• Tenant-level log disk size and IOPS isolation

  Resource specifications (Unit) are used to limit the log disk size and disk IOPS for tenants, enabling I/O isolation.

• Tenant-level physical standby management

  • Supports building primary-standby tenants using archiving-based and network-based methods (only available for OceanBase V4.2.0 and later).
  • Allows standby tenants to switch between primary and standby databases (Switchover) or fail over to a standby database (Failover) to meet local and remote disaster recovery requirements.

• Resource isolation within a tenant

  OCP leverages OceanBase Database's kernel features to provide resource management capabilities across three dimensions, enabling users to maximize resource utilization based on business needs.

  • User resource isolation: Limits CPU, IOPS, and other resources based on user application types.
  • Background task isolation: Limits resources for 8 types of background tasks, including dumps, migrations, compactions, and backups.
  • SQL resource isolation: Limits resources for specific SQL statements (e.g., those with specified WHERE conditions).

• OceanBase V4.2 features

  • Introduces tenant-level read-only replicas, allowing OceanBase Database to support both universal and read-only replicas in OCP V4.2.0.
  • Adds tenant-level unit scaling-in capabilities.
  • Supports starting OBServer by specifying an IP address, resolving issues with IP address selection in scenarios with multiple IPs on a single network card.
  • Requires unit information for capacity-related parameters (e.g., memory_limit, system_memory) to reduce the likelihood of incorrect configurations.
  • Monitors the number, duration, and traffic of incremental log (Clog) physical read I/Os, facilitating real-time log disk performance diagnostics.
  • Monitors 5 transaction table cache hit rates (e.g., SSTable, MEMTable, KV Cache) to assist with transaction-related performance diagnostics.
  • Displays tenant roles and primary/standby replica information in the Unit distribution section of the Resource management page.

Feature enhancements

• OceanBase Autonomy Service

  • Exposes cluster-level exceptions (e.g., node CPU anomalies) and performs SQL diagnostics at the node or cluster level.
  • Introduces an Optimization Center that supports reviewing TopSQL statements for optimization opportunities and analyzing table and index structures for potential improvements.

• Monitoring and alerts

  • Supports 5 alert capabilities for OBProxy processes, including status, connectivity, client and server connection counts, and memory usage, enhancing end-to-end monitoring.
  • Automatically collects and downloads reports for critical alerts (e.g., node downtime, CPU spikes), facilitating fault diagnosis.

• Installation and deployment

  • Allows customization of the installation user for OBServer, OBProxy, and arbitration nodes via the ocp.operation.default.os.user system parameter, accommodating different enterprise management standards.
  • Uses Systemd to automatically start OBProxy and OBServer after host restarts, reducing manual operations and improving efficiency.
  • Supports identifying the CPU architecture (X86 or ARM) of the software installation package, reducing the likelihood of incorrect package selection.

Feature optimizations

• Cluster management module:

  • Allows users to enter the proxyro password in the Take over Cluster scenario, resolving issues with cluster takeover due to inconsistent proxyro passwords.
  • Renames the OceanBase Database term "root server" to "root service".
  • Adds OBServer event collection to the Overview > System Events section for easier troubleshooting.
  • Optimizes the loading speed of the cluster management page to support large-scale cluster management.

• Tenant management module:

  • Optimizes the tenant list by removing the Tenant ID column and adding Cluster sorting.
  • Adds OBServer attributes to the Session List and supports filtering, facilitating quick issue diagnosis.

• Monitoring and alerts module:

  • Renames CPU Utilization to CPU Consumption of Tenant and updates the data calculation logic to more accurately reflect tenant resource usage.
  • Adds the Thread Usage of Tenant monitoring metric to help users quickly identify tenant runtime status.
  • Standardizes 10+ monitoring names based on industry standards, such as changing IO Duration to Physical Read IO Duration in Tenant > Performance Monitoring > Storage and Cache, and Transactions per Second to TPS in OBProxy Cluster > Service Monitoring.

• Inspection module:

  • Introduces the system parameters ocp.inspection.report.expired.days and ocp.inspection.report.expired.cleanup.enabled to control inspection report expiration policies, reducing disk usage.

• Compaction management module:

  • When the enable_manual_merge system parameter is set to true, clearly prompts users to manually perform partition compactions.

• Task management module:

  • Implements mutual navigation between tasks and their target objects (e.g., clusters, tenants, OBProxies), facilitating object and task management.

• Operation audit module:

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

Key Feature Breakdown

Tenant-Level IOPS Isolation

OceanBase Database V4.0 virtualizes disk bandwidth (IOPS) to address the issue of disk contention between tenants, providing an IOPS isolation capability similar to N tenants each operating on separate physical disks. You can specify the maximum IOPS when creating a unit specification, thereby limiting all business requests under that user to the specified IOPS, achieving I/O isolation between tenants.

Tenant-level physical standby database feature

OceanBase Database V4.1.0 adopts the tenant-based primary/standby mode instead of the primary/standby clusters mode before the V4.1.0. In the primary/standby clusters mode, there are two types of instances in a cluster: primary clusters and standby clusters. The standby cluster is a backup of the primary cluster in terms of data, and ensures the transaction consistency. The primary cluster automatically transmits redo logs to the standby cluster, and the standby cluster automatically applies the redo logs to ensure that the data and schema are physically consistent with those in the primary cluster. Starting from V4.1.0, the tenant-based primary/standby mode is adopted. In this mode, each instance belongs to a tenant. The tenants are categorized into primary tenants and standby tenants. An instance in a primary tenant plays the role of a primary instance in a cluster, and an instance in a standby tenant plays the role of a standby instance in the cluster. A cluster in this mode serves as a container to bear tenants only. A primary tenant is a business tenant created by a user. The primary tenants provide full database service capabilities, including querying, DML, DDL, and so on. A standby tenant provides only disaster tolerance and read-only capabilities. A primary tenant together with several standby tenants form a high-availability tenant-based physical standby solution.

You can use log archive-based or network-based method to build a physical standby database.

1. Physical standby database based on log archiving

   In a physical standby database based on log archiving, the redo logs for the physical standby database come from the log archives of the primary tenant or other standby tenants. Similar to Oracle's far sync, the standby tenant only interacts with the log archives and does not have any other form of interaction with the upstream primary or standby tenants. In this deployment mode, the standby tenant does not need to have a network connection to the upstream tenants. However, the synchronization performance and availability of the standby tenant are affected by the log archive media.

2. Physical standby database based on the network

   In a physical standby instance connected to the primary tenant through a network, the standby tenant directly reads logs from the primary tenant or other standby tenants through the network, similar to MySQL database replication. In this deployment mode, network communication between the standby tenant and the primary tenant is required. The standby tenant sends RPC requests through 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 cleanup, the standby tenant needs minimal query permissions for system views of the primary tenant. In this mode, the standby tenant can read either online logs or archived logs (if the primary tenant has enabled log archiving) from the primary tenant, with automatic switching between log sources, without affecting the standby tenant or business users.

The roles of tenants of an OceanBase cluster are divided into primary tenants (PRIMARY) and standby tenants. (STANDBY). You can dynamically change the tenant role by performing routine primary/standby database switching or disaster recovery (DR) switching.

1. Daily switchover between primary and standby clusters: Allows the roles between the primary and a standby cluster to be exchanged, ensuring data is not lost.
2. Standby-to-primary tenant switchover: If the primary tenant is unavailable, you can switchover a standby tenant to the primary tenant.

Limitations: Only OceanBase Database V4.2.0 and later is supported.

Tenant-based resource isolation

In OceanBase Database, resources are allocated and managed using the DBMS_RESOURCE_MANAGER package provided by PL, achieving resource isolation. However, the overall configuration complexity is high. OCP simplifies the user configuration process through highly refined methods, enabling resource isolation at both the user level and SQL level.

1. Simplify the creation process: In three steps – configure resource isolation plans > configure resource groups > limit resource isolation, you can create resource isolation plans with ease.

2. Optimize the viewing of user semantics in resource isolation, such as CPU upper and lower limits, IOPS weight, and SQL expressions.

3. Enables dynamic management of resource isolation plans such as enabling, disabling, modifying, and deleting them.

Fix defects

• Improved the display of alerts when MetaDB is unavailable.

• Optimized the OBProxy parameter configurations and opened the modification for some read-only parameters.

• Fixed the issue where the alert archive time parameter was not taking effect.

• Fix an issue where host metrics pushed to Prometheus are not recognized.

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

• Fixed the issue where the database and username occasionally differ 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 following table lists the minimum hardware requirements for OCP-Server nodes.

OCP-Agent occupies very little resources and has no special requirements for 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 access OCP services through a web browser. The following table lists the client requirements.

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

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