shardmanctl

shardmanctl — Shardman auxiliary command-line client

Synopsis

shardmanctl [common_options] forall --sql query [ --twophase ]

shardmanctl [common_options] getconnstr [--direct-masters]

shardmanctl [common_options] rebalance

shardmanctl [common_options] rebalance_cleanup

shardmanctl [common_options] update [[ -f | --file stolon_spec_file] | spec_text [ -p | --patch ]]

Here common_options are:

[--cluster-name cluster_name] [--log-level error | warn | info | debug ] [--retries retries_number] [--session-timeout seconds] [--store-endpoints store_endpoints] [--store-ca-file store_ca_file] [--store-cert-file store_cert_file] [--store-key client_private_key] [--store-timeout duration] [--version] [ -h | --help ]

Description

shardmanctl is an auxiliary utility for managing a Shardman cluster. It allows you to perform operations explained below.

Note

All the described shardmanctl commands take a global metadata lock.

Executing an SQL Statement on All Replication Groups

To execute an SQL statement on all replication groups in the Shardman cluster, run the following command:

shardmanctl [common_options] forall --sql query [--twophase]

Pass the statement to be executed through the --sql option. For shardmanctl to use the two-phase-commit protocol to execute the statement, specify the --twophase option.

Getting the libpq Connection String

To get the libpq connection string for connecting to the cluster as administrator, run the following command:

shardmanctl [common_options] getconnstr [--direct-masters]

If the ClusterSpec.UseProxy configuration parameter is true, by default the connection string referring to proxies is returned. For the returned string to refer to master servers directly, specify the --direct-masters option.

Rebalancing Sharded Tables

If you did not perform rebalance when adding nodes to the cluster or if some other need arises, you can evenly rebalance sharded tables in the cluster. To do this, run the following command:

shardmanctl [common_options] rebalance

Performing Cleanup After Rebalancing

To perform cleanup after a rebalance command failure, run the following command:

shardmanctl [common_options] rebalance_cleanup

On each node, it cleans up subscriptions and publications left from the rebalance command and drops tables that store data of partially-transferred partitions of sharded tables.

Updating the Stolon Configuration

To update the Stolon configuration, run the following command:

shardmanctl [common_options] update [[-f|--file stolon_spec_file]|spec_text [-p|--patch]]

Provide the string with the Stolon configuration as follows:

  • On the command line — do not specify the -f option and pass the string in spec_text.

  • On the standard input — specify the -f option and pass - in stolon_spec_file.

  • In a file — specify the -f option and pass the filename in stolon_spec_file.

By default, the new configuration replaces the existing one. To merge the new configuration into the existing one, specify the -p (--patch) option. The new configuration is applied to all replication groups and is saved in clusterdata, so that new replication groups are initialized with this configuration. Note that update can cause a DBMS restart.

Common Options

shardmanctl common options are optional parameters that are not specific to the utility. They specify etcd connection settings, cluster name and a few more settings. By default shardmanctl tries to connect to the etcd store 127.0.0.1:2379 and use the cluster0 cluster name. The default log level is info.

-h, --help

Show brief usage information

--cluster-name cluster_name

Specifies the name for a cluster to operate on. The default is cluster0.

--log-level level

Specifies the log verbosity. Possible values of level are (from minimum to maximum): error, warn, info and debug. The default is info.

--retries number

Specifies how many times shardman-ladle retries a failing etcd request. If an etcd request fails, most likely, due to a connectivity issue, shardman-ladle retries it the specified number of times before reporting an error. The default is 5.

--session-timeout seconds

Specifies the session timeout for shardman-ladle locks. If there is no connectivity between shardman-ladle and the etcd store for the specified number of seconds, the lock is released. The default is 30.

--store-endpoints string

Specifies the etcd address in the format: http[s]://address[:port](,http[s]://address[:port])*. The default is http://127.0.0.1:2379.

--store-ca-file string

Verify the certificate of the HTTPS-enabled etcd store server using this CA bundle

--store-cert-file string

Specifies the certificate file for client identification by the etcd store

--store-key string

Specifies the private key file for client identification by the etcd store

--store-timeout duration

Specifies the timeout for a etcd request. The default is 5 seconds.

--version

Show shardman-utils version information

Environment

SDM_CLUSTER_NAME

An alternative to setting the --cluster-name option

SDM_FILE

An alternative to setting the --file option for update

SDM_LOG_LEVEL

An alternative to setting the --log-level option

SDM_RETRIES

An alternative to setting the --retries option

SDM_STORE_ENDPOINTS

An alternative to setting the --store-endpoints option

SDM_STORE_CA_FILE

An alternative to setting the --store-ca-file option

SDM_STORE_CERT_FILE

An alternative to setting the --store-cert-file option

SDM_STORE_KEY

An alternative to setting the --store-key option

SDM_STORE_TIMEOUT

An alternative to setting the --store-timeout option

SDM_SESSION_TIMEOUT

An alternative to setting the --session-timeout option

Examples

Getting the Cluster Connection String

To get the connection string for a Shardman cluster that has the cluster0 name, uses an etcd cluster consisting of n1,n2 and n3 nodes listening on port 2379, run:

 $ shardmanctl --store-endpoints http://n1:2379,http://n2:2379,http://n3:2379 getconnstr
 
 dbname=postgres host=n1,n4,n2,n1,n1,n2,n4,n3 password=yourpasswordhere port=5432,5433,5432,5433,5432,5433,5432,5433 user=postgres
 
 

Executing a Query on All Replication Groups

To execute the select version() query on all replication groups, run:

 $ shardmanctl --store-endpoints http://n1:2379,http://n2:2379,http://n3:2379 forall --sql 'select version()'
 
 Node 1 says:
 [PostgreSQL 13.1 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, 64-bit]
 Node 4 says:
 [PostgreSQL 13.1 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, 64-bit]
 Node 3 says:
 [PostgreSQL 13.1 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, 64-bit]
 Node 2 says:
 [PostgreSQL 13.1 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, 64-bit]
 
 

Performing Rebalance

To rebalance sharded tables in the cluster0 cluster, run:

 $ shardmanctl --store-endpoints http://n1:2379,http://n2:2379,http://n3:2379 rebalance
 

Updating PostgreSQL Configuration Settings

To set the max_connections parameter to 200 in the cluster, create the spec file (for instance, ~/stolon.json) with the following contents:

 {
   "pgParameters": {
     "max_connections": "200"
   }
 }
 

Then run:

 $ shardmanctl --store-endpoints http://n1:2379,http://n2:2379,http://n3:2379 update -p -f ~/stolon.json
 

Since changing max_connections requires a restart, DBMS instances are restarted by this command.

See Also

shardman-ladle, sdmspec.json