GridDB operation control guide

A list of parameters is available to control the GridDB service operations. By default, nodes and cluster are configured to start and stop when the OS is started and stopped respectively.

A list of the parameters is given below.

To change the parameters, edit the start configuration file ( /etc/sysconfig/gridstore/gridstore.conf ).

When a server package is updated or uninstalled, the start configuration file will not be overwritten or uninstalled.

[Points to note]

• Do not directly edit a parameter described in service script. The edited file will be lost when the server package is uninstalled or updated. When changing the parameters, edit the start configuration file.
• When composing a cluster with multiple nodes, use the same parameter file for each node to be attached to the cluster. In particular, if a cluster is expanded by an operation control command, command interpreter, etc. during system operation, the parameter MIN_NODE_NUM of all the nodes needs to be changed to the number of nodes constituting a cluster after the expansion.

See the boot log( /var/log/boot.log ) and operating command log( $GS_HOME/log ) for details of the service log.

Action:

• Start a node and join to a cluster.

  # service gridstore start
  

• This function executes gs_startnode command to start a node and gs_joincluster command to join to a cluster.
• When the gs_startnode command is executed, the system waits for the recovery process to end.
• When the gs_joincluster command is executed, the system doesn't wait for the cluster to start operation.
• Set the cluster name in CLUSTER_NAME .
• Set the number of nodes constituting a cluster in MIN_NODE_NUM .

[Points to note]

• If an error occurs in the middle of a cluster operation, the gsserver process will be stopped.

Action:

• Leave from a cluster and stop a node.

  # service gridstore stop
  

• End if there are no more processes, and error if the timeout time has passed (termination code 150).
• If there are no processes started by the service, termination code 0 will be returned.
• This function executes gs_leavecluster command to leave a node from a cluster before stopping a node.
• When the gs_leavecluster command is executed, the system waits for the node to leave from the cluster.
• A node stopping process will be performed regardless of the termination code of the gs_leavecluster command.

[Points to note]

• When stopping the cluster, execute the gs_stopcluster command and leave/stop each node by a service stop. If you do not stop the cluster with the gs_stopcluster command, autonomous data arrangement may occur due to node leaving. If data relocation happens frequently, network or disk I/O may become a load. If you leave the node after stopping the cluster, data arrangement will not occur. To prevent unnecessary data arrangement, please use the gs_stopcluster command when stopping the cluster.
• A node started by an operating command or command interpreter (gs_sh) cannot be stopped by a service stop. Use the respective tools to stop the node.

Action:

• Display whether the node process is under execution or not.

  # service gridstore status
  

Action:

• Stop and start continuously.

Action:

• Restart if there is a lock file.

If the GridDB node abnormally terminates or the node process is forcibly terminated, it will automatically restart the node and join to the cluster. Operation manager does not need to be aware of restoring the cluster status to normal operation.

[Points to note]

Automatic restart is not performed in the following cases:

• In case of the user explicitly turns it off.
• In case of an unrecoverable failure (Node status: ABNORMAL).
• In case of trying automatic restart more than 5 times.
• In case of the node is not joined to the cluster before the failure.

The parameters of automatic recovery function is as follows.

To change the parameters, edit the start configuration file ( /etc/sysconfig/gridstore/gridstore.conf ).

SVC_ENABLE_AUTO_RESTART

• Set whether to enable or disable this function.
• This parameter can be changed by restarting the node.
• If you want to control GridDB's fault recovery with another monitoring system, set false.

GS_USER/GS_PASSWORD

• Set the GridDB administrator user name and password.
• These parameters are used in the following cases:
  • a. In case of starting, stopping, restarting by service
  • b. In case of the -u option is not specified with the gs_startnode

[Points to note]

• If the specified GS_USER / GS_PASSWORD is invalid, or if these are not specified, the GridDB node will fail to start up.

gs_admin needs to be installed on a machine in which nodes constituting a cluster have been started, or in a machine on the network with the same subnet and multicast distribution.

Install the GridDB client package (griddb-xx-client-X.X.X-linux.x86_64.rpm).

Log into a machine installed with the Web application as a root user, and install the package using the command below.

# rpm -Uvh griddb-xx-client-X.X.X-linux.x86_64.rpm

(*) xx indicates the GridDB edition. (se, ae, ve)

(*) X.X.X indicates the GridDB version.

When a client package is installed, a directory named admin is created in the GridDB home directory ( /var/lib/gridstore/admin ). This directory ( /var/lib/gridstore/admin ) is known as adminHome hereinafter.

gs_admin configuration data and data used by gs_admin are installed in adminHome. As there are functions in gs_admin to operate adminHome files, the appropriate rights need to be set. Rights settings will be described later.

The configuration under adminHome is as follows.

capture/                                                # snapshot storage directory (*)
        [Node address]_[port no.]/YYYYMMDDHHMMSS.json   # snapshot file (*)
conf/                                                   # configuration file directory
     gs_admin.properties                                # static parameter file to be configured initially
     gs_admin.settings                                  # dynamic parameter file to configure display-related settings
     password                                           # gs_admin user definition file
     repository.json                                    # node repository file
log/                                                    # log file directory of gs_admin (*)
    gs_admin-YYYYMMDD.log                               # log file (*)
tree/                                                   # structural file directory of container tree (*)
     foldertree-[cluster name]-[user name].json         # folder tree file (*)

Files and directories marked with a (*) are created automatically by gs_admin.

[Points to note]

• Files and directories under adminHome will not be deleted even if the client package is uninstalled. Manually delete the files if they are not required.

gs_admin is a Web application that runs on Tomcat. To use gs_admin, there is a need to deploy the gs_admin war file in Tomcat. Tomcat settings are omitted in this section.

The deployment procedure is as follows.

Deploy the war file included in the GridDB client package (griddb-xx-client-X.X.X-linux.x86_64.rpm) in Tomcat.

When a client package is installed, war file is installed under the following directory.

• /usr/griddb/web/gs_admin.war

Copy gs_admin.war to the webapps directory under the Tomcat installation directory.

$ cp /usr/griddb/web/gs_admin.war [Tomcat installation directory]/webapps

When using gs_admin, perform authentication as a gs_admin user.

Administrator users of GridDB clusters under management need to be set up as gs_admin users.

The gs_admin user definition file is found in /var/lib/gridstore/admin/conf/password .

This file will not be created when a client package is installed.

To use this easily, copy the user definition file of the node in the cluster you want to manage ( /var/lib/gridstore/conf/password ) to the gs_admin user definition file ( /var/lib/gridstore/admin/conf/password ). In this case, all administrator users listed in the copied user definition file will become gs_admin users.

[Memo]

• See User management for details about user management in GridDB.
• See Managing multiple clusters if you want to manage multiple clusters in gs_admin.

The configuration file is found in /var/lib/gridstore/admin/conf/gs_admin.properties . Set together with the GridDB cluster configuration as a gsadm user.

Reload the Web application if the property file has been overwritten.

gs_admin.properties contains the following settings.

[Memo]

• When installing GridDB, gsadm is registered as an OS user to use GridDB. As no password has been set up in a gsadm user, a password needs to be set up in advance if you want to set up ospassword in gs_admin.

Node repository files are files to centrally manage cluster configuration data and node data ( /var/lib/gridstore/admin/conf/repository.json ). They are used to specify cluster under management and cluster operation functions. Set together with the GridDB cluster configuration as a gsadm user.

The default file contents are as follows.

{
    "header" : {
        "lastModified" : "",
        "version" : "2.7.0"
    },
    "clusters" : [
        {
            "name" : "INPUT_YOUR_CLUSTER_NAME_HERE",
            "address" : "239.0.0.1",
            "port" : 31999,
            "jdbcAddress" : "239.0.0.1",
            "jdbcPort" : 41999
        }
    ],
    "nodes" : [
        {
            "address" : "192.168.1.10",
            "port" : 10040,
            "sshPort" : 22,
            "clusterName" : "INPUT_YOUR_CLUSTER_NAME_HERE"
        }
    ]
}

To configure a node repository, either edit the file directly or use the repository management screen. When configuring using the repository management screen, see the functions on the repository management screen and Starting management of a cluster in operation with gs_admin (recommended).

Use of the operation control command or command interpreter (gs_sh) is recommended when performing cluster configuration for the first time.

Files and directories are created automatically by gs_admin under adminHome. As a result, a Tomcat execution user requires read and write rights to adminHome. Therefore, owners of files and directories under adminHome are changed to Tomcat execution users (tomcat by default) beforehand.

Change the owner as a root user.

# chown -R tomcat:tomcat /var/lib/gridstore/admin

[Memo]

• The default directory of adminHome is /var/lib/gridstore/admin but this can be changed by changing the Web application settings. Change the value of adminHome in /webapps/gs_admin/WEB-INF/classes/conf/gs_adminPath.properties under the Tomcat home ( /usr/local/tomcat by default).

[Points to note]

• When upgrading the gs_admin version, gs_adminPath.properties is recreated when the war file is reinstalled. The value of gs_adminPath.properties needs to be reset if it is going to be changed in the operations.

Access the application URI below to access gs_admin.

http://[Tomcat operating machine address]:8080/gs_admin

he login screen appears when you access the gs_admin application URI.

In the log-in screen, you can choose from 2 different environment; cluster or repository manager. In the former option, you need to select the cluster that you would like to manage from the drop-down list. Once logged in, you will be taken to the Integrated operation control screen

On the other hand, for the latter option, you will be taken to the Repository management screen.

When logging in, enter the user name and password of the gs_admin user in the user and password box respectively, and click the Login button.

[Memo]

• The port no. of the Tomcat operating machine differs depending on the environment. Default port is 8080.
• It is possible to log into the integrated operation control screen even if the node has not been started.

The integrated operation control screen is shown below.

The integrated operation control screen is made up of the following elements.

Tree function

In Tree, a cluster or container can be selected as the main operation target by switching tabs at the top.

View function

In View, the tab displayed at the top of View differs for each operating target selected in Tree. The function can be switched by selecting the tab at the top.

See the items of each tree and screen for details.

This function can be used by a gs_admin administrator user only.

Select repository manager in the login screen and login as a gs_admin administrator user to arrive at the repository management screen.

The repository management screen is shown below.

The following functions are available in the repository management screen.

• Displaying repository data
  • Display of the node repository file ( /var/lib/gridstore/admin/conf/repository.json ) is divided into 2 sections. The top half of the screen shows the cluster data, whereas the bottom half displays the node data.
• Editing repository data
  • Any changes/edit in the repository data will not be applied unless it is saved.
  • To add clusters and nodes to the repository, enter the cluster and node data in the boxes provided, and click the Add button.
    • A cluster cannot be added or replaced when the cluster name is duplicated.
    • A node cannot be added or replaced when the combination of the IP address and port is duplicated.
  • Replace and Delete can be performed by selecting a row in the table.
    • Upon selecting a row, the contents of the row will be copied to the input column.
    • Multiple rows cannot be selected.
  • Besides the cluster name, one of the following data is required to add or replace a cluster depending on the cluster connection method.
    • If the cluster connection method is "MULTICAST": multicast address, multicast port
    • If the cluster connection method is "FIXED_LIST": connection destination list of the fixed list method
    • If the cluster connection method is "PROVIDER": provider URL of the provider method
  • IP address and port are required to add or replace a node.
  • When deleting a cluster, if there are registered nodes in the deleted cluster after deletion, a dialog to confirm deletion of the cluster from these nodes will appear. Select Yes to delete.
• Cluster synchronization
  • Data of a cluster in operation can be acquired and registered in a repository.
  • Click the Sync button to display the dialog for inputting the IP address and port. Enter the IP address and port of any node constituting the cluster here, select Sync, and click Yes in the confirmation dialog to overwrite and update the display in the repository management screen.
    • The specified node need not be a master node.
    • Specify /system/serviceAddress of the node definition file (gs_node.json) as the IP address.
    • Specify /system/servicePort of the node definition file (gs_node.json) as the port.
    • SSH port is registered as 22 by default.
• Updating repository data
  • Click the Refresh button to import the node repository file again.
  • Unsaved contents will be discarded.
• Saving repository data
  • Click the Save button to save the contents displayed on the screen.
  • As long as the data is not saved yet, no changes will be made to the node repository file.

The specifications of the input column are as follows.

Cluster

• Cluster name (Name)
  • Specify /cluster/clusterName of the cluster definition file (gs_cluster.json).
• Cluster connection method (Notification Mode)
  • Select one of the following from the drop-down box
    • Multicast method: MULTICAST
    • Fixed list method: FIXED_LIST
    • Provider method: PROVIDER
• Multicast address (Multicast Address)
  • Specify /transaction/notificationAddress of the cluster definition file (gs_cluster.json).
  • Must be specified when using the multicast method.
• Multicast port (Multicast Port)
  • Specify /transaction/notificationPort of the cluster definition file (gs_cluster.json).
  • Must be specified when using the multicast method.
• JDBC address (JDBC Address)
  • Specify /sql/notificationAddress of the cluster definition file (gs_cluster.json).
  • Specify when using the multicast method. (optional)
  • This is necessary when using the SQL screen in the GridDB Advanced Edition.
• JDBC port (JDBC Port)
  • Specify /sql/notificationPort of the cluster definition file (gs_cluster.json).
  • Specify when using the multicast method. (optional)
  • This is necessary when using the SQL screen in the GridDB Advanced Edition.
• Connection destination list of fixed list method (Transaction Member)
  • Combine the /cluster/notificationMember/transaction/address and /cluster/notificationMember/transaction/port in the cluster definition file (gs_cluster.json) with a “:” and specify the value of each node by separating them with a comma.
  • Example: 192.168.10.1:10001,192.168.10.2:10001,192.168.10.3:10001
• Connection destination list of fixed list method (SQL Member)
  • Combine the /cluster/notificationMember/sql/address and /cluster/notificationMember/sql/port in the cluster definition file (gs_cluster.json) with a “:” and specify the value of each node by separating them with a comma.
  • Example: 192.168.10.1:20001,192.168.10.2:20001,192.168.10.3:20001
• Provider URL of provider method (Provider URL)
  • Specify /cluster/notificationProvider/url of the cluster definition file (gs_cluster.json).
  • This is necessary when using the provider method.

Node

• Cluster
  • Select a registered cluster in the selection box.
• IP Address
  • Specify /system/serviceAddress of the node definition file (gs_node.json).
• Port
  • Specify /system/servicePort of the node definition file (gs_node.json).
• SSH Port
  • Specify the SSH port of the machine with operating nodes. Default port is 22.

Summary

In a cluster tree, the nodes constituting a cluster under management, i.e the repository nodes (clusterName is the cluster under management) are displayed in a tree format.

An * will appear at the beginning of a node which has not been registered in the repository.

A description of the icons shown in a cluster tree is given below.

Icon	Description
	Cluster
	Master node
	Follower node
	Started node
	Stopped node
	Status unconfirmed node
	Message

Context menu

When an element of the tree is right clicked, a context menu appears according to which element is clicked, cluster or node. Data update and element operation can then be performed by selecting an item from the menu.

The menus and functions for the respective selected elements are as follows.

Operating target and view tab

When an element in the tree is left clicked, the functions appear in the View according to which element is clicked, cluster or node. The function can be changed by tapping the top section of the View.

[Memo]

• If the master node of a cluster is changed, re-acquisition of the node list may fail. Log out once first before logging in again.

Summary

The dashboard screen contains a variety of information related to the entire cluster such as memory usage, cluster health, log information, etc.

Method of use

Screen

Functions

The following functions are available in the dashboard screen.

• Total volume of data in the cluster (◆Total Stored)
  • Display the total volume of data in the cluster along with its unit. (KB - TB)
  • The % of the total volume of data saved in the memory is also displayed.
• Total amount of memory used (◆Memory Usage)
  • The utilization rate of memory is displayed on a pie chart.
• Cluster health (◆Cluster Health)
  • Display the proportion of operating nodes and non-operating nodes on a pie chart.
• Network connection in a cluster (◆Current Connections)
  • Display the current connection, session and number of transactions of the cluster on a bar chart.
• Number of cluster events (in the past 5 minutes) (◆Event Count)
  • Display the read command, write command, swap read, swap write and event count of the lock bids which occurred in the past 5 minutes in a cluster.
  • *Past 5 minutes refers to the past 5 minutes starting from the time the latest performance data is output to the log.
• Log analysis data (◆Log Information)
  • Display the WARNING and ERROR logs of each node constituting a cluster.
  • Move and hover the cursor to the icon on the far left to display detailed data of the target log.

Summary

The cluster status screen displays the current cluster's and node's configuration data and information such as the cluster's name, active node count, number of partitions, and the node's IP address, etc., as shown below.

Method of use

Screen

Functions

The cluster status screen is comprised of the following components.

• Cluster data display (◆Cluster Information)
  • Display the following data acquired from a master node.
    • Cluster name, operation node number, number of nodes constituting a cluster, partition status, multicast address and port
• Data-related information display (◆Stored Data Information)
  • Display the following data acquired from a cluster.
    • No. of partitions, total no. of containers
• Display data on nodes constituting a cluster (◆Node Information)
  • Display the following data of each node.
    • IP address and port, node status, cluster status, composite status, node version
    • Composite status is the status of a node displayed on the cluster operation screen.

