DEV Community

Cong Li
Cong Li

Posted on

GBASE数据库 | GBase 8a MPP Cluster - Cluster Manage Tool (1)

GBase Database (GBase数据库) is a high-performance, scalable, and distributed relational database designed to meet the demands of large-scale data processing and complex analytics.

Overview

gcadmin is a Linux command-line tool designed specifically for DBAs to manage and operate database clusters. By using the gcadmin <command> [parameter1[, parameter2...]] command, users can manage clusters, virtual clusters (VCs), nodes, distribution information, and synchronization logs, among other functions.

This article provides a detailed introduction to the main features and usage of the GBase 8a Cluster Management Tool, helping users understand the basic operations and scenarios where the tool can be applied.

Cluster Management

Cluster Status

GBase 8a supports using the cluster management tool to view the cluster status, displaying information such as the name, ID, distribution, remarks, coordinator node, and data node for all VCs in the current cluster.

Syntax:

gcadmin showcluster [c | vc vcname] [d] [g] [f]

Parameters:

  • c: Only display coordinator nodes when showing nodes.
  • vc_name: Specify the VC name to display; only one VC can be specified. If no VC is specified, information for all VCs will be shown.
  • d: Only display the corresponding data nodes. If no VC is specified, it shows the free nodes of the VC; if a VC is specified, it shows that VC’s data nodes.
  • f: Display the information in XML format.

Note:

  • In multi-VC mode, executing gcadmin showcluster vc is required to show the corresponding VC’s cluster mode information. If no VC is specified, the cluster mode will not be shown.
  • This requirement does not apply in compatibility mode.

The cluster status command provides the following information:

Image description

1. Cluster Working Status: ACTIVE

  • The ACTIVE state indicates the normal operational state of the cluster.
  • When the number of online coordinator nodes in the cluster is less than or equal to half of the total number of coordinator nodes, the gcware services will be disabled to protect data safety, and no database operations can be performed during this time.

2. Cluster Mode: NORMAL / READONLY / RECOVERY

  • Normal mode: The cluster is in a normal state, capable of performing all SQL operations.
  • Readonly mode: The cluster enters read-only mode during scaling, replacement, or backup operations. It allows DDL/DML/DQL operations, but DDL/DML operations will automatically execute after the mode returns to normal.
  • Recovery mode: This mode is used when performing cluster data recovery or in specific scenarios. No DDL/DML/DQL operations are allowed in this mode.

Note: The "Cluster Mode" is displayed only when viewing a specific cluster. Administrators can manually switch the cluster mode as needed.

3. Module Process Status: OPEN / OFFLINE / CLOSE / Failure / Unavailable

  • Open: The module is working normally.
  • Offline: The module process is offline, generally due to hardware failure. Investigate issues like sudden power loss or network disconnections.
  • Close: The module process failed to start or was unexpectedly closed. Common reasons include port conflicts, file permission issues, or configuration errors. Logs should be checked for the cause, and relevant processes should be restarted.
  • Failure: The node is marked as faulty, and no DML/DDL operations will be issued to that node. The events are recorded in the eventlog.
  • Unavailable: The node is marked as unavailable and must be replaced to restore its status.

Commands for viewing module process status:

  • gcluster_services all info
  • gcware_services all info

Cluster Service Process Status Management Commands:

  • gcluster_services <gcluster|gcrecover|gbase|syncserver|gbase_ip|syncserver_ip|all> <start|stop [--force]|restart [--force]|info>
  • gcware_services <gcware|all> <start|stop [--force]|restart [--force]|info>

Parameters:

  • force: Used to force stop a service process if it cannot be stopped normally (via kill -9 or kill -KILL).
  • info: Displays the current running status of the process.

4. Data Consistency Status: 0/1

  • 0: Data consistency is normal.
  • 1: Data is inconsistent (e.g., due to failed DDL/DML/loader operations).

Cluster Mode Switching

GBase 8a supports using the cluster management tool to switch cluster modes.

Syntax:

gcadmin switchmode <mode> [vc vc_name]

Modes:

  • [NORMAL], [READONLY], [RECOVERY]

Log Management

1. DDL & DDLEVENT Execution Mechanism

Image description

DDL is used to recover metadata. After recovery, gcrecover notifies gcware, which deletes the corresponding DDLEVENT.

Command to view DDLEvent error logs:

gcadmin showddlevent [<table_name segment_name node_ip>|<max_return_count>]

Parameters:

  • table_name: In the format dbname.tablename.
  • segment_name: The segment name of the table partition. For example, for a distributed table named t, the partition name on the first node is n1, on the second node it is n2, and so on.
  • node_ip: The IP of the node machine.
  • max_return_count: If not specified, the default is 16 rows. Additional events will not be shown.

2. DML & DMLEVENT Execution Mechanism

Image description

