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:
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 (viakill -9
orkill -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
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 isn1
, on the second node it isn2
, 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
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
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.
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.
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 specifiedthread_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)