Summary

The OS data display screen is comprised of two components, Resource Information and OS Performance of the current cluster. The GridDB performance analysis, and the CPU and Network load status are displayed by pie charts and line graphs respectively.

Method of use

Screen

Functions

The OS data display screen is comprised of the following components.

• Display resource Information of a node (◆Resource Information)
  • Display the following data acquired from a node.
    • CPU utilization rate
    • Memory, swap memory capacity, utilization rate
    • Capacity of data directory and backup directory, disk utilization rate
• OS performance data display (◆OS Performance)
  • Click the Start button to get the performance data from the node at the specified cycle interval and draw 2 graphs.
    • CPU utilization rate
    • Network transfer volume

[Memo]

• This function cannot be used if the ospassword has not been set up in gs_admin.properties.
• This setting is necessary in order to connect to the node execution environment from the gs_admin execution environment as an OS user “gsadm”. See the manual of each OS for details on the SSH connection procedure.

This function can be used by the gs_admin administrator only.

Summary

The cluster operations screen consists of a list of table of the running nodes, as well as the start and end node features.

Method of use

Screen

Functions

The following functions are available in the cluster operation screen.

• Displaying list of nodes
  • The cluster operation screen can display three of the following types of nodes, which have been registered to the repository:
    • Nodes that constitute the actual cluster (displayed at the top of the table)
    • Nodes that have been allocated to the current (being managed) cluster but do not constitute (not yet configured to) the actual cluster
    • Nodes that have NOT been allocated to any cluster
• Displaying node data
  • The following data is available for each of the nodes.
    • Cluster registration status (check box)
    • Role in the cluster (Role)
    • IP address and port, and SSH port
    • Node status
  • The cluster registration status indicates whether the nodes are registered in the current cluster.
  • There are 3 types of role - master node (M), follower node (F), and unassigned role (-).
  • Node status appears only for the nodes that constitute the actual cluster, and the nodes that have been allocated to the current (being managed) cluster but do not constitute (not yet configured to) the actual cluster
• Registration and removal of nodes
  • *Contents of a node repository are edited by this function.
  • Click the check box next to the cluster registration status to register or delete a node to/from a cluster.
  • In this screen, only nodes that have been registered into a cluster can be operated.
  • When a cluster is in operation, the check box is disabled.
• Cluster operations components
  • Start cluster
    • Compose a cluster with all the nodes registered in the cluster.
    • This command can be executed only when the node status of all the nodes is STARTED.
  • Stop cluster
    • Stop a cluster in operation.
    • This command can be executed only when the cluster is in operation.
• Node operations components
  • Executable operating buttons will appear in the operations column of each node.
    • Display buttons differ depending on the node status.
  • Starting a node (Start)
    • Start a node which has been stopped (status STOPPED)
  • Joining a cluster (Join)
    • Add or re-add a node to a cluster.
  • Leave a cluster (Leave)
    • Remove a node from the active cluster.
  • Increase the number of nodes in a cluster (Append)
    • Increase the no. of nodes of the active cluster.
  • Stopping a node (Stop)
    • Stop the node in operation.
    • Cannot be executed while a cluster is operating. Stop the node after removing it from the cluster.

[Memo]

• To start a node, this setting is necessary in order to connect to the node execution environment from the gs_admin execution environment as an OS user “gsadm”. See the manual of each OS for details on the SSH connection procedure.

Summary

The system data screen is comprised of configuration and checkpoint/backup information.

Method of use

Screen

Functions

The following functions are available in the system data screen.

• Displaying node data (◆Configuration Information)
  • Display the following data acquired from a node.
    • Node version, IP address and port, node status
• Displaying checkpoint, backup data (◆ CheckPoint/Backup Information)
  • Display the number of checkpoint executions, number of backups performed, etc., as shown in the screenshot above.

Summary

The container list screen contains containers information such as the name of the containers and to which database it belongs to.

Method of use

Screen

Functions

The following functions are available in the container list screen.

• Displaying the container list (◆Own Containers Information)
  • Display a list of the containers stored in a node.
    • Display the database name, container name and partition ID.
• Hyperlink to the container details screen
  • Click on the container name to move to the container details screen and get detailed information of the container.

[Memo]

• The container tree needs to be initialized before moving to the container details screen. If the container details cannot be displayed, click the ContainerTree tab on the Tree once to initialize the container tree.

Summary

The performance data screen shows graphical representation of the node's performance such as memory/storage, read/write count, and misc. count information.

Method of use

Screen

Functions

The following functions are available in the performance data screen.

• Plot a graph (◆Performance Capture)
  • Clicking the Start button will bring up 3 graphs showing the performance of the node at a specified interval.
  • The operation can be stopped with the Stop button.
• Memory/Storage Information
  • Display the volume of data saved in the memory and stored in a disk.
  • Unit is in MB.
• Read/Write Count Information
  • Display the number of times the memory or disk is read from or written to over time.
• Misc Count Information
  • Display the current connection, session, transaction, and number of lock bids generated.

Summary

The snapshot screen shows the node's performance at a point in time. The values can be compared with the values measured earlier.

Method of use

Screen

Functions

The following functions are available in the snapshot screen.

• Gathering of performance data
  • Click the Capture button to get the current performance data of the node.
• Differential display
  • Click the Capture button several times to save and display the baseline and the difference (Diff) between the previous performance data (Start) and current performance data (End).
• Display and save baseline
  • Click the Baseline button to save the displayed differential value per second as the Baseline.
  • Saved data can be selected from the selection box. Only the latest 10 cases will be displayed in the selection box.
  • The baseline is saved in the capture directory of adminHome with the time indicated in Start as its name.

Summary

The log screen contains the event log information of a node and the corresponding setting of its output level.

Method of use

Screen

Functions

The following functions are available in the log screen.

• Displaying event log (◆Log Information)
  • Display the last 30 event logs of the node.
  • Event logs can be acquired again with the reload button.
• Event log output level display setting (◆Current Capture Level)
  • The current event log output level can be checked for each category.
  • The log output levels are ERROR, WARNING, INFO and DEBUG.
  • The changed log level is initialized by restarting the node.
    • Edit the node definition file (gs_node.json) of the target node to be perpetuated.

[Points to note]

• Be sure to follow the instructions of the support desk when changing the log output level.

Summary

In a container tree, the databases and containers which exist in a cluster under management are displayed in a tree format.

The cluster under management is displayed at the top of the tree (the figure within the parentheses () refer to the total number of databases in the cluster).

A description of the icons shown in a container tree is given below.

Icon	Description
	Cluster
	Database
	Database (does not exist)
	Container (collection)
	Container (timeseries container)
	Partitioned table (container)
	Search folder
	Temporary work folder
	Message

Functions

The following functions are available in a container tree.

• Displaying cluster operation functions
  • Upon selecting a cluster, a list of functions such as database creation etc. will appear in View.
• Auto detection of database
  • Automatically detects all databases existing in a cluster and displays them under the cluster.
  • If the displayed database no longer exists in the cluster, it can be deleted from the Tree.
• Selecting database subject to operation
  • Upon selecting a database, a list of functions such as container creation etc. will appear in View.
• Searching for container
  • Containers in each database can be searched using key words. Search conditions can be added by separating them with a single-byte space.
  • A search is conducted by selecting a database or search folder, entering the key words in the search bar at the top, and then clicking the search button or pressing the Enter key.
  • A search folder is created during a search. Figure within parentheses () indicates the number of containers found.
  • Search results can be filtered by stratifying the search folder.
  • Search folders can be deleted with the context menu or Delete key. Even if it is deleted, containers in clusters that are displayed in the folder will not be deleted.
• Deleting container
  • A container can be deleted from a cluster with the context menu or Delete key. Display a confirmation dialog prior to deletion.
• Selecting container subject to operation
  • Icon changes depending on the type of container selected.
  • Upon selecting a container, detailed information etc. of the container will appear in View.
• Temporary work folder
  • This folder is created under the database when a container is created in the container creation screen, or when the container name is clicked from the container data screen.
  • Can be deleted with the context menu or Delete key. Even if it is deleted, containers in clusters that are displayed in the folder will not be deleted.
• Saving tree structure
  • Tree structure after the search is saved and imported during the next login. (File differs for each cluster and user)
  • Objects saved include clusters, databases and search folders. Search results, containers and temporary work folders will not be saved.
  • These are saved in /var/lib/gridstore/admin/tree/foldertree-[cluster name]-[user name].json in the Tomcat operating machine.

After login, the ClusterTree tab and node list are displayed automatically. Upon switching to the ContainerTree tab, the tree structure of the container tree will be added automatically if it has been saved. However, search folders will not be searched again automatically.

The following operations cannot be carried out in a container tree.

• Search for containers across the database
  • Containers in a cluster cannot be searched across a database.
• Creation/deletion of database
  • Perform the operation from the database management screen.
• Creation of container
  • Perform the operation from the container creation screen.
• Deletion of partitioned table (container)
  • Perform the operation from the SQL screen with a SQL command.

Context menu

When an element of the tree is right clicked, a context menu appears according to which element is clicked, cluster or node. Data update and element operation can then be performed by selecting an item from the menu.

The menus and functions for the respective selected elements are as follows.

[Memo]

• Each function of a container tree can be used only when a cluster is in operation.

Operating target and view tab

When an element in the tree is left clicked, the functions appear in the View according to which element is clicked, cluster or node. The function can be changed by tapping the top section of the View.

Summary

The database management screen contains two components, database creation and deletion function, and configuration of access rights (grant, revoke, drop, etc.) for database users.

Method of use

Screen

Functions

The following functions are available in the database management screen.

• Creating database (◆Create Database)
  • Input the database name and click the Create button to create a database in a cluster.
• Displaying database list (◆Database List)
  • Display a list of the databases existing in a cluster.
    • Display the database name, access rights (Privilege), and operations in the database.
  • Display general users who have access rights to the database in the access rights (Privilege) column.
  • Public database cannot be operated.
• Deleting database (Drop)
  • Delete a database from a cluster.
  • An error will occur if a container exists in the database.
• Assignment of access rights (Grant)
  • Assign database access rights to a general user.
  • Click Grant to display the user selection dialog. A general user existing in a cluster can be selected from the selection box.
  • Only one general user has access rights to the database.
  • A single user can have access rights to multiple databases.
• Revoking access rights (Revoke)
  • Revoke database access rights from a general user.
  • In the user management screen tab, when a general user is deleted from the user list, all access rights of that user will be automatically deleted.

Summary

In the user management window, addition and deletion of general user, as well as modification of the password can be performed.

Method of use

Screen

Functions

• Creating a user (◆Create User)
  • Input the desired user name and password, and click the Create button to register a general user into the cluster.
• Displaying a list of the users (◆User List)
  • Display a list of the general users existing in the cluster.
    • Display the user name and operation on the user.
• Deleting user (Drop)
  • Delete a general user from the cluster.
  • If the user has access rights to the database, all access rights will be automatically revoked.
• Changing password (Change Password)
  • The password of a user can be changed. The original password is not needed.
  • Click Change Password to display the input dialog for a new password. Enter the new password and click Change to change the password.

This function can be used in the GridDB Advanced Edition only.

Summary

The results of a SQL command executed on the database are displayed.

Method of use

Screen

Functions

The following functions are available in the SQL screen.

• Selecting a database subject to execution (◆Database)
  • A database existing in a cluster can be selected with the selection box.
  • If a database is selected in a container tree, it will be fixed in the selected database.
• SQL execution (◆SQL)
  • Enter the SQL command and click the Execute button to execute the command. The results are displayed in ◆Result.
    • Although a new line can be returned for input to be carried out, there is only 1 SQL command that can be executed.
    • Inputs can be deleted with the Clear button.
  • By setting Count, the number of hits is displayed. Otherwise, the number is not displayed. (In the latter case, by not getting the number, the response is faster).
  • The number of rows to display is indicated in Display Limit.
  • See “GridDB Advanced Edition SQL Reference” (GridDB_AE_SQL_Reference.html) for details of the SQL syntax that can be used.
• Displaying result (◆Result)
  • If the SELECT command is executed, the number of hits, the number of rows located, and elapsed time (ms) will be displayed (in a table format).
    • The execution time of the SQL statement is displayed as elapsed time in ms.
    • A NULL value and a value of array type are displayed as (NULL). A value of BLOB is displayed as (BLOB).
    • A value of TIMESTAMP is displayed as following format:
      • Date and time format: ISO8601 format
      • Timezone: UTC
      • Example: 2018-11-07T12:30:00.417Z
  • If the INSERT/DELETE/UPDATE command is executed, the no. of rows will be displayed. If other DCL commands or DDL commands are executed, SUCCESS will be displayed in the results.

[Memo]

• When using this screen, the JDBC address and port need to be added to the cluster data of the node repository.
  • Settings in the node repository can be executed from the repository management screen.
• When the number of displaying columns is over 1024, the number of displaying rows at once is decreased and some displaying formats are changed.

Summary

The container creation window allows for creation of container and modification of the column.

Method of use

Screen

Functions

The following functions are available in the container creation screen.

• Creating a container
  • Specify the container name and container type, followed by the parameters according to the container type, and then click the Create button to create a container in a database.
• Selection of container type
  • The container type can be either a collection (Collection) or timeseries container (TimeSeries).
  • The parameters and column contents that can be set differ depending on the container type.
• Column settings
  • Column settings can be configured when creating a container. The upper limit of the number of columns is 100.
  • A column can be added with the Add Column button and deleted with the Del button on the right side of the column.
  • All settings except the container type can be returned to their initial status with the Reset button.
  • If Row Key Assigned is set to true when a collection is selected for the container type, the first column will be set up as the row key.
    • When a row key is set up, the data type of the first column will be limited to those that can be used. And a NOT NULL constraint will be fixed as true.
  • If a timeseries container is selected for the container type, the data type of the first column will be fixed as TIMESTAMP and index settings will be disabled. And a NOT NULL constraint will be fixed as true.
• Add to container tree
  • If a container is created successfully, a temporary work folder will be created under the database of the container tree and the created container will be added automatically under the folder.

[Memo]

• See “GridDB API reference” (GridDB_API_Reference.html) for the detailed settings.

Summary

The container details screen contains column and index configuration data of a container.

Method of use

Screen

Functions

The following functions are available in the container details screen.

• Display container parameters
  • Displaying the container parameters, including the container name, container type etc.
• Displaying column data of a container
  • Display the following data as column data of a container.
    • Column name, data type, column constraints, index, compression data (timeseries container only), table partitioning data (partitioned table only)

Summary

Index setting window allows an index to be created or deleted for each column of a container.

Method of use

Screen

Functions

The following functions are available in the index setting screen.

• Index setting of a column (◆Build/Rebuild Index)
  • Select/deselect a check box and click the Apply button to create/delete the target index.
  • An index name can be specified in textbox.
  • Click the Reset button to dismiss any changes made to the index.

[Memo]

• If the index name is changed and apply, the index is recreated.
• The upper limit of the number of operative columns in this screen is 100.

Summary

The trigger setting screen allows for configuration of the container's trigger such creation, edit and deletion.

Method of use

Screen

Functions

The following functions are available in the trigger setting screen.

• Creating a trigger (◆Create Trigger)
  • To create a trigger in the container, first click New to bring up the configuration boxes. Then, once the setting has been set, click the Apply button to complete the process.
  • Click the Clear button to dismiss the changes and return to the default values.
  • The trigger name (Name), operation under management (Action), and notification destination URI (Destination URI) are essential items. If the notification method (Type) is set to JMS, the notification name (Destination Name) in the JMS settings becomes necessary to fill in.
  • Notification methods (Type) include REST and JMS. Settings vary depending on the notification method.
  • The operation under monitoring (Action) is set up by ticking the PUT and DELETE check boxes.
  • The column under monitoring (Notify Column members) is set up by ticking the check box.
• Editing a trigger (◆Edit Trigger)
  • When the list of triggers appear, click on the trigger's name to bring up its configuration.
  • Only destination URI (Destination URI) and JMS settings can be edited.
  • Click the Apply button to save the edited contents.
  • Click the Delete button to delete the trigger.
  • Click the Clear button to clear the settings.

[Memo]

• See “GridDB API reference” (GridDB_API_Reference.html) for the details.

Summary

In the TQL screen, the TQL (query language) on a container can be executed and the corresponding results can be displayed.

Method of use

Screen

Functions

The following functions are available in the TQL screen.

• TQL execution (◆TQL)
  • Input the TQL command and click the Execute button to execute the command. The results will be displayed in ◆Result.
  • Although a new line can be used as an input, 1 TQL command can be executed at a time.
  • The FROM phrase can be omitted since this command will be executed on containers subject to the operation.
  • The input box can be cleared with the Clear button.
  • The number of rows to display is indicated in Display Limit.
• Displaying result (◆Result)
  • Display the number of hits, the number of rows located (in a table format), and elapsed time (ms). The number of hits is not displayed for a partitioned table.
    • The execution time of the TQL statement is displayed as elapsed time in ms.
    • A NULL value is displayed as (NULL). A value of BLOB is displayed as (BLOB).
    • A value of TIMESTAMP is displayed as following format:
      • Date and time format: ISO8601 format
      • Timezone: UTC
      • Example: 2018-11-07T12:30:00.417Z

