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 could not be accessed when an exception event occurred.

• Fixed the issue where an error occurred when the All button was clicked after modifying the cluster parameters.

V4.2.0 BP1

OCP V4.2.0 BP1 supports seven scenarios for automatic recovery, including automatic recovery of OBServer and arbitration services, tenant and OBProxy scaling, and SQL-level throttling. It provides operational 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

• Release date: September 22, 2023

New features

• Provides operational emergency response solutions based on alert rules. The main features include:

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

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

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

    • In the case where the tenant_memstore_percent_over_threshold alert is triggered, OCP automatically scales the memory resources of the tenant by 120% by default.

    • In the case where the client connection ratio of OBProxy exceeds the threshold, OCP automatically scales the client_max_connections and proxy_mem_limited resources of the cluster by 120% by default.

    • In scenarios such as abnormal SQL execution plans, declining SQL performance, and 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 such as "Lark", "DingTalk", and "WeCom", allowing users to quickly handle emergencies via mobile devices.

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

  • Supports recording and querying Open API calls for traceability.

  • Supports setting alert features 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 impacting 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 improvements

• 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 to a random password.

• Root@proxysys password security fix

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

Bug fixes

• Optimizes data latency during 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 the three major features of OceanBase Database V4.x: tenant-level physical primary-standby, resource isolation within a tenant, and IOPS isolation between tenants. In addition, OCP V4.2.0 allows you to customize the users and installation paths of OBServer, OBProxy, and arbitration service nodes to meet the O&M requirements of different users. It also enhances the monitoring and alerting capabilities for OBProxy and arbitration service nodes and the SQL diagnostic capabilities of the autonomous service module. OCP V4.2.0 also optimizes usability in 20+ aspects, such as optimizing the CPU usage at the tenant level and enabling automatic restart of OBServer and OBProxy services. This reduces the operation difficulty for users and makes 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:

  • Direct upgrade from OCP V3.2.4 and later to the current version is supported.

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

  • For 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 versions of OceanBase Database:

• 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 size of log disks and disk IOPS for tenants, enabling I/O isolation.

• Tenant-level physical standby database management

  • Supports building primary-standby tenants using archiving-based and network-based methods (only available in OceanBase V4.2.0 and later).
  • Supports daily switchover and disaster recovery failover for standby tenants to meet local and remote disaster recovery scenarios.

• Resource isolation within a tenant

  OCP leverages OceanBase'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 for users based on their application type.
  • Background task isolation: Limits resources for 8 types of background tasks, including storage, migration, major compactions, and backups.
  • SQL resource isolation: Limits resources for specific SQL queries (e.g., those with specified WHERE conditions).

• OceanBase V4.2 features

  • Added tenant-level read-only replicas, allowing OceanBase to support both full-featured and read-only replicas in OCP V4.2.0.
  • Added tenant-level unit scaling-in capability.
  • Supports starting OBServer by specifying an IP address to resolve IP address selection issues in scenarios with multiple IPs on a single network interface.
  • Requires unit information for capacity-related parameters like memory_limit and system_memory, reducing the likelihood of incorrect parameter configuration.
  • Supports monitoring the number of physical reads, time spent, and traffic for incremental logs (Clog), facilitating real-time log disk performance diagnostics.
  • Supports monitoring 5 transaction table cache hit rates (e.g., SSTable, MEMTable, KV Cache) to assist with transaction-related performance diagnostics.
  • In the Resource Management > Unit Distribution section of the cluster, units display tenant roles and primary/replica information.

Feature enhancements

• OceanBase Autonomy Service

  • Exposes cluster-level exceptions (e.g., node CPU anomalies) and performs SQL diagnostics at the node or cluster level.
  • Introduced an Optimization Center that supports reviewing TopSQL queries within a specified time period to identify optimization opportunities. It also allows reviewing table and index structures for potential optimizations.

• Monitoring and alerts

  • Supports 5 alert capabilities for OBProxy processes, including process status, connectivity, client and server connection counts, and memory usage, enhancing end-to-end monitoring.
  • Supports automatically collecting fault information and downloading reports in critical scenarios like cluster downtime or CPU spikes, facilitating fault diagnosis.

• Installation and deployment

  • Allows custom user installation and deployment of OBServer, OBProxy, and arbitration nodes using the ocp.operation.default.os.user system parameter, meeting diverse enterprise management requirements.
  • Supports automatic startup of OBProxy and OBServer after host restart via Systemd, reducing manual operations and improving O&M efficiency.
  • Supports identifying the CPU architecture (X86 or ARM) of software installation packages, reducing the likelihood of incorrect package selection.

Feature optimizations

