Specifies a file that lists the username and password of the account to use when connecting to a database with security enabled. This is useful when writing shell scripts because it avoids having to hardcode the password as plain text in the script. The credentials file is interpreted as a Java properties file defining the properties username and password. For example:

username: johndoe
password: 4tUn8

Because it is a Java properties file, you must escape certain special characters in the username or password, including the colon or equals sign.

Displays information about how to use a command. The --help flag and the help command perform the same function.

Specifies which database server to connect to. You can specify the server as a network address or hostname. When specifying an IPv6 address, enclose the address (exclusive of the optional colon and port number) in square brackets. By default, voltadmin attempts to connect to a database on localhost. You can optionally specify the port number. If you do not specify a port, voltadmin uses the default admin port.

Specifies the use of Kerberos authentication when connecting to the database. You must login to your Kerberos account using kinit before issuing the voltadmin with this argument.

Specifies the password to use when connecting to the database. You must specify a username and password if security is enabled for the database. If you specify a username with the --user argument but not the --password argument, VoltDB prompts for the password. This is useful when writing shell scripts because it avoids having to hardcode passwords as plain text in the script.

Specifies the use of TLS encryption when communicating with the server. Only necessary if the cluster is configured to use TLS encryption for the external ports. See the section called “Using CLI Commands with TLS/SSL” for more information.

Specifies the username to use for authenticating to the database. The username is required if the database has security enabled.

Displays additional information about the specific commands being executed.

Performs a defragmentation operation on the memory used to store database records. By default, one iteration of memory compaction is performed using the standard settings for memory management. However, you can use optional arguments to the command to control how much compaction is done and which tables are affected. See the chapter on "Understanding Memory Usage" in the Volt Guide to Performance and Customization for more information about how memory compaction is done and the minimum requirements and controls available for managing the defragmentation process.

The --full and --maxcount options are mutually exclusive. If you specify both, --maxcount is ignored.

Displays information about the usage of individual commands or, if you do not specify a command, summarizes usage information for all commands. The help command and --help qualifier are synonymous.

Removes the current cluster from an XDCR environment. Performing a drop breaks existing DR connections, deletes pending binary logs and stops the queuing of DR data on the current cluster. It also tells all other clusters in the XDCR relationship to drop their connection to the current cluster and remove any associated binary logs for that cluster.

This command will wait until all other clusters respond before returning to the shell prompt. If one (or more) of the clusters are unreachable, the command will periodically report which clusters it is waiting for. Be aware that if you CTRL-C out of the command before it returns to the shell prompt, one or more of the remote clusters will not have received the appropriate message and will not have cleared their logs for the targeted cluster. In that case, you need to clear that cluster's queues manually after it comes back online using the dr reset --cluster command.

The dr drop command lets you effectively remove a single cluster — the cluster on which the the command is executed — from a multi-cluster XDCR environment in a single command.

Reports the current DR protocol that is in use and that is supported by each of the clusters with a DR connection to the current cluster. This information is useful when upgrading XDCR clusters and determining if they are capable of using dynamic schema change or not.

If all of the clusters support a higher protocol version than the current cluster is using, you can use the --update argument to have the cluster move to the higher protocol version.

Resets the database replication (DR) connection(s) for the database. Performing a reset breaks existing DR connections, deletes pending binary logs and stops the queuing of DR data on the current cluster.

After a reset, DR must start over from scratch; it cannot be restarted where it left off. Similarly, if there are two clusters in an XDCR environment, you can use dr reset for one cluster to drop the connection to the other cluster.

If you are using multiple XDCR clusters, the dr drop command is the recommended way to remove a running cluster from the environment. Otherwise, if you use the dr reset command you must choose between removing the connections to all other clusters or just one cluster using the following options. You must issue the appropriate command on all applicable clusters:

The --all and --cluster options are mutually exclusive.

Resets any blocked export queues, resuming export at the next available export record. You must specify both of the export release qualifiers:

Displays information about the configuration of the database. If you specify a specific property (such as deployment.cluster.kfactor), it displays the value of that property. If you specify the name of a parent in the property hierarchy (such as deployment.export), it displays all of the configuration values under that branch. If you do not specify a property or specify the top-most parent, deployment, all of the configuration properties are displayed.

Displays information about the software, license, and cluster operating environment. Primarily used when communicating with customer support.

Saves the current state of all Java threads on one or more of the cluster nodes. If you specify a server on the command line, Jstacks are taken for that node only. If you do not specify a server, Jstacks are saved on all nodes of the cluster. The Jstack files are saved in the thread_dumps subfolder under the database root directory. This command is primarily for use when working with VoltDB support to debug application or database issues.

Updates the software license for the database. After validating the license matches the current configuration, the license is saved to the database root directory for each node in the cluster.

Updates the logging configuration. You specify the new configuration as a Log4j XML configuration file.

Writes the specified text message to the VoltDB log file. When security is enabled, the user must have admin permissions to write to the log file.

Pauses the database, stopping any additional activity on the client port. Normally, pause returns immediately. However, you can use the --wait flag to have the command wait until all pending transactions are processed and all database replication (DR) and export queues are flushed. Use of --wait is recommended if you are shutting down the database and do not intend to restart with recover, since --wait ensures all associated DR or export data is delivered prior to shutdown.

Since it is possible that lost connections to external systems or other abnormal conditions can cause queues to hang, the pause --wait command waits for up to two minutes if transactions are pending but not being cleared. After two minutes of inactivity, the command times out and stops waiting, leaving the database in a paused state. You can change the timeout period by using the --timeout (or -t) flag and specifying a different timeout period in seconds.

If the pause --wait command times out, review any error messages to determine the cause of the delay. Once you correct the problem, you can either reissue the pause --wait command or check the @Statistics system procedure results to make sure all pending transactions and queues are clear.

Reduces the size of a cluster by removing one or more nodes. The number of nodes removed depends on the K-safety factor. See Section 9.3.2, “Removing Nodes with Elastic Scaling” for more information on resizing clusters. Without any action qualifiers, the voltadmin resize command tests to ensure a resize is possible, reports which nodes will be removed, and starts the resize process There are two options that affect how the resizing is performed:

There are four action qualifiers that alter what resize operation is performed. These qualifiers are mutually exclusive:

Resumes normal database operation after a pause.

Creates a snapshot containing the current database contents. Snapshot files are saved to each server in the cluster. If you use save without any arguments, the snapshot is saved into the database's snapshots directory where it can automatically be restored the next time the database starts. If you specify an alternate directory and ID, the snapshot files are saved to the specified path using the unique ID as a file prefix.

When saving into the default snapshots directory, VoltDB automatically performs a full snapshot in native mode. The following are additional arguments you can specify when saving to a specific location and unique ID. (Only the --blocking argument is allowed when saving to the default snapshots directory.)

Restores the data from a snapshot to the database. The data is read from a snapshot using the same unique ID and directory path that were used when the snapshot was created. If no tables exist in the database (that is, no schema has been defined) the restore command will also restore the original schema, including stored procedure classes, before restoring the data.

The following arguments let you selectively include or exclude data from certain tables during the restore operation.

Note that if the database is empty (that is, has no existing schema), the full schema from the snapshot is always loaded even if you choose not to load the data for certain tables. Also, you can specify either --skiptables or --tables but not both on the same command.

Updates or adds the configuration option with the specified value. You can include multiple configuration options separated by spaces. The properties are specified in dot notation. You can also set multiple properties using --file to specify a YAML file of configuration properties.

The set command is cumulative. Values for existing properties are replaced and new properties are added to the existing configuration. For example, specifying a value for deployment.systemsettings.query.timeout sets the value for query timeout but does not alter other system settings. Similarly, if you specify a new export configuration it is added to the existing configurations. See the voltadmin update command for instructions on replacing the existing configuration.

Not all configuration settings can be updated while the database is running. See Section E.2, “YAML Properties for Configuring Volt Databases on Bare Metal” for information on which options can and cannot be updated on the fly.

Displays information about the cluster's current license.

Displays information about up to ten previous snapshots. This command is useful for determining the success or failure of snapshots started with the save command.

Displays information on the state of the cluster, such as the number of nodes and uptime. You can use the following options to customize the content and presentation of the status information:

Updates the configuration on a running database with the values in the configuration file. The specified configuration replaces the current configuration. That is, values specified in the configuration file replace the current values. Configuration options not specified in the configuration file are reset to their default values, even if they were set explicitly in the previous configuration. Alternately, you can use the voltadmin set command to change or add individual properties.

There are limitations on what changes can be made to the configuration of a running database cluster. See Section E.2, “YAML Properties for Configuring Volt Databases on Bare Metal” for information on the allowable changes. The update either succeeds or fails as a whole. If any of the requested changes are for properties that cannot be set on a running database, no changes are made to the configuration.

Stops an individual node in the cluster. The voltadmin stop command can only be used on a K-safe cluster and will not intentionally shutdown the database. That is, the command will only stop a node if there are enough nodes left for the cluster to remain viable.

By default, the stop command waits for all partition and export leadership on the specified node to be redistributed to other nodes in the cluster in an orderly fashion before stopping the node. You can use the --force argument to stop the node immediately. However, if you force the node to stop, the remainder of the cluster must negotiate leadership after the node stops, which can have several negative effects. The advantages of using the default, orderly stop command are:

Shuts down the database process on all nodes of the cluster. By default, voltadmin shutdown performs an orderly shutdown, pausing the database, completing all pending transactions and writing any queued export, import, or DR data to disk before shutting down the database. You can also use one of the following arguments to modify the behavior of shutdown:

Since it is possible that lost connections to external systems or other abnormal conditions can cause queues to hang, the shutdown command (without the --force flag) waits for up to two minutes if transactions are pending but not being cleared. After two minutes of inactivity, the command times out, leaving the database in a paused state but not shutdown. You can change the timeout period by using the --timeout (or -t) flag and specifying a different timeout period in seconds.

If the shutdown command times out, review any error messages to determine the cause of the delay. You can:

Note that if you do a shutdown --force after a shutdown --save command, the system will not have created a final snapshot.