[Memo]

• See “GridDB API Reference” (GridDB_API_Reference.html) for the TQL details.
• When the number of displaying columns is over 1024, the number of displaying rows at once is decreased and some displaying formats are changed.

To manage the current active cluster in gs_admin, use the repository management function and follow the procedure below.

1. Select the repository manager in the login screen and login as a gs_admin administrator user.
2. Click the Sync button, enter the following data of any cluster in operation, and then click Sync to synchronize the data.
   • Specify /system/serviceAddress of the node definition file (gs_node.json) as the IP address.
   • Specify /system/servicePort of the node definition file (gs_node.json) as the port.
3. Data of a cluster in operation will be reflected in the cluster list and node list.
4. Click the Save button to save repository data.
5. Click the Logout button to return to the login screen.
6. Select the name of the cluster in operation from the list of clusters on the login screen.
7. Log in as a gs_admin administrator user or a normal user to commence the operating functions.

When managing multiple clusters as a single gs_admin user, take note of the gs_admin user settings.

gs_admin user is managed in a single file, therefore if an administrator managing multiple clusters use different passwords for each of the cluster, the admin cannot be specified as a gs_admin user.

Therefore, the appropriate settings need to be configured according to number of admin in charge of the entire clusters.

• When multiple clusters are managed by different users
  • Choose unique names for each of the gs_admin users.
• When multiple clusters are managed by a single user
  • Register gs_admin users with the same password in all the clusters to-be-managed.

The procedure to register a new gs_admin user is shown below.

1. Use the gs_adduser command to add an administrator user to a single node among the clusters that you want to manage as a new user.

   Example: If the new user name/password is gs#newuser/newuser

   $ su - gsadm
   $ gs_adduser gs#newuser -p newuser
   $ cat /var/lib/gridstore/conf/password
   admin,8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918
   gs#newuser,9c9064c59f1ffa2e174ee754d2979be80dd30db552ec03e7e327e9b1a4bd594e
   system,6ee4a469cd4e91053847f5d3fcb61dbcc91e8f0ef10be7748da4c4a1ba382d17
   

2. Distribute the above-mentioned user definition file to all the other nodes of the cluster that you want to manage as a new user.
3. All nodes will be restarted to reconstitute the cluster.
4. Add the user name and password added above to the gs_admin user definition file as a Tomcat execution user.

   Example: If the new user name/password is gs#newuser/newuser

   $ echo gs#newuser,9c9064c59f1ffa2e174ee754d2979be80dd30db552ec03e7e327e9b1a4bd594e >> /var/lib/gridstore/admin/conf/password
   

Carry out the following preparations before using gs_sh.

• GridDB setup
  • Installation of GridDB node and client library
  • User creation
  • Network setting (GridDB cluster definition file, node definition file)

  See the chapter on “System Design & Construction” in the “GridDB Quick Start Guide” (GridDB_QuickStartGuide.html) for details on the procedure.

• Remote connection setting using SSH
  • This setting is necessary in order to connect to each GridDB node execution environment from the gs_sh execution environment as an OS user “gsadm”.

  *See the manual of each OS for details on the SSH connection procedure.

There are two types of start modes in gs_sh.

• Startup in interactive mode
  • The interactive mode is started when gs_sh is executed without any arguments. The gs_sh prompt will appear, allowing sub-commands to be entered.
  • Example:

    $ gs_sh
    // execution of sub-command “version”
    gs> version
    gs_sh version 2.0.0
    

    [Memo]

    • When a sub-command is started in the interactive mode,
      • a .gssh_history file is created in the home directory of the execution user and saved in the history.
      • Click the arrow key to display/execute up to 20 sub-commands started earlier.
      • Enter some of the sub-commands and click the Tab key to display a list of the sub-command input candidates.
• Startup in batch mode
  • When the script file for user creation is specified in gs_sh, the system will be started in the batch mode. Batch processing of a series of sub-commands described in the script file will be carried out. gs_sh will terminate at the end of the batch processing.
  • Example:

    // specify the script file (test.gsh) and execute
    $ gs_sh test.gsh
    

[Memo]

• Execute gs_sh commands as the OS user “gsadm”.
• During gs_sh startup, .gsshrc script files under the gsadm user home directory are imported automatically. The .gsshrc contents will also be imported to the destination from other script files.
• Extension of script file is gsh.
• A script file is described using the character code UTF-8.

Define the IP address and port no. of a GridDB node in the node variable.

• Sub-command

  setnode

  <Node variable> <IP address> <Port no.> [<SSH port no.>]

• Description of each argument

  Argument	Description
  Node variable	Specify the node variable name. If the same variable name already exists, its definition will be overwritten.
  IP address	Specify the IP address of the GridDB node (for connecting operation control tools).
  Port no.	Specify the port no. of the GridDB node (for connecting operation control tools).
  SSH port no.	Specify the SSH port number. Number 22 is used by default.

• Example:

  //Define 4 GridDB nodes
  gs> setnode node0 192.168.0.1 10000
  gs> setnode node1 192.168.0.2 10000
  gs> setnode node2 192.168.0.3 10000
  gs> setnode node3 192.168.0.4 10000
  

[Memo]

• Only single-byte alphanumeric characters and the symbol "_" can be used in the node variable name.
• Check the GridDB node “IP address” and “port no. ” for connecting the operation control tools in the node definition file of each tool.
  • “IP address”: /system/serviceAddress
  • “Port no.” : /system/servicePort

Define the GridDB cluster configuration in the cluster variable.

• Sub-command

  setcluster	<Cluster variable> <Cluster name> <Multicast address> <Port no.> [<Node variable> ...]
  setcluster	<Cluster variable> <Cluster name> FIXED_LIST <Address list of fixed list method> [<Node variable> ...]
  setcluster	setcluster <Cluster variable> <Cluster name> PROVIDER <URL of provider method> [<Node variable> ...]

• Description of each argument

  Argument	Description
  Cluster variable	Specify the cluster variable name. If the same variable name already exists, its definition will be overwritten.
  Cluster name	Specify the cluster name.
  Multicast address	[For the multicast method] Specify the GridDB cluster multicast address (for client connection).
  Port no.	[For the multicast method] Specify the GridDB cluster multicast port no. (for client connection).
  Node variable	Specify the nodes constituting a GridDB cluster with a node variable.
  	When using a cluster variable in a data operation sub-command, the node variable may be omitted.
  Address list of fixed list method	[For fixed list method] Specify the list of transaction addresses and ports for /cluster/notificationMember in gs_cluster.json. Example: 192.168.15.10:10001,192.168.15.11:10001
  URL of provider method	[For provider method] Specify the value of /cluster/notificationProvider in gs_cluster.json.

• Example:

  // define the GridDB cluster configuration
  gs> setcluster cluster0 name 200.0.0.1 1000 $node0 $node1 $node2
  

[Memo]

• Only single-byte alphanumeric characters and the symbol "_" can be used in the cluster variable name.
• Prepend a "$" to the node variable name.
• Check the “cluster name”, “multicast address” and “port no.” defined in a cluster variable in the cluster definition file of each GridDB node.
  • “Cluster name”: /cluster/clusterName
  • “Multicast address”: /transaction/notificationAddress
  • “Port no.”: /transaction/notificationPort

  *All settings in the cluster definition file of a node constituting a GridDB cluster have to be configured the same way. If the settings are configured differently, the cluster cannot be composed.

In addition, node variables can be added or deleted for a defined cluster variable.

• Sub-command

  modcluster

  <Cluster variable> add | remove <Node variable> ...

• Description of each argument

  Argument	Description
  Cluster variable	Specify the name of a cluster variable to add or delete a node.
  add | remove	Specify "add" when adding node variables, and "remove" when deleting node variables.
  Node variable	Specify node variables to add or delete a cluster variable.

• Example:

  //Add a node to a defined GridDB cluster configuration
  gs> modcluster cluster0 add $node3
  //Delete a node from a defined GridDB cluster configuration
  gs> modcluster cluster0 remove $node3
  

[Memo]

• Prepend a "$" to the node variable name.

Define the SQL connection destination in the GridDB cluster configuration. This is set up only when using the GridDB NewSQL interface.

• Sub-command

  setclustersql	<Cluster variable> <Cluster name> <SQL address> <SQL port no.>
  setclustersql	<Cluster variable> <Cluster name> FIXED_LIST < SQL address list of fixed list method>
  setclustersql	<Cluster variable> <Cluster name> PROVIDER <URL of provider method>

• Description of each argument

  Argument	Description
  Cluster variable	Specify the cluster variable name. If the same variable name already exists, the SQL connection data will be overwritten.
  Cluster name	Specify the cluster name.
  SQL address	[For multicast method] Specify the reception address for the SQL client connection.
  SQL port no.	[For multicast method] Specify the port no. for the SQL client connection.
  SQL address list of fixed list method	[For fixed list method] Specify the list of sql addresses and ports for cluster.notificationMember in gs_cluster.json. Example: 192.168.15.10:20001,192.168.15.11:20001
  URL of provider method	[For provider method] Specify the value of cluster.notificationProvider in gs_cluster.json.

• Example:

  //Definition method when using both NoSQL interface and NewSQL interface to connect to a NewSQL server
  gs> setcluster    cluster0 name 239.0.0.1 31999 $node0 $node1 $node2
  gs> setclustersql cluster0 name 239.0.0.1 41999
  

[Memo]

• Only single-byte alphanumeric characters and the symbol "_" can be used in the cluster variable name.
• This is set up only when using the GridDB NewSQL interface.
• When an existing cluster variable name is specified, only the section containing SQL connection data will be overwritten. When overwriting, the same method as the existing connection method needs to be specified.
• Execute only this command when using SQL only.
• Check the “SQL address” and “SQL port no.” defined in a cluster variable in the cluster definition file of each GridDB node.
  • “SQL address”: /sql/notificationAddress
  • “SQL port no.”: /sql/notificationPort

Define the user and password to access the GridDB cluster.

• Sub-command

  setuser

  <User name> <Password> [<gsadm password>]

• Description of each argument

  Argument	Description
  User name	Specify the name of the user accessing the GridDB cluster.
  Password	Specify the corresponding password.
  gsadm password	Specify the password of the OS user 'gsadm'.
  	This may be omitted if start node (startnode sub-command) is not going to be executed.

• Example:

  //Define the user, password and gsadm password to access a GridDB cluster
  gs> setuser admin admin gsadmpass
  

[Memo]

• The user definition is divided and stored in the variables below.

  Variable Name	Value
  user	User name
  password	Password
  ospassword	gsadm password

• Multiple users cannot be defined. The user and password defined earlier will be overwritten. When operating multiple GridDB clusters in gs_sh, reset the user and password with the setuser sub-command every time the connection destination cluster is changed.

Define an arbitrary variable.

• Sub-command

  set	<Variable name> [<Value>]

• Description of each argument

  Argument	Description
  Variable name	Specify the variable name.
  Value	Specify the setting value. The setting value of the variable concerned can be cleared by omitting the specification.

• Example:

  // Define variable
  gs> set GS_PORT 10040
  // Clear variable settings
  gs> set GS_PORT
  

[Memo]

• Node variable and cluster variable settings can also be cleared with the set sub-command.
• Only single-byte alphanumeric characters and the symbol "_" can be used in the variable name.

Display the detailed definition of the specified variable.

• Sub-command

  show	[<Variable name>]

• Description of each argument

  Argument	Description
  Variable name	Specify the name of the variable to display the definition details. If the name is not specified, details of all defined variables will be displayed.

• Example:

  // Display all defined variables
  gs> show
  Node variable:
    node0=Node[192.168.0.1:10040,ssh=22]
    node1=Node[192.168.0.2:10040,ssh=22]
    node2=Node[192.168.0.3:10040,ssh=22]
    node3=Node[192.168.0.4:10040,ssh=22]
  Cluster variable:
    cluster0=Cluster[name=cluster0,239.0.0.1:31999,nodes = (node0,node1,node2,node3)]
  Other variables:
    user=admin
    password=*****
    ospassword=*****
  

[Memo]

• Password character string will not appear. Display replaced by "*****".

Save the variable definition details in the script file.

• Sub-command

  save	[<Script file name>]

• Description of each argument

  Argument	Description
  Script file name	Specify the name of the script file serving as the storage destination. Extension of script file is gsh.
  	If the name is not specified, the data will be saved in the .gsshrc file in the gsadm user home directory.

• Example:

  // Save the defined variable in a file
  gs> save test.gsh
  

[Memo]

• If the storage destination script file does not exist, a new file will be created. If the storage destination script file exists, the contents will be overwritten.
• A script file is described using the character code UTF-8.
• Contents related to the user definition (user, password, gsadm password) will not be output to the script file.
• Contents in the .gsshrc script file will be automatically imported during gs_sh start-up.

Execute a read script file.

• Sub-command

  load	[<Script file name>]

• Description of each argument

  Argument	Description
  Script file name	Specify the script file to execute.
  	If the script file is not specified, the .gsshrc file in the gsadm user home directory will be imported again.

• Example:

  // Execute script file
  gs> load test.gsh
  

[Memo]

• Extension of script file is gsh.
• A script file is described using the character code UTF-8.

This section explains the status of a GridDB node and GridDB cluster.

A cluster is composed of 1 or more nodes.
A node status represents the status of the node itself e.g. start or stop etc.
A cluster status represents the acceptance status of data operations from a client. A cluster status is determined according to the status of the node group constituting the cluster.

An example of the change in the node status and cluster status due to a gs_sh sub-command operation is shown below.
A cluster is composed of 4 nodes. When the nodes constituting the cluster are started (startnode), the node status changes to “Start”. When the cluster is started after starting the nodes (startcluster), each node status changes to “Join”, and the cluster status also changes to “In Operation”.

A detailed explanation of the node status and cluster status is given below.

• Node status

Node status changes to “Stop”, “Start” or “Join” depending on whether a node is being started, stopped, joined or detached. If a node has joined a cluster, there are 2 types of node status depending on the status of the joined cluster.

• Cluster status

  GridDB cluster status changes to “Stop”, “Halted” or “In Operation” depending on the operation start/stop status of the GridDB cluster or the join/leave operation of the GridDB node. Data operations from the client can be accepted only when the GridDB cluster status is “In Operation”.

  

  Cluster status

  Status	Status name	Description
  In Operation	SERVICE_STABLE	All nodes defined in the cluster configuration have joined the cluster
  	SERVICE_UNSTABLE	More than half the nodes defined in the cluster configuration have joined the cluster
  Halted	WAIT	Half and more of the nodes defined in the cluster configuration have left the cluster
  	INIT_WAIT	1 or more of the nodes defined in the cluster configuration have left the cluster (when the cluster is operated for the first time, the status will not change to “In Operation” unless all nodes have joined the cluster)
  Stop	STOP	All nodes defined in the cluster configuration have left the cluster

  The GridDB cluster status will change from “Stop” to “In Operation” when all nodes constituting the GridDB cluster are allowed to join the cluster. In addition, the GridDB cluster status will change to “Halted” when half and more of the nodes have left the cluster, and “Stop” when all the nodes have left the cluster.

  Join and leave operations (which affect the cluster status) can be applied in batch to all the nodes in the cluster, or to individual node.

  Operation	When the operating targets are all nodes	When the operating target is a single node
  Join	startcluster : Batch entry of a group of nodes that are already operating but have not joined the cluster yet.	joincluster : Entry by a node that is in operation but has not joined the cluster yet.
  Leave	stopcluster : Batch detachment of a group of nodes joined to a cluster.	leavecluster : Detachment of a node joined to a cluster.

[Memo]

• Join and leave cluster operations can be carried out on nodes that are in operation only.
• A node which has failed will be detached automatically from the GridDB cluster.
• The GridDB cluster status can be checked with the cluster status data display sub-command (configcluster).

Details of the various operating methods are explained below.

Start the specified node.

• Sub-command

  startnode

  <Node variable> | <Cluster variable> [<Timeout time in sec>]

• Description of each argument

  Argument	Description
  Node variable | cluster variable	Specify the node to start by its node variable or cluster variable.
  	If the cluster variable is specified, all nodes defined in the cluster variable will be started.
  Timeout time in sec.	Set the number of seconds the command or a script is allowed to run. Returns an error message (D20203: Timeout occurred) if this number is reached.
  	Timeout time = -1, return to the console immediately without waiting for the command to finish.
  	Timeout time = 0 or not set, no timeout time, wait for the command to finish indefinitely.
  	Timeout time > 0, return an error if timeout time is reached.

• Example:

  // start node
  gs> startnode $node1
  The GridDB node node1 is starting up.
  All GridDB node has been started.
  

[Memo]

• Command can be executed by an administrator user only.
• Append "$" in front of the variable name when using a variable.
• The cluster start process (startcluster sub-command) can be executed in batches by waiting for the start process to complete.

Stop the specified node.

• Sub-command

  stopnode

  <Node variable> | <Cluster variable> [<Timeout time in sec>]

• Description of each argument

  Argument	Description
  Node variable | Cluster variable	Specify the node to stop by its node variable or cluster variable.
  	If the cluster variable is specified, all nodes defined in the cluster variable will be stopped.
  Timeout time in sec.	Set the number of seconds the command or a script is allowed to run. Returns an error message (D20203: Timeout occurred) if this number is reached.
  	Timeout time = -1, return to the console immediately without waiting for the command to finish.
  	Timeout time = 0 or not set, no timeout time, wait for the command to finish indefinitely.
  	Timeout time > 0, return an error if timeout time is reached.

• Example:

  // stop node
  gs> stopnode $node1
  The GridDB node node1 is stopping down.
  All GridDB node has been stopped.
  

In addition, the specified node can be forced to stop as well.

• Sub-command

  stopnodeforce

  <Node variable> | <Cluster variable> [<Timeout time in sec>]

• Description of each argument

  Argument	Description
  Node variable | Cluster variable	Specify the node to stop by force by its node variable or cluster variable.
  	If the cluster variable is specified, all nodes defined in the cluster variable will be stopped by force.
  Timeout time in sec.	Set the number of seconds the command or a script is allowed to run. Returns an error message (D20203: Timeout occurred) if this number is reached.
  	Timeout time = -1, return to the console immediately without waiting for the command to finish.
  	Timeout time = 0 or not set, no timeout time, wait for the command to finish indefinitely.
  	Timeout time > 0, return an error if timeout time is reached.

• Example:

  // stop node by force
  gs> stopnodeforce $node1
  The GridDB node node1 is stopping down.
  All GridDB node has been stopped.
  

[Memo]

• Command can be executed by an administrator user only.
• Append "$" in front of the variable name when using a variable.
• In a stopnode sub-command, nodes which have joined the GridDB cluster cannot be stopped. In a stopnodeforce command, nodes which have joined the GridDB cluster can also be stopped but data may be lost.

Explanation on how to add batch nodes into a cluster is shown below. In this case when a group of unattached but operating nodes are added to the cluster, the cluster status will change to “In Operation”.

• Sub-command

  startcluster

  <Cluster variable> [<Timeout time in sec.>]

• Description of each argument

  Argument	Description
  Cluster variable	Specify a GridDB cluster by its cluster variable.
  Timeout time in sec.	Set the number of seconds the command or a script is allowed to run. Returns an error message (D20203: Timeout occurred) if this number is reached.
  	Timeout time = -1, return to the console immediately without waiting for the command to finish.
  	Timeout time = 0 or not set, no timeout time, wait for the command to finish indefinitely.
  	Timeout time > 0, return an error if timeout time is reached.

• Example:

  // start GridDB cluster
  gs> startcluster $cluster0
  Waiting for the GridDB cluster to start.
  The GridDB cluster has been started.
  

[Memo]

• Command can be executed by an administrator user only.
• Append "$" in front of the variable name when using a variable.
• To change the status of a GridDB cluster from “Stop” to “In Operation”, all nodes must be allowed to join the cluster. Check beforehand that all nodes constituting the GridDB cluster are in operation.

To stop a GridDB cluster, simply make the attached nodes leave the cluster using the stopcluster command.

• Sub-command

  stopcluster

  <Cluster variable> [<Timeout time in sec.>]

• Description of each argument

  Argument	Description
  Cluster variable	Specify a GridDB cluster by its cluster variable.
  Timeout time in sec.	Set the number of seconds the command or a script is allowed to run. Returns an error message (D20203: Timeout occurred) if this number is reached.
  	Timeout time = -1, return to the console immediately without waiting for the command to finish.
  	Timeout time = 0 or not set, no timeout time, wait for the command to finish indefinitely.
  	Timeout time > 0, return an error if timeout time is reached.

• Example:

  // stop GridDB cluster
  gs> stopcluster $cluster0
  Waiting for the GridDB cluster to stop.
  The GridDB cluster has been stopped.
  

[Memo]

• Command can be executed by an administrator user only.
• Append "$" in front of the variable name when using a variable.

Join a node that is temporarily left from the cluster by leavecluster sub-command or failure into the cluster.

• Sub-command

  joincluster

  <Cluster variable> <Node variable> [<Timeout time in sec.>]

• Description of each argument

  Argument	Description
  Cluster variable	Specify a GridDB cluster by its cluster variable.
  Node variable	Specify the node to join by its node variable.
  Timeout time in sec.	Set the number of seconds the command or a script is allowed to run. Returns an error message (D20203: Timeout occurred) if this number is reached.
  	Timeout time = -1, return to the console immediately without waiting for the command to finish.
  	Timeout time = 0 or not set, no timeout time, wait for the command to finish indefinitely.
  	Timeout time > 0, return an error if timeout time is reached.

• Example:

  gs> startnode $node0
  // start node
  The GridDB node node0 is starting up.
  All GridDB node has been started.
  // join node
  gs> joincluster $cluster0 $node0
  Waiting for the GridDB node to join the GridDB cluster.
  The GridDB node has joined to the GridDB cluster.
  

[Memo]

• Command can be executed by an administrator user only.
• Append "$" in front of the variable name when using a variable.
• Only nodes that are in operation can join a GridDB cluster. Check that the nodes joining a cluster are in operation.
• Use the appendcluster sub-command when adding a node that is not yet defined in the cluster's configuration to the cluster (the node is not part of the cluster).

Detach the specified node from the cluster.

• Sub-command

  leavecluster	<Node variable> [<Timeout time in sec.>]
  leaveclusterforce	<Node variable> [<Timeout time in sec.>]

• Description of each argument

  Argument	Description
  Node variable	Specify the node to detach by its node variable.
  Timeout time in sec.	Set the number of seconds the command or a script is allowed to run. Returns an error message (D20203: Timeout occurred) if this number is reached.
  	Timeout time = -1, return to the console immediately without waiting for the command to finish.
  	Timeout time = 0 or not set, no timeout time, wait for the command to finish indefinitely.
  	Timeout time > 0, return an error if timeout time is reached.

• Example:

  // leave node
  gs> leavecluster $node0
  Waiting for the GridDB node to leave the GridDB cluster.
  The GridDB node has leaved the GridDB cluster.
  

[Memo]

• Command can be executed by an administrator user only.
• Append "$" in front of the variable name when using a variable.
• A node can safely leave a GridDB cluster only when the data has been duplicated in other nodes. However, a leavecluster sub-command forces a node to leave regardless of whether the data has been duplicated or not and so there is always a risk of data loss. Use the gs_leavecluster command to detach a node. See the section on “System Design & Construction - Designing Tuning Parameters” in the “GridDB Quick Start Guide” (GridDB_QuickStartGuide.html) for details regarding data duplication.
• A leaveclusterforce command forces a node to leave a cluster even if there is a risk that data may be lost due to the detachment.

Add an undefined node to a pre-defined cluster.

• Sub-command

  appendcluster

  <Cluster variable> <Node variable> [<Timeout time in sec.>]

• Description of each argument

  Argument	Description
  Cluster variable	Specify a GridDB cluster by its cluster variable.
  Node variable	Specify the node to join by its node variable.
  Timeout time in sec.	Set the number of seconds the command or a script is allowed to run. Returns an error message (D20203: Timeout occurred) if this number is reached.
  	Timeout time = -1, return to the console immediately without waiting for the command to finish.
  	Timeout time = 0 or not set, no timeout time, wait for the command to finish indefinitely.
  	Timeout time > 0, return an error if timeout time is reached.

• Example:

  // define node
  gs> setnode node5 192.168.0.5 10044
  // start node
  gs> startnode $node5
  // increase no. of nodes
  gs> appendcluster $cluster1 $node5
  Waiting for a node to be added to a cluster.
  A node has been added to the cluster.
  Add node variables $node5 to cluster variable $cluster1. (Execute a save command when saving changes to a variable. )
  
  Cluster[name=name1,239.0.5.111:33333,nodes=($node1,$node2,$node3,$node4,$node5)]
  

[Memo]

• Command can be executed by an administrator user only.
• Append "$" in front of the variable name when using a variable.
• To increase the number of new nodes, all nodes that constitute a GridDB cluster needs to join the cluster. If there is any node detached from the GridDB cluster, re-attach the nodes first. In addition, check that the new node to be added is in operation.
• When executing an appendcluster sub-command, the node variable to be added is added to the cluster variable automatically. There is no need to manually change the cluster variable definition.
• If a variable is changed, execute a save command to save the data. Unsaved contents will be discarded.
• See the chapter on “System Design & Construction” in the “GridDB Quick Start Guide” (GridDB_QuickStartGuide.html) for details on how to set up a new node.

Display the cluster status data.

• Sub-command

  configcluster

  <Cluster variable>

• Description of each argument

  Argument	Description
  Cluster variable	Specify a GridDB cluster by its cluster variable.

• Example:

  // display cluster data
  gs> configcluster $cluster1
  Name                  : cluster1
  ClusterName           : defaultCluster
  Designated Node Count : 4
  Active Node Count     : 4
  ClusterStatus         : SERVICE_STABLE
  
  Nodes:
    Name    Role Host:Port              Status
  -------------------------------------------------
    node1     F  10.45.237.151:10040    SERVICING 
    node2     F  10.45.237.152:10040    SERVICING 
    node3     M  10.45.237.153:10040    SERVICING 
    node4     F  10.45.237.154:10040    SERVICING
  

[Memo]

• Command can be executed by an administrator user only.
• ClusterStatus will be one of the following.
  • INIT_WAIT : Waiting for cluster to be composed
  • SERVICE_STABLE : In operation
  • SERVICE_UNSTABLE : Unstable (specified number of nodes constituting a cluster has not been reached)
• Role will be one of the following.
  • M: MASTER
  • F: FOLLOWER
  • S: SUB_CLUSTER (temporary status in a potential master candidate)
  • -: Not in operation

Display the cluster configuration data.

• Sub-command

  config

  <Node variable>

• Description of each argument

  Argument	Description
  Node variable	Specify the node belonging to a GridDB cluster to be displayed with a node variable.

• Example:

  // display cluster configuration data
  gs> config $node1
  {
    "follower" : [ {
      "address" : "10.45.237.151",
      "port" : 10040
    }, {
      "address" : "10.45.237.152",
      "port" : 10040
    }, {
      "address" : "10.45.237.153",
      "port" : 10040
    }, {
      "address" : "10.45.237.154",
      "port" : 10040
    } ],
    "master" : {
      "address" : "10.45.237.155",
      "port" : 10040
    },
    "multicast" : {
      "address" : "239.0.5.111",
      "port" : 33333
    },
    "self" : {
      "address" : "10.45.237.150",
      "port" : 10040,
      "status" : "ACTIVE"
    }
  }
  

[Memo]

• Command can be executed by an administrator user only.
• Append "$" in front of the variable name when using a variable.
• The output contents differ depending on the version of the GridDB node. Check with the support desk for details.

Display the node configuration data.

• Sub-command

  stat	<Node variable>

• Description of each argument

  Argument	Description
  Node variable	Specify the node to display by its node variable.

