Version: 7.0.0

CM ​

Availability ​

This feature is available since openGauss 3.0.0.

Introduction ​

Cluster manager (CM) is a database management software, which consists of cm_server and cm_agent.

  • cm_agent is a database management component deployed on each database host. It is used to start, stop, and monitor database instance processes.
  • cm_server is a component used for managing database instances and arbitrating instances.

Benefits ​

It manages and monitors the running status of functional units and physical resources in a database system, ensuring stable running of the system.

Description ​

It supports customized resource monitoring and provides capabilities such as monitoring of the primary/standby database status, network communication faults, file system faults, and automatic primary/standby switchover upon faults. It also provides various database management capabilities, such as starting and stopping nodes and instances, querying database instance status, performing primary/standby switchover, and managing logs.

Enhancements ​

The CM supports external status query and push.

  • The HTTP/HTTPS service is used to remotely query the cluster status, helping management personnel and O&M platforms monitor the cluster status.
  • When an primary/standby switchover occurs in the database cluster, the latest primary/standby information of the cluster is pushed to the receiving address registered by the application through the HTTP/HTTPS service in time. In this way, the application can detect the primary/standby change of the cluster in time and quickly connect to the new primary and standby nodes.

The CM supports two-node deployment mode

  • The minimum number of nodes in the CM cluster is reduced from 3 nodes to 2 nodes, bringing significant cost advantages.
  • By introducing a third-party gateway IP, it effectively solves the self-arbitration problem in the two-node deployment mode of the CM cluster, and supports dynamic configuration of the CM cluster failover strategy and the database cluster split-brain fault recovery strategy, so as to ensure data integrity and consistency as much as possible.

The CM supports automatic cleanup of gstor archive logs (introduced in 7.0.0RC2)

  • Added automatic cleanup functionality for gstor archive logs. When the size of gstor archive logs exceeds 85% of the threshold (2G), the automatic archive log cleanup policy is triggered, and after cleanup, 15% of the threshold size is retained.

Constraints ​

Versions before 5.0.0, in scenarios where there are one primary node and one standby node, CM supports only basic capabilities, such as installation, startup, stop, and detection.

Dependencies ​

None.