DML is used to recover user data. After recovery, gcrecover notifies gcware, which deletes the corresponding DMLEVENT.

Command to view DML event logs:

gcadmin showdmlevent [<table_name segment_name node_ip>|<max_return_count>]

Parameters: Same as for DDLEvent logs.

3. DMLSTORAGEEVENT Execution Mechanism

Image description

When a partition experiences physical damage or is lost, it is marked as a STORAGEEVENT. GBase 8a first sets a DMLEvent to attempt recovery. If recovery fails (e.g., due to missing tables or unreadable metadata), the event is upgraded to DMLStorageEvent.

The recovery process involves first using DDLEvent recovery, followed by DMLEvent recovery.

Command to view DMLStorageEvent logs:

gcadmin showdmlevent [<table_name segment_name node_ip>|<max_return_count>]

Parameters: Same as for DDLEvent logs.

4. Deleting FEVENT Logs

Before performing a node replacement, use this command to delete all FEVENT logs for nodes marked as unavailable (including DDL, DML, and DMLStorage FEVENT logs).

Syntax:

gcadmin rmfeventlog <ip>

Parameter:

  • ip: The IP of the node to delete FEVENT logs.

Note:

Be cautious when using this command. It should only be used during node replacement operations.

5. FAILOVER Mechanism

When the managing node fails and cannot complete an SQL operation, the takeover node will read the SQL execution information recorded in gcware and continue execution. This process is known as the failover mechanism for the managing node.

Command to display failover information:

gcadmin showfailover

The failover information contains the following fields: Commit ID, Database name, Table name, SCN number, Type, Create time, State, Original node, Takeover node, and Takeover count.

Image description

Note:

When a gcluster goes offline, all DDL and DML operations in progress will be picked up by available gclusters sequentially. Once the failover SQL is successfully executed and committed, it will be deleted from gcware.

6. Cluster Lock

When performing write operations (DDL/DML/Loader), a cluster lock must be acquired for the table before proceeding. Once the operation is complete, the lock is released.

Command to view existing locks in the cluster:

gcadmin showlock [f]

Optional parameter f: Displays lock information in XML format.

Image description

Parameters:

  • Lock name: The lock name in the format dbname.tablename.lock_name.
  • Owner: The IP of the lock owner.
  • Content: A remark describing the lock.
  • Create time: The time the lock was created.
  • Locked: True/False.
  • Type: Shared or exclusive lock.

Other

  • View running threads: show processlist
  • Kill thread: KILL [CONNECTION | QUERY] thread_id

    • CONNECTION: Default, used to terminate the specified thread_id thread.
    • QUERY: Abort the currently executing statement, but do not terminate the connection itself.

Virtual Cluster (VC) Management

1. Create VC

Syntax:

gcadmin createvc <create_vc.xml | e example_file_name>

Parameters:

  • create_vc.xml: Configuration file used to create the VC, including data node IP, VC name, and comment.
  • e example_file_name: Generate an example configuration file without creating a VC.

Note:

Before creating a VC, ensure the cluster is running normally, that free data nodes exist in the root cluster, and that multiple VCs cannot share GNODE nodes.

2. Delete VC

Syntax:

gcadmin rmvc <vc_name>

Note:

Before deleting a VC, manually delete its resource management information from the GBase database. The following tables store this information:

  • consumer_group, consumer_group_user, resource_plan, resource_pool, resource_plan_directive, resource_config, resource_pool_events, cluster_resource_pool_usage_history.

3. Start VC

Syntax:

gcadmin startvc <vc_name1 vc_name2 ...> <os_dba_user_name os_dba_password>

Note:

Multiple virtual clusters can be started simultaneously. The command must be executed using the dbaUser specified in the demo.options file, and the VC names must be provided when executing the command.

4. Stop VC

Syntax:

gcadmin stopvc <vc_name1 vc_name2 ...> <os_dba_user_name os_dba_password>

Note:

Multiple virtual clusters can be stopped simultaneously. The command must be executed using the dbaUser specified in the demo.options file, and the VC names must be provided when executing the command.

5. Import VC

This command imports another cluster into the current cluster, adding a new VC and several physical nodes for unified management.

Syntax:

gcadmin importvc [e] <config_file_name>

Parameters:

  • config_file_name: Command configuration file for importing the VC
  • e example_file_name: Generate a sample configuration file. If this parameter is used, the import will not be executed.

Note:

  • The imported cluster must be a virtual cluster version, and only one VC can be imported at a time.
  • The coordinator and data mixed nodes from the original cluster will become data nodes in the current cluster. All data nodes will join the new VC and generate the same shard distribution information as the original cluster.
  • Pure coordinator nodes from the original cluster will not be imported into the root cluster.

If you have any further questions or need additional assistance about GBase Database (GBase数据库), feel free to reach out!

Top comments (0)