• Example:

  // display node status, statistical data
  gs> stat $node1
  {
    "checkpoint" : {
      "archiveLog" : 0,
      "backupOperation" : 0,
      "duplicateLog" : 0,
      "endTime" : 1413852025843,
      "mode" : "NORMAL_CHECKPOINT",
               :
               :
  }
  

[Memo]

• Command can be executed by an administrator user only.
• Append "$" in front of the variable name when using a variable.
• The output contents differ depending on the version of the GridDB node.

Displays the log of the specified node.

• Sub-command

  logs	<Node variable>

• Description of each argument

  Argument	Description
  Node variable	Specify the node to display by its node variable.

• Example:

  // display log of node
  gs> logs $node0
  2013-02-26T13:45:58.613+0900 c63x64n1 4051 INFO SYSTEM_SERVICE ../server/system_service.cpp void SystemService::joinCluster(const char8_t*, uint32_t) line=179 : joinCluster requested (clusterName="defaultCluster", minNodeNum=1) 
  2013-02-26T13:45:58.616+0900 c63x64n1 4050 INFO SYSTEM_SERVICE ../server/system_service.cpp virtual void SystemService::JoinClusterHandler::callback(EventEngine&, util::StackAllocator&, Event*, NodeDescriptor) line=813 : ShutdownClusterHandler called g
  2013-02-26T13:45:58.617+0900 c63x64n1 4050 INFO SYSTEM_SERVICE ../server/system_service.cpp void SystemService::completeClusterJoin() line=639 : completeClusterJoin requested 
  2013-02-26T13:45:58.617+0900 c63x64n1 4050 INFO SYSTEM_SERVICE ../server/system_service.cpp virtual void SystemService::CompleteClusterJoinHandler::callback(EventEngine&, util::StackAllocator&, Event*, NodeDescriptor) line=929 : CompleteClusterJoinHandler called
  

In addition, the log output level can be displayed and changed.

• Sub-command

  logconf

  <Node variable> [<Category name> [<Log level>]]

• Description of each argument

  Argument	Description
  Node variable	Specify the node to operate by its node variable.
  Category name	Specify the log category name subject to the operation. Output level of all log categories will be displayed by default.
  Log level	Specify the log level to change the log level of the specified category.
  	Log level of the specified category will be displayed by default.

• Example:

  // display log level of node
  gs> logconf $node0
  {
    "CHECKPOINT_SERVICE" : "INFO",
    "CHUNK_MANAGER" : "ERROR",
    "CLUSTER_OPERATION" : "INFO",
    "CLUSTER_SERVICE" : "ERROR",
    "COLLECTION" : "ERROR",
    "DATA_STORE" : "ERROR",
    "EVENT_ENGINE" : "WARNING",
    "HASH_MAP" : "ERROR",
    "IO_MONITOR" : "WARNING",
    "LOG_MANAGER" : "WARNING",
    "MAIN" : "ERROR",
    "OBJECT_MANAGER" : "INFO",
    "RECOVERY_MANAGER" : "INFO",
    "REPLICATION" : "WARNING",
    "REPLICATION_TIMEOUT" : "WARNING",
    "SESSION_TIMEOUT" : "WARNING",
    "SYNC_SERVICE" : "ERROR",
    "SYSTEM_SERVICE" : "INFO",
    "TIME_SERIES" : "ERROR",
    "TRANSACTION_MANAGER" : "ERROR",
    "TRANSACTION_SERVICE" : "ERROR",
    "TRANSACTION_TIMEOUT" : "WARNING",
    "TRIGGER_SERVICE" : "ERROR"
  }
  

[Memo]

• Command can be executed by an administrator user only.
• Log levels are ERROR, WARNING, INFO, and DEBUG. Be sure to follow the instructions of the support desk when changing the log level.
• Log level is initialized by restarting the node. Changes to the log level are not saved.
• Batch changes cannot be made to the log level of multiple categories.
• The output contents differ depending on the version of the GridDB node. Check with the support desk for details.

Establish connection to a GridDB cluster to execute a data operation.

• Sub-command

  connect

  <Cluster variable> [<Database name>]

• Description of each argument

  Argument	Description
  Cluster variable	Specify a GridDB cluster serving as the connection destination by its cluster variable.
  Database name	Specify the database name.

• Example:

  // connect to GridDB cluster
  // for NoSQL
  gs> connect $cluster1
  The connection attempt was successful(NoSQL).
  gs[public]> 
  
  gs> connect $cluster1 userDB
  The connection attempt was successful(NoSQL).
  gs[userDB]> 
  
  // for NewSQL (configure both NoSQL/NewSQL interfaces)
  gs> connect $cluster1
  The connection attempt was successful(NoSQL).
  The connection attempt was successful(NewSQL).
  gs[public]> 
  

[Memo]

• Connect to the database when the database name is specified. Connect to the “public” database if the database name is omitted.
• If the connection is successful, the connection destination database name appears in the prompt.
• Append "$" in front of the variable name when using a variable.
• When executing a data operation sub-command, it is necessary to connect to a GridDB cluster.
• If the SQL connection destination is specified (execution of setclustersql sub-command), SQL connection is also carried out.

Execute a search and retain the search results.

• Sub-command

  tql	<Container name> <Query;>

• Description of each argument

  Argument	Description
  Container name	Specify the container subject to the search.
  Query;	Specify the TQL command to execute. A semicolon (;) is required at the end of a TQL command.

• Example:

  // execute search
  gs[public]> tql c001 select *;
  5 results. (25 ms)
  

[Memo]

• When executing a data operation sub-command, it is necessary to connect to a GridDB cluster.
• A return can be inserted in the middle of a TQL command.
• Display the elapsed time of query as milliseconds.
• Retain the latest search result. Search results are discarded when a tql or sql sub-command is executed.
• See the chapter on “TQL Syntax & Operating Functions” in the “GridDB API Reference” (GridDB_API_Reference.html) for the TQL details.

Execute an SQL command and retains the search result. This function can be executed in the GridDB Advanced Edition edition only.

• Sub-command

  sql	<SQL command;>

• Description of each argument

  Argument	Description
  SQL command;	Specify the SQL command to execute. A semicolon (;) is required at the end of the SQL command.

• Example:

  gs[public]> sql select * from con1;          -> search for SQL
  10,000 results. (52 ms)
  gs[public]> get 1                            -> display SQL results
  id,name
  ----------------------
  0,tanaka
  The 1 results had been acquired.
  

Sub-command name 'sql' can be omitted when the first word of SQL statement is one of the follows.

• select update insert replace delete create drop alter grant revoke pragma

[Memo]

• Before executing a sql command, there is a need to specify the SQL connection destination and perform a connection first.
• Retain the latest search result. Search results are discarded when a sql or tql sub-command is executed.
• Sub-command name 'sql' can not be omitted when specifying the 'set password' command or the command includes comments in header.
• Count the number of hits when querying.
• Display the elapsed time of query as milliseconds. It does not include the time of counting.
• The following results will appear depending on the type of SQL command.

  Operation	Execution results when terminated normally
  Search SELECT	Display the no. of search results found. Search results are displayed in sub-command get/getcsv/getnoprint.
  Update INSERT/UPDATE/DELETE	Display the no. of rows updated.
  DDL statement	Nothing is displayed.

• See “GridDB Advanced Edition SQL Reference” (GridDB_AE_SQL_Reference.html) for the SQL details.

The following command gets the inquiry results and presents them in different formats. There are 3 ways to output the results as listed below.

(A) Display the results obtained in a standard output.

• Sub-command

  get	[No. of acquires]

• Description of each argument

  Argument	Description
  No. of acquires	Specify the number of search results to be acquired. All search results will be obtained and displayed by default.

(B) Save the results obtained in a file in the CSV format.

• Sub-command

  getcsv

  <CSV file name> [<No. of acquires>]

• Description of each argument

  Argument	Description
  File name	Specify the name of the file where the search results are saved.
  No. of acquires	Specify the number of search results to be acquired. All search results will be obtained and saved in the file by default.

(C) Results obtained will not be output.

• Sub-command

  getnoprint

  [<No. of acquires>]

• Description of each argument

  Argument	Description
  No. of acquires	Specify the number of search results to be acquired. All search results will be obtained by default.

• Example:

  // execute search
  gs[public]> tql c001 select *;
  5 results. (5 ms)
  
  //Get first result and display
  gs[public]> get 1
  name,status,count
  mie,true,2
  The 1 results had been acquired.
  
  //Get second and third results and save them in a file
  gs[public]> getcsv /var/lib/gridstore/test2.csv 2
  The 2 results had been acquired.
  
  //Get fourth result
  gs[public]> getnoprint 1
  The 1 results had been acquired.
  
  //Get fifth result and display
  gs[public]> get 1
  name,status,count
  akita,true,45
  The 1 results had been acquired.
  

[Memo]

• When executing a data operation sub-command, it is necessary to connect to a GridDB cluster.
• Output the column name to the first row of the search results
• An error will occur if the search results are obtained when a search has not been conducted, or after all search results have been obtained or discarded.
• A NULL value is output by each command as follows.
  • get: (NULL)
  • getcsv: an unquoted empty string
• A value of TIMESTAMP is output as following format:
  • Date and time format: ISO8601 format
  • Timezone: UTC
  • Example: 2018-11-07T12:30:00.417Z

The following command displays the execution plan of the specified TQL command. Search is not executed.

• Sub-command

  tqlexplain

  <Container name> <Query;>

• Description of each argument

  Argument	Description
  Container name	Specify the target container.
  Query;	Specify the TQL command to get the execution plan. A semicolon (;) is required at the end of a TQL command.

• Example:

  //Get execution plan
  gs[public]> tqlexplain c001 select * ;
  0       0       SELECTION       CONDITION       NULL
  1       1       INDEX   BTREE   ROWMAP
  2       0       QUERY_EXECUTE_RESULT_ROWS       INTEGER 0
  

In addition, the actual measurement values such as the number of processing rows etc. can also be displayed together with the executive plan by actually executing the specified TQL command.

• Sub-command

  tqlanalyze

  <Container name> <Query;>

• Description of each argument

  Argument	Description
  Container name	Specify the target container.
  Query;	Specify the TQL command to get the execution plan. A semicolon (;) is required at the end of a TQL command.

• Example:

  // Execute search to get execution plan
  gs[public]> tqlanalyze c001 select *;
  0       0       SELECTION       CONDITION       NULL
  1       1       INDEX   BTREE   ROWMAP
  2       0       QUERY_EXECUTE_RESULT_ROWS       INTEGER 5
  3       0       QUERY_RESULT_TYPE       STRING  RESULT_ROW_ID_SET
  4       0       QUERY_RESULT_ROWS       INTEGER 5
  

[Memo]

• When executing a data operation sub-command, it is necessary to connect to a GridDB cluster.
• See the chapter on “TQL Syntax & Operating Functions” in the “GridDB API Reference” (GridDB_API_Reference.html) for the detailed execution plan.
• Since search results are not retained, search results cannot be acquired and thus there is also no need to execute a tqlclose sub-command. When the search results are required, execute a query with the tql sub-command.
• A partitioned table (container) is not supported. If executed, an error will occur.

Close the tql and discard the search results saved.

• Sub-command

  tqlclose

Close query. Discard the search results retained.

• Sub-command

  queryclose

• Example:

  //Discard search results
  gs[public]> tqlclose
  
  gs[public]> queryclose
  

[Memo]

• Search results are discarded at the following timing.
  • When a tqlclose or query close sub-command is executed
  • When executing a new search using a tql or sql sub-command
  • When disconnecting from a GridDB cluster using a disconnect sub-command
• An error will occur if search results are acquired (get sub-command, etc.) after they have been discarded.

Disconnect from a GridDB cluster.

• Sub-command

  disconnect

• Example:

  //Disconnect from a GridDB cluster
  gs[public]> disconnect
  gs> 
  
  

[Memo]

• Retained search results are discarded.
• When disconnected, the connection database name will disappear from the prompt.

Set whether to execute count query when SQL querying.

• Sub-command

  sqlcount

  <Boolean>

• Description of each argument

  Argument	Description
  Boolean	If FALSE is specified, gs_sh does not count the number of the result when querying by sql sub-command. And hit count does not be displayed. Default is TRUE.

• Example:

  gs[public]> sql select * from mycontainer;
  25550 results. (33 ms)
  
  gs[public]> sqlcount FALSE
  
  gs[public]> sql select * from mycontainer;
  The query had been executed. (33 ms)
  

[Memo]

• If FALSE is specified, the response will be faster instead of displaying no hit count.

Create a database with the specified name.

• Sub-command

  createdatabase

  <Database name>

• Description of each argument

  Argument	Description
  Database name	Specify the name of the database to be created.

• Example:

  // Create a database with the name “db1”
  gs[public]> createdatabase db1
  

[Memo]

• Command can be executed by an administrator user only.
• Only the administrator user can access a database immediately after it has been created. Assign access rights to general users where necessary.

Delete the specified database.

• Sub-command

  dropdatabase

  <Database name>

• Description of each argument

  Argument	Description
  Database name	Specify the name of the database to be deleted.

• Example:

  //Delete databases shown below
  //db1: No container exists in the database
  //db2: Database does not exist
  //db3: Container exists in the database
  
  gs[public]> dropdatabase db1                  // No error occurs
  gs[public]> dropdatabase db2                  // An error occurs
  D20340: This database "db2" does not exists.
  gs[public]> dropdatabase db3                  // An error occurs
  D20336: An unexpected error occurred while dropping the database. : msg=[[145045:JC_DATABASE_NOT_EMPTY] Non-empty database cannot be dropped]
  

[Memo]

• Command can be executed by an administrator user only.
• A public database which is a default connection destination cannot be deleted.

Display the current database name.

• Sub-command

  getcurrentdatabase

• Example:

  gs[db1]> getcurrentdatabase
  db1
  

List the databases with access right information.

• Sub-command

  showdatabase

  [<Database name>]

• Description of each argument

  Argument	Description
  Database name	Specify the name of the database to be displayed.

• Example:

  gs[public]> showdatabase
  database     ACL
  ----------------------------
  public       ALL_USER
  db1          user1
  db2          user1
  db3          user3
  
  gs[public]> showdatabase db1
  database     ACL
  ----------------------------
  public       ALL_USER
  db1          user1
  

[Memo]

• For general users, only databases for which access rights have been assigned will be displayed. For administrator users, a list of all the databases will be displayed.

Grant the database access rights to user.

• Sub-command

  grantacl

  <Database name> <User name>

• Description of each argument

  Argument	Description
  Database name	Specify the name of the database for which access rights are going to be granted
  User name	Specify the name of the user to assign access rights to.

• Example:

  gs[public]> grantacl db1 user001
  

[Memo]

• Command can be executed by an administrator user only.
• An error will occur if access rights have already been assigned (only 1 user can be assigned access rights to each database). Execute this command after revoking the access rights ("revokeacl" command).

Revoke access rights to the database.

• Sub-command

  revokeacl

  <Database name> <User name>

• Description of each argument

  Argument	Description
  Database name	Specify the name of the database for which access rights are going to be revoked.
  User name	Specify the name of the user whose access rights are going to be revoked.

• Example:

  gs[public]> revokeacl db1 user001
  

[Memo]

• Command can be executed by an administrator user only.

Create a general user (username and password).

• Sub-command

  createuser

  <User name> <Password>

• Description of each argument

  Argument	Description
  User name	Specify the name of the user to be created.
  Password	Specify the password of the user to be created.

• Example:

  gs[public]> createuser user01 pass001
  

[Memo]

• Command can be executed by an administrator user only.
• A name starting with "gs#" cannot be specified as the name of a general user as it is reserved for use by the administrator user.
• When creating an administrator user, use the gs_adduser command in all the nodes constituting the cluster.

Delete the specified general user

• Sub-command

  dropuser

  <User name>

• Description of each argument

  Argument	Description
  User name	Specify the name of the user to be deleted.

• Example:

  gs[public]> dropuser user01
  

[Memo]

• Command can be executed by an administrator user only.

Update the user password.

• Sub-command

  setpassword	<Password> (general user only)
  setpassword	<User name> <Password> (administrator user only)

• Description of each argument

  Argument	Description
  Password	Specify the password to change.
  User name	Specify the name of the user whose password is going to be changed.

• Example:

  gs[public]> setpassword newPass009
  

[Memo]

• The general user can change its own password only.
• An administrator user can change the passwords of other general users only.

List the general user data.

• Sub-command

  showuser

  [<User name>]

• Description of each argument

  Argument	Description
  User name	Specify the name of the user to be displayed.

• Example:

  gs[public]> showuser
  UserName
  ------------------------------------
  user002
  user001
  user003
  
  gs[public]> showuser user001
  Name     : user001
  GrantedDB: public, userDB
  

[Memo]

• Command can be executed by an administrator user only.

Create a container.

• Sub-command
  • Simplified version

    Container (collection)
    createcollection	<Container name> <Column name> <Column type> [<Column name> <Column type> ...]
    Container (timeseries container)
    createtimeseries	<Container name> <Compression method> <Column name> <Column type> [<Column name> <Column type> ...]

  • Detailed version

    createcontainer

    <Container data file> [<Container name>]

• Description of each argument

  Argument	Description
  Container name	Specify the name of the container to be created. If the name is omitted in the createcontainer command, a container with the name given in the container data file will be created.
  Column name	Specify the column name.
  Column type	Specify the column type.
  Compression method	For time series data, specify the data compression method.
  Container data file	Specify the file storing the container data in JSON format.

  Simplified version

  Specify the container name and column data (column name and type) to create the container. The compression type can also be specified for timeseries containers only.

  • Specify "NO", "SS" for the compression method. Use the detailed version if "HI" is specified.
  • The collection will be created with a specified row key. The first column will become the row key.
  • In case of specifying column constraints and index names, use the detailed version.

  Detailed version

Specify the container definition data in the json file to create a container.

• The container definition data has the same definition as the metadata file output by the export tool. See the container data file format and Metadata files for the column type and data compression method, container definition format, etc. However, the following data will be invalid in this command even though it is defined in the metadata file of the export command.
  • version : Export tool version
  • database : Database name
  • containerFileType : Export data file type
  • containerFile : Export file name
  • partitionNo : Partition no.
• Describe a single container definition in a single container definition file.
• If the container name is omitted in the argument, create the container with the name described in the container definition file.
• If the container name is specified in the argument, ignore the container name in the container definition file and create the container with the name described in the argument.
• An error will not occur even if the database name is described in the container definition file but the name will be ignored and the container will be created in the database currently being connected.
• Partitioned tables are not applicable. An error will occur when table partitioning data is described in the container definition file.
• When using the container definition file, the metadata file will be output when the --out option is specified in the export function. The output metadata file can be edited and used as a container definition file.

  Example: When using the output metadata file as a container definition file

  {
      "version":"2.1.00",                              # unused
      "container":"container_354",
      "database":"db2",                                # unused
      "containerType":"TIME_SERIES",
      "containerFileType":"binary",                    # unused
      "containerFile":"20141219_114232_098_div1.mc",   # unused
      "rowKeyAssigned":true,
      "partitionNo":0,                                 # unused
      "columnSet":[
          {
              "columnName":"timestamp",
              "type":"timestamp",
              "notNull":true
          },
          {
              "columnName":"active",
              "type":"boolean",
              "notNull":true
          },
          {
              "columnName":"voltage",
              "type":"double",
              "notNull":true
          }
      ],
      "timeSeriesProperties":{
          "compressionMethod":"NO",
          "compressionWindowSize":-1,
          "compressionWindowSizeUnit":"null",
          "expirationDivisionCount":8,
          "rowExpirationElapsedTime":-1,
          "rowExpirationTimeUnit":"null"
      },
      "compressionInfoSet":[
      ]
  }
  

Delete a container

• Sub-command

  dropcontainer

  <Container name>

• Description of each argument

  Argument	Description
  Container name	Specify the name of the container to be deleted.

• Example:

  gs[public]> dropcontainer Con001
  

[Memo]

• A partitioned table (container) is not supported. If executed, an error will occur.
  • To drop partitioned table (container), use SQL.

Display a container data.

• Sub-command

  showcontainer

  <Container name>

• Description of each argument

  Argument	Description
  Container name	Specify the container name to be displayed. Display a list of all containers if omitted.

• Example:

  // display container list
  gs[userDB]> showcontainer
  Database : userDB
  Name                  Type         PartitionId
  ------------------------------------------------
  cont001               COLLECTION            10
  col00a                COLLECTION             3
  time02                TIME_SERIES            5
  cont003               COLLECTION            15
  cont005               TIME_SERIES           17
  
  // display data of specified container
  gs[public]> showcontainer cont003
  Database    : userDB
  Name        : cont003
  Type        : COLLECTION
  Partition ID: 15
  DataAffinity: -
  
  Columns:
  No  Name                  Type            CSTR  Index
  ------------------------------------------------------------------------------
   0  string                STRING          NN    TREE(myIndex)   [RowKey]
   1  value                 DOUBLE          NN    HASH() TREE(myIndex2)
  
  
  

[Memo]

• Container data of the current DB will be displayed.
• The data displayed in a container list are the “Container name”, “Container type” and “Partition ID”.
• The data displayed in the specified container are the “Container name”, “Container type”, “Partition ID”, “Defined column name”, “Column data type”, “Column constraints” as CSTR, “Column index setting”, and "Table partitioning data".
• In “Column constraints” column, “NOT NULL constraint” as NN is displayed.
• In the case of connecting through JDBC, the details of "Table partitioning data" are displayed. The displayed items are "Partitioning Type", "Partitioning Column", "Partition Interval Value", "Partition Interval Unit" of interval partitioning, and "Partition Division Count" of hash partitioning. For interval-hash partitioning, the items of interval partitioning and hash partitioning are both displayed.
• Example:

  // Display the specified container data (in the case of connecting through JDBC)
  gs[public]> showcontainer cont003
  Database    : userDB
  Name        : time018
  Type        : TIME_SERIES
  Partition ID: 15
  DataAffinity: -
  Partitioned             : true
  Partition Type          : INTERVAL
  Partition Column        : date
  Partition Interval Value: 730
  Partition Interval Unit : DAY
  Partition Division Count: -
  Sub Partition Type          : HASH
  Sub Partition Column        : id
  Sub Partition Interval Value: -
  Sub Partition Interval Unit : -
  Sub Partition Division Count: 15
  
  Columns:
  No  Name                  Type            CSTR  Index
  ------------------------------------------------------------------------------
   0  date                  TIMESTAMP       -     TREE(myIndex)   [RowKey]
   1  id                    DOUBLE          NN    
  
  
  // Display the specified container data (not in the case of connecting through JDBC)
  gs[public]> showcontainer cont003
  Database    : userDB
  Name        : time018
  Type        : TIME_SERIES
  Partition ID: 15
  DataAffinity: -
  Partitioned : true(need SQL connection for details)
  
  Columns:
  No  Name                  Type            CSTR  Index
  ------------------------------------------------------------------------------
   0  date                  TIMESTAMP       -     TREE(myIndex)   [RowKey]
   1  value                 DOUBLE          NN    
  
  

Display a table data. It is compatible command of showcontainer.

• Sub-command

  showtable

  <Table name>

• Description of each argument

  Argument	Description
  Table name	Specify the table name to be displayed. Display a list of all tables if omitted.

Create an index in the column of a specified container.

• Sub-command

  createindex

  <Container name> <Column name> <Index type> ...

• Description of each argument

  Argument	Description
  Container name	Specify the name of container that the column subject to the index operation belongs to.
  Column name	Specify the name of the column subject to the index operation.
  Index type ...	Specify the index type. Specify TREE, HASH or SPATIAL (or multiple) for the index type.

• Example:

  // create index
  gs[public]> createindex cont003 col2 tree hash
  
  gs[public]> showcontainer cont003
  Database    : public
  Name        : cont003
  Type        : COLLECTION
  Partition ID: 15
  DataAffinity: -
  
  Columns:
  No  Name                  Type            Index
  ------------------------------------------------------------
   0  col1                  INTEGER         [TREE] (RowKey)
   1  col2                  STRING          [TREE, HASH]
   2  col3                  TIMESTAMP       []
  

[Memo]

• An error will not occur even if an index that has already been created is specified.
• An index name is not supported. In case of specifying an index name, use the detailed version or SQL.

Delete the index in the column of a specified container.

• Sub-command

  dropindex

  <Container name> <Column name> <Index type> ...

• Description of each argument

  Argument	Description
  Container name	Specify the name of container that the column subject to the index operation belongs to.
  Column name	Specify the name of the column subject to the index operation.
  Index type ...	Specify the index type. Specify TREE, HASH or SPATIAL (or multiple) for the index type.

• Example:

  // delete index
  gs[public]> showcontainer cont003
  Database    : public
  Name        : cont003
  Type        : COLLECTION
  Partition ID: 27
  DataAffinity: -
  
  Columns:
  No  Name                  Type            CSTR  Index
  ------------------------------------------------------------------------------
   0  col1                  INTEGER         NN    TREE()   [RowKey]
   1  col2                  STRING                TREE() HASH(myIndex)
   2  col3                  TIMESTAMP       NN    HASH()
  
  gs[public]> dropindex cont003 col2 hash
  
  gs[public]> showcontainer cont003
  Database    : public
  Name        : cont003
  Type        : COLLECTION
  Partition ID: 27
  DataAffinity: -
  
  Columns:
  No  Name                  Type            CSTR  Index
  ------------------------------------------------------------------------------
   0  col1                  INTEGER         NN    TREE()   [RowKey]
   1  col2                  STRING                TREE()
   2  col3                  TIMESTAMP       NN    HASH()
  

[Memo]

• An error will not occur even if an index that has not been created is specified.

Delete the trigger of a specified container.

• Sub-command

  droptrigger

  <Container name> <Trigger name>

• Description of each argument

  Argument	Description
  Container name	Specify the name of the container whose trigger is going to be deleted.
  Trigger name	Specify the trigger name to delete.

• Example:

  gs[public]> droptrigger con01 tri03
  

Display the trigger data of a specified container.

• Sub-command

  showtrigger

  <Container name> [<Trigger name>]

• Description of each argument

  Argument	Description
  Container name	Specify the container name to be displayed.
  Trigger name	Specify the trigger name to be displayed. Display a list of all trigger data if omitted.

• Example:

  // Display the trigger data list of the specified container
  gs[public]> showtrigger cont003
  Name                 Type  Columns              Events
  ---------------------------------------------------------------
  rtrig01              REST  [col1, col3]         [PUT]
  
  gs[public]> showtrigger cont003 rtrig01
  Name          : rtrig01
  Type          : REST
  Target Columns: [col1, col3]
  Target Events : [PUT]
  
  Destination URI: http://example.com
  

[Memo]

• The data displayed in a trigger list are the “Trigger name”, “Notification method”, “Column to be notified”, “Operation to be monitored (create new or update, delete a row)”.
• The data displayed in the specified trigger data are the “Trigger name”, “Notification method”, “Column to be notified”, “Operation to be monitored” and “Notification destination URI”. In addition, the “Destination name”, “Destination type“, “User“ and “Password” are also displayed together in a JMS notification.
• See the chapter on “Trigger Function” in the “GridDB API Reference” (GridDB_API_Reference.html) for the trigger function details.

Display the executed sub-command in the standard output.

• Sub-command

  echo

  <Boolean>

• Description of each argument

  Argument	Description
  Boolean	Display the executed sub-command in the standard output when TRUE is specified. Default value is FALSE.

• Example:

  // display the executed sub-command in the standard output
  gs> echo TRUE
  

[Memo]

• gs_sh prompt "gs>" always appear in the standard output.

Display the definition details of the specified character string or variable.

• Sub-command

  print

  <Message>

• Description of each argument

  Argument	Description
  Message	Specify the character string or variable to display.

• Example:

  // display of character string
  gs> print print executed.
  print executed.
  

[Memo]

• Append "$" in front of the variable name when using a variable.

Set the time for the sleeping function.

• Sub-command

  sleep

  <No. of sec>

• Description of each argument

  Argument	Description
  No. of sec	Specify the no. of sec to go to sleep.

• Example:

  // sleep for 10 sec
  gs> sleep 10
  

[Memo]

• Specify a positive integer for the no. of sec number.

Execute an external command.

• Sub-command

  exec	<External command> [<External command arguments>]

• Description of each argument

  Argument	Description
  External command	Specify an external command.
  External command arguments	Specify the argument of an external command.

• Example:

  // display the file data of the current directory
  gs> exec ls -la
  

[Memo]

• Pipe, redirect, and hear document cannot be used.

Terminate gs_sh.

• Sub-command

  exit
  quit

• Example:

  // terminate gs_sh.
  gs> exit
  

In addition, if an error occurs in the sub-command, the setting can be configured to end gs_sh.

• Sub-command

  errexit

  <Boolean>

• Description of each argument

  Argument	Description
  Boolean	If TRUE is specified, gs_sh ends when an error occurs in the sub-command. Default is FALSE.

• Example:

  // configure the setting so as to end gs_sh when an error occurs in the sub-command
  gs> errexit TRUE
  

[Memo]

• There is no functional difference between the exit sub-command and quit sub-command.

Display a description of the sub-command.

• Sub-command

  help	[<Sub-command name>]

• Description of each argument

  Argument	Description
  Sub-command name	Specify the sub-command name to display the description Display a list of the sub-commands if omitted.

• Example:

  // display the description of the sub-command
  gs> help exit
  exit
  The above command is used to terminate gs_sh.
  

[Memo]

• A description of gs_sh can be obtained with the command “gs_sh --help”.

Display the version of gs_sh.

• Sub-command

  version

• Example:

  // display the version
  gs> version
  gs_sh version 2.0.0
  

[Memo]

• The gs_sh version data can be obtained with the command “gs_sh --version” as well.

• Commands

  gs_sh	[<Script file>]
  gs_sh	-v|--version
  gs_sh	-h|--help

• Options

  Option	Essential	Description
  -v|--version		Display the version of the tool.
  -h|--help		Display the command list as a help message.

[Memo]

• In order to batch process the gs_sh sub-command, a script file can be created. Extension of the script file is gsh.
• During gs_sh startup, .gsshrc script files under the gsadm user home directory are imported automatically. The .gsshrc contents will also be imported to the destination from other script files.

• GridDB cluster definition sub-command list

  Sub-command	Argument	Description	(*1)
  setnode	<Node variable> <IP address>	Define the node variable.
  	<Port no.> [ <SSH port no.> ]
  setcluster	<Cluster variable> <Cluster name>	Define the cluster variable.
  	<Multicast address> <Port no.>
  	[ <Node variable> ... ]
  setclustersql	<Cluster variable> <Cluster name>	Define the SQL connection destination in the cluster configuration.
  	<SQL address> <SQL port no.>
  modcluster	<Cluster variable>	Add or delete a node variable to or from the cluster variable.
  	add|remove <Node variable> ...
  setuser	<User name> <Password>	Define the user and password to access the cluster.
  	[ <gsadm password> ]
  set	<Variable name> [ <Value> ]	Define an arbitrary variable.
  show	[ <Variable name> ]	Display the detailed definition of the variable.
  save	[ <Script file name> ]	Save the variable definition in the script file.
  load	[ <Script file name> ]	Read and execute a script file.

• GridDB cluster operation sub-command list

  Sub-command	Argument	Description	*1
  startnode	<Node variable> | <Cluster variable> [ <Timeout time in sec.> ]	Start the specified node.	*
  stopnode	<Node variable> | <Cluster variable> [ <Timeout time in sec.> ]	Stop the specified node.	*
  stopnodeforce	<Node variable> | <Cluster variable> [ <Timeout time in sec.> ]	Stop the specified node by force.	*
  startcluster	<Cluster variable> [ <Timeout time in sec.> ]	Attach the active node groups to a cluster, together at once.	*
  stopcluster	<Cluster variable> [ <Timeout time in sec.> ]	Detach all of the currently attached nodes from a cluster, together at once.	*
  joincluster	<Cluster variable> <Node variable> [ <Timeout time in sec.> ]	Attach a node individually to a cluster.	*
  leavecluster	<Node variable> [ <Timeout time in sec.> ]	Detach a node individually from a cluster.	*
  leaveclusterforce	<Node variable> [ <Timeout time in sec.> ]	Detach a node individually from a cluster by force.	*
  appendcluster	<Cluster variable> <Node variable> [ <Timeout time in sec.> ]	Add an undefined node to a pre-defined cluster.	*
  configcluster	<Cluster variable>	Display the cluster status data.	*
  config	<Node variable>	Display the cluster configuration data.	*
  stat	<Node variable>	Display the cluster configuration data.	*
  logs	<Node variable>	Display the log of the specified node.	*
  logconf	<Node variable> [ <Category name> [ <Output level> ] ]	Display and change the log settings.	*

  *1 : Commands marked with an * can be executed by an administrator user only.
  
• Data operation sub-command list

  Sub-command	Argument	Description	*1
  connect	<Cluster variable> [ <Database name> ]	Connect to a GridDB cluster.
  tql	<Container name> <Query;>	Execute a search and retain the search results.
  get	[ <No. of acquires> ]	Get the search results and display them in a stdout.
  getcsv	<CSV file name> [ <No. of acquires> ]	Get the search results and save them in a file in the CSV format.
  getnoprint	[ <No. of acquires> ]	Get the query results but do not display them in a stdout.
  tqlclose		Discard the search results retained.
  tqlanalyze	<Container name> <Query;>	Execute the specified TQL command and display the execution plan and actual measurement values such as the number of cases processed etc.
  tqlexplain	<Container name> <Query;>	Displays the execution plan of the specified TQL command.
  sql	<SQL command;>	Executes an SQL command and retains the search result.
  sqlcount	<Boolean>	Set whether to execute count query when SQL querying.
  queryclose		Close SQL.
  disconnect		Disconnect user from a GridDB cluster.

  *1 : Commands marked with an * can be executed by an administrator user only.
  
• Database management sub-command list

  Sub-command	Argument	Description	*1
  createdatabase	<Database name>	Create a database.	*
  dropdatabase	<Database name>	Delete a database.	*
  getcurrentdatabase		Display the current database name.
  showdatabase	[ <Database name> ]	Display the database list and access permissions data.
  grantacl	<Database name> <User name>	Grant the database access rights to user.	*
  revokeacl	<Database name> <User name>	Revoke access rights to the database.	*

  *1 : Commands marked with an * can be executed by an administrator user only.
  
• User management sub-command list

  Sub-command	Argument	Description	*1
  createuser	<User name> <Password>	Create a general user.	*
  dropuser	<User name>	Delete a general user.	*
  setpassword	<Password>	Change the own password.
  setpassword	<User name> <Password>	Change the password of a general user.
  showuser	[ <User name> ]	Displays the user data.

  *1 : Commands marked with an * can be executed by an administrator user only.
  
• Container management sub-command list

  Sub-command	Argument	Description	*1
  createcollection	<Container name> <Column name> <Column type> [<Column name> <Column type> ...]	Create a container (collection).
  createtimeseries	<Container name> <Compression method> <Column name> <Column type> [<Column name> <Column type> ...]	Create a container (timeseries container).
  createcontainer	<Container data file> [ <Container name> ]	Create a container from the container data file.
  dropcontainer	<Container name>	Delete a container.
  showcontainer	[ <Container name> ]	Display the container data.
  showtable	[ <Table name> ]	Display the table data.
  createindex	<Container name> <Column name> <Index type> ...	Create an index in the specified column.
  dropindex	<Container name> <Column name> <Index type> ...	Delete an index of the specified column.
  droptrigger	<Container name> <Trigger name>	Delete the trigger data.
  showtrigger	<Container name> [ <Trigger name> ]	Display the trigger data.

  *1 : Commands marked with an * can be executed by an administrator user only.
  
• Other operation sub-command list

  Sub-command	Argument	Description	*1
  echo	<Boolean>	Set whether to echo back.
  print	<Message>	Display the definition details of the specified character string or variable.
  sleep	<No. of sec>	Set the time for the sleeping function.
  exec	<External command> [ <External command arguments> ]	Execute an external command.
  exit		Terminate gs_sh.
  quit		Terminate gs_sh.
  errexit	<Boolean>	Set whether to terminate gs_sh when an error occurs.
  help	[ <Sub-command name> ]	Display a description of the sub-command.
  version		Display the version of gs_sh.

  *1 : Commands marked with an * can be executed by an administrator user only.
  

Execute the GridDB start node command on the machine executing the node. This command needs to be executed for each GridDB node.

• Command

  gs_startnode	[-w|--wait [<No. of sec>] -u <User name>/<Password>]
  	[--releaseUnusedFileBlocks]

• Options

  Option	Description
  --releaseUnusedFileBlocks	Deallocate unused file blocks.

[Memo]

• Specify the user name and password with -u option. If omitted, start configuration file will be referred.
  • If the specified user name or password is invalid, an authentication error occurs.
• By waiting for start completion with -w option, the following gs_joincluster command can be executed safely.
  • Start completion means that the recovery of the database is completed.
• See the GridDB technical reference (GridDB_TechnicalReference.html) for details of the --releaseUnusedFileBlocks option.

The following command is used to stop the GridDB node. To stop a node, the GridDB cluster management process needs to be stopped first.

• Command

  gs_stopnode	[-f|--force]
  	[-k|--kill]
  	[-w|--wait [<No. of sec>]]
  	[-s <Server>[:<Port no.>] | -p <Port no.>]
  	-u <User name>/<Password>

• Options

  Option	Description
  -f|--force	Stop a node by force.
  -k|--kill	Force the node process of a local machine to stop.

[Memo]

• When stopping a specific node, the node cannot be stopped if it is joined to the cluster configuration. Stop the node after its detachment from the cluster (gs_leavecluster).
• When stopping all nodes, stop the GridDB cluster management process (gs_stopcluster) first and then stop the nodes in sequence.
• When a node is stopped, it may take a while for the process to be actually terminated due to the checkpoint process. Wait for a while until the node has stopped completely.
• Although a node can be forced to stop by specifying a --force option or --kill option, there is a risk that data may be lost.
• The node process of a remote machine cannot be stopped with the --kill option.

• Command

  gs_adduser	<User name>
  	[-p|--password <Password>]

• Options

  Option	Description
  User name	The username should start with "gs#", and only one or more ASCII alphanumeric characters and the underscore sign “_” can be used after “gs#”.
  -p|--password <Password>	A prompt to input the password interactively appears by default.

[Memo]

• Execute as an OS user gsadm.
• The password is encrypted during registration.
• When an administration user is registered, distribute the user definition file of the node which executed the command to all the nodes, stop the cluster, restart the nodes, and then recompose the cluster.
• Users registered before V2.5 can be used directly as administrator users.
• Only “admin“, “system” can be re-registered even after they are deleted.

[Example]

• Add an administrator user (“user name (gs#someone)”, “password (opensesami)”) to the user definition file.

  $ gs_adduser -p opensesami gs#someone 
  $ gs_stopcluster -u admin/admin
  Execute the following in all the nodes
  $ gs_stopnode -u admin/admin
  $ cp [User definition file with additional users] /var/lib/gridstore/conf/password
  $ gs_startnode
  $ gs_joincluster -c clsA  -n XX -u admin/admin
  

• Command

  gs_deluser

  <User name>

[Memo]

• Execute as an OS user gsadm.
• When an administration user is deleted, distribute the user definition file of the node which executed the command to all the nodes, stop the cluster, restart the nodes, and then recompose the cluster.

[Example]

• Delete the specified administrator user (gs#someone).

  $ gs_deluser gs#someone
  $ gs_stopcluster -u admin/admin
  Execute the following in all the nodes
  $ gs_stopnode -u admin/admin
  $ cp [User definition file with deleted users] /var/lib/gridstore/conf/password
  $ gs_startnode
  $ gs_joincluster -c clsA  -n XX -u admin/admin
  

• Command

  gs_passwd	<User name>
  	[-p|--password <Password>]

• Options

  Option	Description
  User name	The name of the administrator user whose password is going to be changed.
  -p|--password <Password>	Specify the password of the administrator user. A prompt to input the password interactively appears by default.

[Memo]

• Execute as an OS user gsadm.
• The password is encrypted during registration.
• When the password of an administration user is changed, distribute the user definition file of the node which executed the command to all the nodes, stop the cluster, restart the nodes, and then recompose the cluster.

[Example]

• Change the password of a specified administrator user (“user name (gs#someone)”) to foobarxyz.

  $ gs_passwd -p foobarxyz gs#someone 
  $ gs_stopcluster -u admin/admin
  Execute the following in all the nodes
  $ gs_stopnode -u admin/admin
  $ cp [Revised user definition file] /var/lib/gridstore/conf/password
  $ gs_startnode
  $ gs_joincluster -c clsA  -n XX -u admin/admin
  

When composing a GridDB cluster, the nodes need to be attached (joined) to the cluster. The following command is used to attach the nodes.

• Command

  gs_joincluster	[-c|--clusterName <Cluster name>]
  	[-n|--nodeNum <No. of nodes constituting a cluster>]
  	[-w|--wait [<No. of sec>]]
  	[-s <Server>[:<Port no.>]| -p <Port no.>]
  	-u <User name>/<Password>

• Options

  Option	Description
  -c|--clusterName <Cluster name>	Specify the cluster name. Default value is "defaultCluster”.
  -n|--nodeNum <No. of nodes constituting a cluster>	Specify the number of nodes of the cluster to be composed. Default value is 1 (single node configuration).

[Memo]

• It is recommended to use a different cluster name than the default.
• If the cluster name of the cluster definition file ( /cluster/clusterName ) has been set up, an error will occur if the specified cluster name does not match the value set.
• When attaching a new node to a stable cluster, use the node expansion command (gs_appendcluster).
• When composing a cluster by attaching a node to the cluster from a specific machine, use the -w option to wait for the process to complete.
• If a large scale expansion is required, stop the cluster once and then reconstitute the cluster with the new set of nodes.

[Example] Compose a 3-node cluster with the cluster name “example_three_nodes_cluster” using node A - C

• Start the nodes constituting the cluster and attach them to the cluster.

  Execute on node A
  $ gs_startnode
  $ gs_joincluster -c example_three_nodes_cluster -n 3 -u admin/admin -w
  Execute on node B
  $ gs_startnode
  $ gs_joincluster -c example_three_nodes_cluster -n 3 -u admin/admin -w
  Execute on node C
  $ gs_startnode
  $ gs_joincluster -c example_three_nodes_cluster -n 3 -u admin/admin -w
  

• Node commencement is done separately in each of the nodes (as shown above) and node entry is performed from a specific node (as shown below). In the following case, node entry is done at A.

  Execute on node A - C respectively
  $ gs_startnode
  Execute on node A
  $ gs_joincluster -c example_three_nodes_cluster -n 3 -s <node B's server address> -u admin/admin
  $ gs_joincluster -c example_three_nodes_cluster -n 3 -s <node C's server address> -u admin/admin
  $ gs_joincluster -c example_three_nodes_cluster -n 3 -u admin/admin -w
  

The following command is used to detach a node from a cluster.

• Command

  gs_leavecluster	[-f|--force]
  	[-w|--wait [<No. of sec>]]
  	[-s <Server>[:<Port no.>]| -p <Port no.>]
  	-u <User name>/<Password>

• Options

  Option	Description
  -f|--force	Detach a node by force.

[Memo]

• Use the cluster stop command (gs_stopcluster) to stop a cluster with a single node configuration.
• If there is a risk of data loss, the node cannot leave the cluster.
  • Use the --force option to force the node to leave the cluster. Stop the cluster first to detach the node safely off of the cluster.
• A cluster will be stopped automatically if the number of nodes participating in a cluster is reduced to less than half the number of nodes constituting the cluster due to nodes leaving the cluster.

[Example]

• Execute a leave cluster command on the node that you want to detach from the cluster.

  $ gs_leavecluster -u admin/admin
  

The following command is used to stop a cluster.

• Command

  gs_stopcluster	[-w|--wait [<No. of sec>]]
  	[-s <Server>[:<Port no.>]|-p <Port no.>]
  	-u <User name>/<Password>

[Memo]

• To confirm that a cluster has come to a complete stop, check the status of all nodes constituting the cluster.
• To detach a node from a cluster not in operation, use the leave cluster command (gs_leavecluster).

[Example]

• Execute a cluster stop command.

  $ gs_stopcluster -u admin/admin
  

The following command is used to get the cluster configuration data (data on list of nodes joined to a cluster).

• Command

  gs_config	[-s <Server>[:<Port no.>]| -p <Port no.>]
  	-u <User name>/<Password>
  	[-a|--address-type <Address type>]

• Options

  Option	Description
  -a|--address-type <Address type>	Specify the service type of the port, address to display.
  	system: Connection address of operating command
  	cluster: Reception address used for cluster administration
  	transaction: Reception address for transaction process
  	sync: Reception address used for synchronization process

[Memo]

• Address and port information of "master" (master node), "follower" (follower node), "self" (node which executed the command) will be displayed.
• Address and port information for multicast distribution to the clients will be displayed in “multicast”.
• The system status (status) will be one of the following.
  • INACTIVE: Stop
  • ACTIVATING: Start operation
  • ACTIVE: In operation
  • DEACTIVATING: Start stop
  • ABNORMAL: Abnormal stop
  • NORMAL_SHUTDOWN: Start normal shutdown

[Example]

• The following data is output when the cluster is composed of 3 nodes and cluster configuration data is acquired from the master.

  $ gs_config -u admin/admin
  {
      "follower": [                       // [array] follower data
          {
              "address": "192.168.11.10", // [string] connection address of operating command
              "port": 10040               // [number] connection port of operating command
          },
          {
             "address": "192.168.11.11",
             "port": 10040
          }
      ],
      "master": {                         // master data
          "address": "192.168.11.12",     // [string] connection address of operating command
          "port": 10040                   // [number] connection port of operating command
      },
      "multicast": {                      // multicast data
          "address": "239.0.0.20",        // [string] address for multi-cast distribution to client
          "port": 31999                   // [number] Port for multi-cast distribution to client
      },
      "self": {                           // own node data
          "address": "192.168.11.12",     // [string] connection address of operating command
          "port": 10040,                  // [number] connection port of operating command
          "status": "ACTIVE"              // [string] system status
      }
  }
  

The following command gets the cluster data (cluster configuration data and internal data), or backup progress status.

• Command

  gs_stat	[-t|--type <Type>]
  	[-a|--address-type <Address type>]
  	[--member]
  	[-s <Server>[:<Port no.>]|-p <Port no.>]
  	-u <User name>/<Password>

• Options

  Option	Description
  -t|--type <Type>	Display data of the specified type.
  	backup: Display the backup status
  -a|--address-type <Address type>	Specify the service type of the port, address to display.
  	system: Connection address of operating command
  	cluster: Reception address used for cluster administration
  	transaction: Reception address for transaction process
  	sync: Reception address used for synchronization process
  --member	When the cluster configuration method is the fixed list method or provider method, an address list of the cluster configuration members currently recognized by the node is displayed.

[Memo]

• The cluster status (/cluster/clusterStatus) will be one of the following.
  • MASTER: Master
  • SUB_MASTER: Sub-master
  • FOLLOWER: Follower
  • SUB_FOLLOWER: Sub-follower
  • SUB_CLUSTER: cluster is not in operation
• The system status (/cluster/nodeStatus) will be one of the following.
  • INACTIVE: Stop
  • ACTIVATING: Start operation
  • ACTIVE: In operation
  • DEACTIVATING: Start stop
  • ABNORMAL: Abnormal stop
  • NORMAL_SHUTDOWN: Start normal termination
• The name of the backup process under execution or last executed is displayed in the backup status (/checkpoint/mode).
  • -: Completed or not in operation
  • NORMAL_CHECKPOINT: Periodic checkpoint
  • REQUESTED_CHECKPOINT: Manual checkpoint
  • BACKUP: Full backup
  • RECOVERY_CHECKPOINT: Checkpoint (during recovery)
  • SHUTDOWN_CHECKPOINT: Checkpoint (during shutdown)
  • INCREMENTAL_BACKUP_LEVEL_0: baseline of differential/incremental backup
  • INCREMENTAL_BACKUP_LEVEL_1_CUMULATIVE: differential backup
  • INCREMENTAL_BACKUP_LEVEL_1_DIFFERENTIAL: Incremental backup

[Example]

• The following data is output when cluster data is acquired by nodes joined to the cluster in operation.

  $ gs_stat -u admin/admin
  {
                  :
                  :
      "cluster": {
          "activeCount": 1,
          "clusterName": "defaultCluster",
          "clusterStatus": "MASTER",
          "designatedCount": 1,
          "loadBalancer": "ACTIVE",
          "master": {
              "address": "192.168.10.11",
              "port": 10010
          },
          "nodeList": [
              {
                  "address": "192.168.10.11",
                  "port": 10010
              }
          ],
          "nodeStatus": "ACTIVE",
          "partitionStatus": "NORMAL",
          "startupTime": "2014-08-29T09:56:20+0900",
          "syncCount": 3
      },
                  :
                  :
  }
  

Add a new node to a cluster in operation.

• Command

  gs_appendcluster	--cluster <Server>:<Port no.>
  	[-w|--wait [<No. of sec>]]
  	[-s <Server>[:<Port no.>] | -p <Port no.>]
  	-u <User name>/<Password>

• Options

  Option	Description
  --cluster <Server>:<Port no.>	Specify the server name (address) and port no. of the node to be added to the cluster.

[Memo]

• This operation is available only when the cluster is in operation and in a stable state (i.e. number of nodes already participating in a cluster = number of nodes constituting a cluster).
• If a large scale expansion is required, stop the cluster once and then reconstitute the cluster with the new set of nodes.
• When expanding a cluster with a single node configuration that is in operation, stop the cluster once first before re-composing the cluster.

[Example]

• Add a new node to a cluster in operation.

  Check the status of the cluster to add the nodes
  $ gs_stat -s 192.168.33.29:10040  -u admin/admin
  {
          :
      "cluster":{                                 // cluster-related
          "activeCount":5,                        // number of nodes already participating in a cluster
          "clusterName":"function_1",             // cluster name
          "clusterStatus":"MASTER",               // cluster status
          "designatedCount":5,                    // number of nodes constituting a cluster
          :
  }
  Check that the number of nodes = number of nodes already participating in a cluster
  If the number of nodes constituting a cluster> number of nodes already participating in a cluster, execute a gs_joincluster (add node to cluster configuration)
  
  Start the node you want to add and specify the server address and port no. of the node joined to the cluster in operation.
  $ gs_startnode
  $ gs_appendcluster --cluster 192.168.33.29:10040 -u admin/admin
  
  Check the cluster status to see if the node has been added successfully to the cluster.
  $ gs_stat  -u admin/admin
  {
          :
      "cluster":{                                 // cluster-related
          "activeCount":6,                        // number of nodes already participating in a cluster
          "clusterName":"function_1",             // cluster name
          "clusterStatus":"MASTER",               // cluster status
          "designatedCount":6,                    // number of nodes constituting a cluster
          :
  }
  

The following command is used to execute GridDB cluster failover.

• Command

  gs_failovercluster	[--repair]
  	[-s <Server>[:<Port no.>] | -p <Port no.>]
  	-u <User name>/<Password>

• Options

  Option	Description
  --repair	Accept the data lost and execute a forced failover.

[Memo]

• This command can only be executed when the cluster is in operation.
• Basically, the command is valid in the following cases as the cluster algorithm will be executed as a normal process.
  • The user detects a cluster error and executes a failover immediately.
  • At the end of the data recovery from the backup data, database recovery will be deemed to be complete and the system will be started even if the partition LSN maintained by the cluster is younger than the final update LSN (Permit data lost).

[Example]

• Execute a cluster failover.

  $ gs_failovercluster -u admin/admin
  

The following command is used to display the partition data of a GridDB node.

• Command

  gs_partition	[-n|--partitionId <Partition ID>]
  	[--loss]
  	[-a|--address-type <Address type>]
  	[-s <Server>[:<Port no.>] | -p <Port no.>]
  	-u <User name>/<Password>

• Options

  Option	Description
  -n|--partitionId <Partition ID>	Specify the partition ID to display data. (Display all data by default)
  --loss	Display only data from missing partitions.
  -a|--address-type <Address type>	Specify the service type of the port, address to display.
  	system: Connection address of operating command
  	cluster: Reception address used for cluster administration
  	transaction: Reception address for transaction process
  	sync: Reception address used for synchronization process

[Memo]

• The --loss option can be used only when a cluster is in operation.
• Missing partitions are partitions that cannot be accessed, including those holding replicas.

[Example]

• Get the partition data of a specific node of a cluster in operation.

  $ gs_partition -u admin/admin
  [
      {
          "backup": [],
          "catchup": [],
          "maxLsn": 300008,
          "owner": {
              "address": "192.168.11.10",
              "lsn": 300008,
              "port": 10010
          },
          "pId": "0",
          "status": "ON"
      },
          :
  ]
  

Increase the no. of nodes of the GridDB cluster.

• Command

  gs_increasecluster	[-s <Server>[:<Port no.>] | -p <Port no.>]
  	-u <User name>/<Password>

[Memo]

• It runs only when the cluster is running and it is in stable state. Therefore, when adding a node to an active cluster, it is necessary to add one at a time.
• If you want to perform a large-scale expansion, stop the cluster and then reconfigure the cluster by specifying the number of expanded nodes as the number of initial configuration nodes.
• When a cluster is expanded by this command, if there is a node to be expanded, that node will join to the cluster. If there are multiple nodes to be added, one of the nodes will join to the cluster.
• If the node to be expanded is not present and the cluster is expanded by this command, if the node to be expanded is specified, that node will join to the cluster.
• It is not possible to extend a single node configuration cluster while it is running. Please reconfigure the cluster after stopping the cluster.

[Example]

• Increase the no. of nodes of the GridDB cluster and append node to the cluster.

  Confirm the cluster status.
  $ gs_stat -s 192.168.33.29:10040  -u admin/admin
  {
          :
      "cluster":{                                 // Cluster category
          "activeCount":5,                        // No. of the active nodes
          "clusterName":"function_1",             // Cluster name
          "clusterStatus":"MASTER",               // Cluster status
          "designatedCount":5,                    // No. of the designated nodes
          :
  }
  Confirm that the no. of the designated nodes is equaled to the no. of the active nodes.
  
  Start the node to be expanded, execute the gs_joincluster command with the no. of nodes after expansion (6 nodes).
  $ gs_startnode -u admin/admin -w
  $ gs_joincluster -u admin/admin -c function_1 -n 6
  
  Execute the gs_increasecluster for the cluster to be expanded.
  $ gs_increasecluster -s 192.168.33.29:10040 -u admin/admin
  
  Confirm that the node to be expanded has been added to the cluster.
  $ gs_stat  -u admin/admin
  {
          :
      "cluster":{                                 // Cluster category
          "activeCount":6,                        // No. of the active nodes
          "clusterName":"function_1",             // Cluster name
          "clusterStatus":"MASTER",               // Cluster status
          "designatedCount":6,                    // No. of the designated nodes
          :
  }
  

Enable/disable autonomous data redistribution of a GridDB cluster, or display the setting.

As in the case of stopping nodes and rejoining them in a cluster for rolling upgrade, by disabling autonomous data redistribution, you can eliminate redundant redistribution processing and reduce the load on the operations.

• Command

  gs_loadbalance	[--on|--off] [--cluster]
  	[-s Server[:<Port no.>] | -p <Port no.>]
  	-u <User name>/<Password>

• Options

  Option	Description
  --on|--off	Enable (--on) or Disable (--off) autonomous data redistribution.
  	If these options are omitted, the current setting value is displayed.
  --cluster	The setting is applied to all nodes of the cluster by specifying this option.
  	If this option is omitted, the setting is applied to only the specified node.

[Memo]

• When you disable the autonomous data redistribution, you have to restore the setting to enable it again later. While it is not active, data replication is not performed so that the availability against node failure becomes lower.

[Example]

Confirm the settings of autonomous data redistribution on all nodes in a cluster.
$ gs_loadbalance -s 192.168.33.29:10040  -u admin/admin --cluster
192.168.33.29 ACTIVE
192.168.33.30 ACTIVE
192.168.33.31 ACTIVE

Disable the setting of the node, "192.168.33.31".
$ gs_loadbalance -s 192.168.33.31:10040  -u admin/admin --off

Enable/disable the periodic checkpoint of a GridDB node, or execute manual checkpoint.

• Command

  gs_checkpoint	[--on|--off]|[--manual [-w|--wait [No. of sec]]]
  	[-s <Server>[:<Port no.>] | -p <Port no.>]
  	-u <User name>/<Password>

• Options

  Option	Description
  --on|--off	Enable (--on) or Disable (--off) the periodic checkpoint.
  	If these options are omitted, the current setting value is displayed.
  --manual	Perform the manual checkpoint.

[Memo]

• In operation, in case of disabling the periodic checkpoint temporarily, please be sure to re-enable it. While it is disabled, the size of transaction log file become larger and the time of backup operation or the time of recovery operation when restarting gets longer.

[Example]

# Disable the periodic checkpoint
$ gs_checkpoint -u admin/admin --off
# Perform the manual checkpoint and wait to complete.
$ gs_checkpoint -u admin/admin --manual -w
...
The manual checkpoint has been completed.
# Re-enable the periodic checkpoint
$ gs_checkpoint -u admin/admin --on

The following command is used to get the most recent GridDB event log.

• Command

  gs_logs	[-l|--lines <No. of rows acquired>]
  	[-g|--ignore <Exclusion key word>]
  	[-s <Server>[:<Port no.>] | -p <Port no.>]
  	-u <User name>/<Password>
  	[<First key word> [<Second key word>]]

• Options

  Option	Description
  -l|--lines <No. of rows acquired>	Specify the no. of rows to acquire.
  -g|--ignore <Exclusion key word>	Ignore rows that include exclusion key words.
  <First key word> [<Second key word>]	Get only rows that contain the key word.

[Memo]

• Event data is output in the following format.
  • Time, machine name, thread no., event type, event category, generation source file name, generation method, number of rows generated: Followed by any character string
• Check with the support desk for details.

[Example]

• Get logs terminated by the checkpoint 3 times.

  $ gs_logs -u admin/admin CP_END -l 3
  2014-08-04T11:02:52.754+0900 NODE1 1143 INFO CHECKPOINT_SERVICE ../server/checkpoint_service.cpp void CheckpointService::runCheckpoint(EventContext&, int32_t, const std::string&) line=866 : [CP_END] mode=NORMAL_CHECKPOINT, backupPath=, commandElapsedMillis=132
  2014-08-04T11:22:54.095+0900 NODE1 1143 INFO CHECKPOINT_SERVICE ../server/checkpoint_service.cpp void CheckpointService::runCheckpoint(EventContext&, int32_t, const std::string&) line=866 : [CP_END] mode=NORMAL_CHECKPOINT, backupPath=, commandElapsedMillis=141
  2014-08-04T11:42:55.433+0900 NODE1 1143 INFO CHECKPOINT_SERVICE ../server/checkpoint_service.cpp void CheckpointService::runCheckpoint(EventContext&, int32_t, const std::string&) line=866 : [CP_END] mode=NORMAL_CHECKPOINT, backupPath=, commandElapsedMillis=138
  

The following command is used to display or change the event log output level. Get the list of settings if the argument is not specified.

• Command

  gs_logconf	[-s <Server>[:<Port no.>]|-p <Port no.>]
  	-u <User name>/<Password>
  	[<Category name> <Output level>]

• Options

  Option	Description
  <Category name> <Output level>	Specify the category name and output level.

[Memo]

• When displaying a list of the event log output level, omit [Category output level] and execute.
• All output log data with an output level higher than the level specified will be output. For example, if INFO is set, the INFO, WARNING, and ERROR logs will be output.
• A list of the output levels from high to low is shown below.
  • ERROR
  • WARNING
  • INFO
  • DEBUG
• When a node is shutdown, settings changed by an executed command will not be saved.
• The log output level is either the default value given in gs_node.json of the sample, or a level lower than that is recommended to be set. Please refer to the list of parameters in Annex for the default value.

[Example]

• Change the log output level and display the event log status.

  $ gs_logconf -u admin/admin CHUNK_MANAGER INFO
  $ gs_logconf -u admin/admin
  {
      "levels": {
          "CHECKPOINT_SERVICE": "INFO",
          "CHECKPOINT_SERVICE_DETAIL": "ERROR",
          "CHUNK_MANAGER": "INFO",
          "CLUSTER_OPERATION": "INFO",
              :
              :
      }
  }
  

The following command is used to get GridDB backup data on a per-node basis while continuing services.

A backup of the entire cluster can be carried out while continuing services by backing up all the nodes constituting the cluster in sequence.

• Command

  gs_backup	[--mode <Mode> [--skipBaseline]]
  	-u <User name>/<Password>
  	<Backup name>

• Options

  Option	Description
  --mode <Mode>	Specify the backup mode.
  	- auto: auto backup
  	- auto_nostop: auto backup (no node stop when an error occurs)
  	- baseline: Create a full backup of the differential/incremental backup baseline
  	- since: After creating a baseline, perform a differential backup from the baseline of the updated data blocks
  	- incremental: After creating a baseline, or after the last incremental, since backup, perform an incremental backup of the updated data blocks
  --skipBaseline	If mode is auto or auto_nostop, omit a baseline backup operation.
  	Otherwise, ignore this option.
  Backup name	Specify the directory name of the backup data.

<mode option>

auto

As the data update log file is automatically copied to the backup directory, the user does not need to perform any backup. However, recovery may take a while when a failure occurs during backup of the log file. A full backup is recommended to be performed regularly.

auto_nostop

Even if an error occurred in the log output on the backup end, the node will not stop even though a trace log output will be carried out to stop duplicated output. If auto_nostop is not specified, the node will stop as a system error.

baseline

Create a backup data baseline. In a differential backup, differential data updated from the baseline is backed up.

since

After executing a backup with a specified baseline, updated data will be backed up (differential backup).

incremental

After executing a backup with a specified baseline, or after the last incremental, since backup was executed, updated data blocks will be backed up (incremental backup).

[Memo]

• Up to 12 alphanumeric characters can be set for the backup name.
• See “GridDB backup guide” (GridDB_BackupGuide.html) for the backup details.
• The backup file is created under the backup file directory specified in the node definition file (gs_node.json). It is recommended to store the backup file in a separate physical location from the data directory.
• When restoring a GridDB cluster database to the correct status, the backup and restoration processes need to be carried out for the entire cluster.
• Control will return after the command is executed but depending on the data size and online processing load, it may take several hours or more for the backup to complete. The progress status of the backup can be acquired with a gs_stat command.
• When a backup is performed while the cluster is in operation, the backup may be created with the entire cluster in a non-conforming state if multiple containers have are created. If necessary, ban transaction services so that the backup can be executed in the static state.
• In GridDB, data will be automatically re-arranged when a failure occurs. Therefore, if a failure occurs during backup, perform the backup again starting from the first node.
• When specifying --skipBaseline option with the automatic log backup, please take a backup using the other method instead of the online backup function of GridDB. See “GridDB backup guide” (GridDB_BackupGuide.html) for the details.

[Example]

• Perform a backup in the node being started

  Check the directory where the backup file is stored (backup directory)
  $ cat /var/lib/gridstore/conf/gs_node.json         # configuration check
  {
      "dataStore":{
          "dbPath":"/var/lib/gridstore/data",
          "backupPath":"/var/lib/gridstore/backup",  # backup directory
          "storeMemoryLimit":"1024MB",
          "concurrency":4,
          "logWriteMode":1,
          "persistencyMode":"NORMAL"
              ：
              ：
  }
  Execute backup
  $ gs_backup -u admin/admin 20150425        # backup execution
  
  Depending on the data size and load condition, it may take several hours or more for the backup to be completed.
  The progress status of the backup can be checked with a gs_stat command.
  $ gs_stat -u admin/admin --type backup        
  BackupStatus: Processing                          # backup in progress
  

• The backup status output by gs_stat (BackupStatus) is one of the following.
  • Processing: Full backup execution in progress
  • Processing (Baseline): Creation of differential/incremental backup baseline in progress (full backup)
  • Processing (Since): Differential backup in progress
  • Processing (Incremental) Incremental backup in progress
  • -: Completed or not in operation
• The following file is created upon executing a backup.
  • Directory specified in BACKUPNAME will be created under the backup directory ( /var/lib/gridstore/backup ). During a differential/incremental backup, BACKUPNAME_lv0 (baseline directory of differential/incremental backup ), BACKUPNAME_lv1_NNN_MMM (differential (Since) and incremental (Incremental) directory of differential/incremental backup) are created.
  • The backup files below will be created.
    • Checkpoint file (gs_cp_n_p.dat)
    • Transaction log file (gs_logs_n_m.log)
    • Backup data file (gs_backup_info.json,gs_backup_info_digest.json)
    • LSN data file (gs_lsn_info.json)

The following is used to get a list of the backup data in the backup directory set up in the node definition file (gs_node.json).

• Command

  gs_backuplist	[-s <Server>[:<Port no.>]|-p <Port no.>]
  	-u <User name>/<Password>
  	[--partitionId <Partition ID>|<Backup name>]

• Options

  Option	Description
  --partitionId <Partition ID>	Display the LSN data of the specified partition in a list.
  Backup name	Specify the backup name.

[Memo]

• A list of the backup data can be displayed regardless of the startup status of the nodes. The Status appears as “P” if the backup process is in progress with the nodes started.
• If the status displayed is NG, the backup file may be damaged and so restoration is not possible.
• Backup names marked with an “*” at the start of the name in the list display is differential/incremental backup data.
• The status of the differential/incremental backup is always displayed as "-". Multiple backups taken in differential/incremental backup can be checked with detailed data specifying the backup name.

[Example]

• Verify the backup data in the node where you want to check the list of backup data.

  Display a list of the backup names.
  $ gs_backuplist -u admin/admin
  
  BackupName   Status   StartTime                EndTime
  ------------------------------------------------------------------------
  *201504          --  2015-04-01T05:20:00+0900 2015-04-24T06:10:55+0900
  *201503          --  2015-03-01T05:20:00+0900 2015-04-24T06:05:32+0900
    :
   20141025NO2     OK   2014-10-25T06:37:10+0900 2014-10-25T06:37:10+0900
   
   
  Specify the individual backup name and display the detailed data.
  $ gs_backuplist -u admin/admin 201504
   
  BackupName : 201504
  
  BackupData            Status   StartTime                EndTime
  --------------------------------------------------------------------------------
  201504_lv0                OK  2015-04-01T05:20:00+0900 2015-04-01T06:10:55+0900
  201504_lv1_000_001        OK  2015-04-02T05:20:00+0900 2015-04-01T05:20:52+0900
  201504_lv1_000_002        OK  2015-04-03T05:20:00+0900 2015-04-01T05:20:25+0900
  201504_lv1_000_003        OK  2015-04-04T05:20:00+0900 2015-04-01T05:20:33+0900
  201504_lv1_000_004        OK  2015-04-05T05:20:00+0900 2015-04-01T05:21:15+0900
  201504_lv1_000_005        OK  2015-04-06T05:20:00+0900 2015-04-01T05:21:05+0900
  201504_lv1_001_000        OK  2015-04-07T05:20:00+0900 2015-04-01T05:22:11+0900
  201504_lv1_001_001        OK  2015-04-07T05:20:00+0900 2015-04-01T05:20:55+0900
  
  
  When investigating the LSN no. of the data maintained in the partition.
  $ gs_backuplist -u admin/admin --partitionId=68
   BackupName      ID   LSN
  ---------------------------------------------------------------------------------
  *201504          68   81512
  *201503          68   2349
   20140925        68   0
  
  

The following command is used to restore a GridDB backup file.

• Command

  gs_restore

  [--test] [--updateLogs] <Backup name>

• Options

  Option	Description
  --test	Get backup data used for restoration purposes without performing a restoration.
  --updateLogs	If specified, restore only log and json files and overwrite existing files.
  Backup name	Specify the directory name of the backup file to restore.

[Memo]

• When restoring data, the node needs to be stopped.
• Take note of the number of partitions and the parameter value of the processing parallelism in the cluster definition file. Set the configuration value of the node to restore to be the same as the configuration value of the backup node. The node cannot start correctly if it is not the same.
• If you want to restore the backup state correctly, the backup and restoration tasks need to be carried out for the entire cluster.
• For example, even if some of the nodes are restored, these nodes cannot be returned to the state they were in at the time of the backup. After restoration, it is necessary to attach the nodes to the cluster in operation in order to use the data. However, if the data is updated in the cluster after backup, the restored data will be updated by the (updated) cluster data. In particular, if the cluster configuration has changed from the time the backup was created, there will be no restoration effect. As the data will be autonomously re-arranged if the node is forced to join a cluster, there is a high probability that the data will become invalid even when restored.
• If data is missing in the backup data file, or if the contents have been revised, a GridDB node will not be able to start services.
• If a signal (Ctrl+C) is sent in the middle of a restoration and the process gets interrupted, the data in the middle of the restoration will be deleted.

[Example]

• Restore backup data. Execute a restoration with the executing node stopped.

  Move the files in the database file directory
  Specify the database file directory with the node definition file (gs_node.json)
  $ mv ${GS_HOME}/data/*.{dat,log} ${GS_HOME}/temp    # Move the database file
  
  
  Check the data to be restore prior to the restoration
  $ gs_restore --test 20150424
  
  BackupName : 20150424
  BackupFolder : /var/lib/gridstore/data/backup
  
  RestoreData           Status   StartTime                EndTime
  --------------------------------------------------------------------------------
  201504_lv0 
  201504_lv1_001_001        OK  2015-04-07T05:20:00+0900 2015-04-01T05:20:55+0900
  
  
  Execute a restoration
  $ gs_restore 20150424                       # restoration
  
  

• In this example, when a restore is executed, after the backup file group from the 201504_lv0 directory under the backup directory ( /var/lib/gridstore/backup ) is copied to the data directory ( /var/lib/gridstore/data ), data in 201504_lv1_001_001 is also copied.
• At the end of the restoration, follow the same procedure as a normal start-up to start the restored node and let it join a cluster.
• After start-up, the database file (backup file group) arranged by the restoration is imported and at the end of the import, the GridDB node starts services.

The following command is used to display or change the node parameters.

• Command

  gs_paramconf	[-s <Server>[:<Port no.>]|-p <Port no.>]
  	-u <User name>/<Password>
  	--show [<Parameter name>] | --set <Parameter name> <Value>

• Options

  Option	Description
  --show [<Parameter name>]	Display the specified parameter. If the parameter is not specified in the command, all parameters will be displayed instead.
  --set <Parameter name> <Value>	Change the specified parameter to the specified value.

[Memo]

• A parameter change (--set) changes the parameter value of a node in operation dynamically. When a node is shutdown, settings changed by the executed command will not be saved.
• The following are the 2 parameters that can be specified.
  • storeMemoryLimit: Upper limit of the store memory
  • checkpointMemoryLimit: Upper limit of the checkpoint memory
• See Parameter list for details including the data type of the parameter, etc.

[Example]

• Change the parameter storeMemoryLimit and display the value.

  $ gs_paramconf -u admin/admin --set storeMemoryLimit 2048MB
  $ gs_paramconf -u admin/admin --show storeMemoryLimit
  "2048MB"
  

Container data files are composed of metadata files and row data files.

A metadata file is a file in the json format which contains the container type and schema, the index set up, and the trigger data.

There are 2 types of row data file, one of which is the CSV data file in which container data is stored in the CSV format, and the other is the binary data file in which data is stored in a zip format.

• CSV data file:
  • Stores container row data as CSV data. Readability is high, and the file can be imported and edited with generic tools.
  • If the row data is a specific data type such as BLOB, spatial data, array etc., the data is stored in an external object file while only the external object file name is stored in a CSV data file. An external object file is created for each row data.
• Binary data file:
  • Stores container row data in the Zip format. Can be created with the command gs_export only. Size is smaller compared to a CSV data file. In addition, the number of files can be reduced as there is no need to create external object files. However, binary data files are not readable and cannot be edited.

See Format of a container data file for details of the contents described in each file.

In addition, there are 2 types of container data file as shown below depending on the number of containers to be listed.

• Single container configuration: Holds 1 container data file for each container
• Multi-container configuration: Consolidates multiple containers into a single container data file

Hereinafter, container data files of various configurations will be written as single container data file and multi-container data file.

When a large container is specified as a single container data file and export is executed, management becomes troublesome as a large amount of metadata files and row data files are created. On the other hand, even if a large container is specified as a multi-container data file, only 1 metadata file and row data file is output.

Therefore, it is recommended that these 2 configurations be used differently depending on the application.

A single container data file is used in the following cases.

• To output the current data of a specific container to perform data analysis.
• To create many containers with the same schema as existing containers to register data.

A multi-container data file is used in the following cases.

• To backup a specific container group.
• To move a database to a different GridDB cluster.

Data such as the export date and time, the number of containers, container name etc. is saved in the export execution data file. This file is required to directly recover exported data in a GridDB cluster.

[Memo]

• The file name of an export execution data file is gs_export.json.
• Delete the export execution data if an exported container data file is edited manually. A registration error may occur due to discrepancies in the data.
• When importing without any export execution data file, it is essential that the container metadata file be specified. If not, import will fail.
• When importing from RDB, the export execution data file is not required.

The client package containing the export/import functions and Java library package need to be installed.

[Example]

# rpm -Uvh griddb-xx-client-X.X.X-linux.x86_64.rpm
Preparing...                   ########################################### [100%]
User and group has already been registered correctly.
GridDB uses existing user and group.
   1:griddb-xx-client          ########################################### [100%]

# rpm -Uvh griddb-xx-java_lib-X.X.X-linux.x86_64.rpm
Preparing...                   ########################################### [100%]
   1:griddb-xx-java_lib        ########################################### [100%]

Property file is /var/lib/gridstore/expimp/conf/gs_expimp.properties . Set together with the GridDB cluster configuration used as a gsadm user.

The property file contains the following settings.