• Cluster Management Module:

  • In the Take over Cluster scenario, supports entering the proxyro password to resolve cluster takeover issues caused by inconsistent proxyro passwords.
  • Optimized OceanBase Database terminology: Changed "root server" to "root service".
  • Added OBServer event collection in Overview > System Events, facilitating issue troubleshooting.
  • Optimized cluster management page loading speed to support large-scale cluster management.

• Tenant Management Module:

  • Optimized tenant list by removing the Tenant ID column and adding Cluster sorting.
  • Added OBServer attribute and filtering support in the Session List, facilitating quick issue diagnosis.

• Monitoring and Alerts Module:

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

• Inspection Module:

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

• Major Compaction Management Module:

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

• Task Management Module:

  • Implemented mutual navigation between tasks and operation objects (e.g., clusters, tenants, OBProxies) to facilitate 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 Insights

IOPS isolation at the tenant level

OceanBase Database V4.0 virtualizes the IOPS of a disk, thereby solving the disk contention issue between tenants. This means that you can deploy multiple tenants each on a disk. Therefore, OceanBase Database V4.0 provides the strongest resource isolation capability for tenants. When you create a Unit specification, you can specify the maximum IOPS. Therefore, all business requests of a corresponding user are subject to the IOPS, achieving I/O isolation between tenants.

Physical standby for tenant-level replication

OceanBase Database V4.1.0 has two types of nodes: primary nodes and standby nodes. A standby node is a data copy of the primary node and guarantees transaction consistency. Redo logs are automatically transmitted from the primary node to the standby node and then applied by the standby node. The data and schema are physically consistent on the primary and standby nodes. Starting from V4.1.0, physical standby databases have been transformed to tenant-level standby databases. That is, each tenant can be a primary or standby tenant. A cluster only serves as a container for tenants. A primary tenant is a user-created business tenant and provides complete database services, such as query, DML, and DDL operations. A standby tenant provides only disaster recovery and read-only services. A primary tenant and several standby tenants together form a tenant-level high-availability solution.

Physical standby databases can be built either through log archiving or via network:

1. Physical standby database based on log archiving

   In a physical standby instance of an archive-based physical standby instance, the Redo logs of the physical standby instance are obtained from the archive logs of the primary tenant or another standby tenant. This is similar to the Far Sync feature in an Oracle database. In this case, the standby tenant only interacts with the archive logs and does not communicate with the primary or other standby tenant. In this deployment mode, the standby tenant does not require a network connection to the upstream tenant. However, its synchronization performance and availability are affected by the archive media.

2. Physical standby database based on a network

   In this mode, the standby tenants connect to the primary tenant or other standby tenants over the network to directly read logs. This is similar to the replication mechanism in a MySQL database. In this deployment mode, the standby tenants and the primary tenant must be connected through a network. To ensure high availability of the standby tenants in scenarios such as primary tenant node failure or log recycling, the standby tenant requires read permissions on system views from the primary tenant. This mode allows the standby tenants to read either online logs or archived logs (if log archiving is enabled for the primary tenant) from the primary tenant. This log source switch is transparent to both standby tenants and business users.

A tenant can be a primary tenant or a standby tenant. (standby). You can change the tenant role dynamically through daily switching between the primary and standby databases and disaster recovery switching between the primary and standby databases.

1. Routine active-standby switch: allows the tenant in the primary tenant group to exchange roles with a tenant in the standby tenant group, ensuring that no data is lost.
2. Primary/Standby Tenant Disaster Switch: If the primary tenant is unavailable, it can be switched to a standby tenant.

Product limit: OceanBase Database V4.2.0 or later is supported.

Resource isolation within tenants

OceanBase Database implements resource isolation by using the DBMS_RESOURCE_MANAGER system package of PL to manage resource allocation. However, the overall configuration process is complex. OCP provides a refined solution that simplifies the configuration process and enables resource isolation at both the user level and the SQL level.

1. Optimize the creation process with a three-step approach: configure the resource isolation plan > configure the resource group > apply resource isolation restrictions, making it easy to set up resource isolation plans.

2. Optimize the resource isolation display user semantics, such as CPU and IOPS upper and lower limits and weights of resources and SQL expressions.

3. You can dynamically manage resource isolation plans, such as enabling, disabling, modifying, and deleting a resource isolation plan.

Fixing defects

• Optimize the behavior of MetaDB unavailable alert.

• Optimized OBProxy parameter configurations and allowed modification of some read-only parameters.

• Fixed issue where the archived time parameter for alerts was not taking effect.

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

• Fixed a bug that caused the host standardization to fail in some scenarios.

• Fixes a problem where the database name and user name occasionally do not match 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 shown in the following table.

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

Operating system requirements

The following table lists the operating systems that support OCP-Server (including OCP-Agent).

Client requirements

General users access OCP services through a web browser. The following table lists the minimum versions of the browsers.

If you want to access OCP services from an iOS device, the minimum version of the operating system is shown in the following table.

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