Control Script

Use this command to set a cluster’s state:

The command arguments are as follows.

To get the state of a cluster (activated or not), use the following syntax:

To get a list of nodes registered in the baseline topology, run the following command:

The output contains the current topology version, the list of consistent IDs of the nodes included in the baseline topology, and the list of nodes that joined the cluster but were not added to the baseline topology.

To add a node (or multiple nodes) to the baseline topology, run the following command.

The command arguments are as follows.

To remove a node from the baseline topology, use the following command.

The command arguments are as follows.

You can set baseline topology by providing a list of nodes (consistent IDs).

The command syntax is as follows:

The command arguments are as follows.

To restore a specific version of the baseline topology, use the following command:

The command arguments are as follows.

Baseline topology autoadjustment is an automatic update of baseline topology after the topology has been stable for a specific amount of time.

For in-memory clusters, autoadjustment is enabled by default with the timeout set to 0. It means that baseline topology changes immediately after server nodes join or leave the cluster.

For clusters with persistence, the automatic baseline adjustment is disabled by default.

To enable autoadjust, use the following command:

The command arguments are as follows.

Baseline topology autoadjustment is an automatic update of baseline topology after the topology has been stable for a specific amount of time.

For clusters with persistence, the automatic baseline adjustment is disabled by default.

For in-memory clusters, autoadjustment is enabled by default with the timeout set to 0. It means that baseline topology changes immediately after server nodes join or leave the cluster.

To disable baseline autoadjustment, use the following command:

The following command returns a list of transactions that meet the filter conditions (or all transactions if no filter is defined):

The transaction filter parameters are as follows.

To cancel transactions, use the following command:

The transaction filter parameters are as follows.

The command affects the following transactions:

For example, to cancel the transactions that have been running for more than 100 seconds, execute the following command:

Use this command to detects situations where multiple transactions are in contention to create a lock for the same key. The command is useful if you have long-running or hanging transactions.

The command syntax is as follows:

The command arguments are as follows:

Example:

If contended keys are detected, the command dumps extensive information including the keys, transactions, and nodes where the contention took place.

Example:

This command is used for cache monitoring. It retrieves a list of deployed caches, their affinity/distribution parameters, and their distribution within cache groups. There is also a command option for viewing existing atomic sequences.

Use the following command syntax:

The command arguments are as follows.

This command resets lost partitions in the specified caches. Refer to Partition Loss Policy for details.

Use the following command syntax:

The command arguments are as follows.

Partition reconciliation is a process of consistency checking, with the goal to verify the internal data consistency invariants and fix the inconsistent entries. The main difference between idle_verify and partition_reconciliation is that the latter one can work under the load.

If the topology is changed while the script is running, or if the task execution fails, the command is automatically cancelled.

The command has the following optional arguments.

Use this command to safely stop the partition reconciliation process. All changes done before the cancellation are preserved.

Use this command to destroy caches.

The syntax is as follows:

The command uses one of the following two arguments:

This command compares the hash of the primary partition with that of the backup partitions and reports differences, if any. Said differences might result from node failure or incorrect shutdown during an update operation.

The command syntax is as follows:

The command has the following optional arguments.

A list of diverging partitions is printed out, as follows:

This command verifies that index inline size is the same on all cluster nodes. Every entry in the SQL index has a constant size, which is calculated during the index creation. Having different sizes on different nodes in a cluster may lead to performance issues.

The command syntax is as follows:

The command returns a response in the command line.

This command validates the indexes of the specified caches on the specified cluster nodes.

It verifies that:

The command syntax is as follows:

The command can use one or both of the following optional arguments:

If indexes refer to non-existing entries, or if some entries are not indexed, errors appear in the command output. Example:

Use this command to get the full list of the available cluster properties.

The command syntax is as follows:

Use this command to set property values.

The command syntax is as follows:

For example, you to enable SQL statistics in a cluster:

Use this command to get a property value.

The command syntax is as follows:

When a user uploads a large volume of data to the cluster, to be sure the data is delivered successfully, you can trigger a manual checkpoint on the cluster.

Use the following command to trigger a checkpoint on all server nodes simultaneously and wait until the checkpoint completes:

In a large distributed database, triggering multiple checkpoints at the same time can create a spike in traffic and, consequently, negatively affect the cluster performance. To prevent this, you can set the checkpoint.deviation property to offset checkpoints' time, so that they happen within specified interval of checkpoint.frequency. For example, if your checkpoints trigger every 100 seconds, and you set checkpoint.deviation at 10%, your triggers will happen every 95-105 seconds.

The example below offsets the checkpoints by 10% to reduce traffic issues:

Use this command to get diagnostic information for your cluster (page locks or connectivity):

The command arguments are as follows:

Example pageLock output:

Example connectivity output:

Use the this command to get the master key that is used in the cluster encryption:

Use the this command to set the master key that is used in the cluster encryption:

Use this command to change cache-level encryption keys:

Use this command to list IDs of the cache group encryption keys:

Use this command to monitor cluster reencryption:

Use this command to pause reencryption of your cluster:

When re-encryption is initiated on the cluster, you can monitor it with the reencryption_status subcommand.

Use this command to resume reencryption of your cluster that you had previously suspended (see encryption suspend_reencryption):

Encryption requires a large amount of system resources. One way to address this is to suspend reencryption to allow the system to handle the workload - see encryption suspend_reencryption. Alternatively, you can use this command to limit the reencryption rate.

Use this command to enable rolling upgrades:

The command arguments are as follows.

Use this command to disable rolling upgrades:

The command arguments are as follows.

Use this command to force a rolling upgrade on your cluster.

The command arguments are as follows.

Use this command to check the current status of the rolling upgrade on your cluster:

Use this command to change the cluster ID of in-memory clusters.

The command arguments are as follows.

Use this command to change the cluster tag of in-memory clusters.

The command arguments are as follows.

Use this command to get the current state of data center replication:

With the --verbose option, you can get extended status information.

The command arguments are as follows.

Use this command to print the cluster topology with the Data Center Replication details:

The command arguments are as follows.

Use this command to pause data center replication on all caches in a cluster.

The command arguments are as follows.

Use this command to resume data center replication on all caches in a cluster.

The command arguments are as follows.

Use this command to execute a full state transfer on all caches in a cluster if the caches in the master cluster already have data:

The command arguments are as follows.

Use this command to dump all data to persistent storage (for example, to make sure that all data is saved before deleting the source data):

Use this command to cancel an active full state transfer at any time:

The command arguments are as follows.

Use this command to get a list of all full state transfers currently in progress.

Use this command to get information about a node’s status during data center replication:

The command arguments are as follows.

Use this command to get specific cache details related to data center replication:

The command arguments are as follows.

Use the shutdown-policy command to set the node shutdown policy to:

The command syntax is as follows:

Use the warm-up command to disable cache warmup on the cluster:

Use this command to print information about the potentially corrupted caches on a local node:

Use this command to clean persistent caches.

The command arguments are as follows.

Use this command to back up caches:

The command arguments are as follows.

Use this command to schedule the disk defragmentation:

The command arguments are as follows.

Use this command to cancel a scheduled or active defragmentation if it interferes with other operations:

Use this command to check the status the current defragmentation process.

Use this command to list meta information:

Use this command to print information about the specified binary type:

The command syntax is as follows:

One of the following command arguments must be used.

Following is an example of the command output:

Use this command to remove metadata for the specified type form the cluster and save the removed metadata to a file.

The command syntax is as follows:

The command arguments are as follows.

Use this command to updates cluster metadata from a specified file.

The command syntax is as follows:

The command arguments are as follows.

Use this command to schedule an index rebuild:

The command arguments are as follows: