shardmand — Shardman configuration daemon
shardmand [common_options] [
--system-bus
] [
--user
]user_name
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
]
shardmand is a Shardman
configuration daemon. It runs on each node in a Shardman
cluster, subscribes for changes of shardman/cluster0/data/ladle and
shardman/cluster0/data/cluster keys in the etcd
store (cluster0 is the default cluster name used by
Shardman utils) and manages Shardman services
on the node where it is running according to the configuration described in these JSON
documents.
shardmand manages systemd services for shardman units. On startup and when one of the monitored etcd keys changes, shardmand reconfigures services as follows:
It calculates the expected node configuration, i. e., the list of
services expected to run and their configurations, from the
shardman/cluster0/data/ladle and shardman/cluster0/data/cluster
values.
It loads the list of running Shardman services from systemd and their existing environment and properties files.
It stops services that are not expected to run. This can be a service that belongs to a cluster with the same name, but a different UUID, or a service whose description is no longer present in the expected node configuration. For shardman-keeper services, shardmand purges their data directory.
If a service should be running, but its environment is different from the expected, shardmand overwrites the environment file and restarts the service. If a service should be running, but it is not running or not enabled, shardmand enables and starts it.
Also, a separate thread of shardmand periodically updates
the shardman/cluster0/data/shardmand/NODENAME etcd
key with the ClusterUUID of the last cluster to which the
configuration of services was applied. So, before the
shardmanctl
nodes
add command tries to initialize new stolon clusters
for a clover, the command can ensure that no alive stolon
services from a previous cluster configuration are left on all nodes in the clover.
All Shardman services are managed by
shardmand@cluster0.service, so when it is started, stopped or restarted, it
also starts, stops or restarts all other Shardman services
(including DBMS instances).
The meaning of the command-line options is as follows:
Avoid enabling individual Shardman services manually
(besides shardmand@cluster0.service). They are supposed to be
disabled and started by shardmand. If
shardmand@cluster0.service is disabled, but other services are enabled,
after reboot this can lead to inconsistent cluster state.
--system-bus
Sets shardmand to manage services with a system bus. By default, this is done with a user bus.
shardmand systemd
service can be installed either as a user unit or a system unit.
shardmand manages user or system systemd
units accordingly. A usual name of a shardmand
systemd service is shardmand@CLUSTER_NAME.service
.
shardmand connects to a D-Bus to manage
systemd units. When shardmand is
run as a system service, it manages system systemd
units and must connect to a system bus. When run as a user service, it
manages user systemd units and must connect to a
user bus. When shardmand is run as a system
service, set the --system-bus option.
--user user_name
Sets shardmand to change UID and GID to the UID and GID of the specified user after connecting to a D-Bus.
shardmand 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 shardmand 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 shardmanctl retries a failing etcd request. If an etcd request fails, most likely, due to a connectivity issue, shardmanctl retries it the specified number of times before reporting an error. The default is 5.
--session-timeout seconds
Specifies the session timeout for shardmanctl locks. If there is no connectivity between shardmanctl 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
A shardmand service reads the environment from
/etc/shardman/shardmand-cluster0.env. The following environment variables
affect the behavior of shardmand.
shardmand manages *.env and
*.props files for other Shardman services
located in the /etc/shardman directory. So all manual changes
to these files get overwritten.
SDM_CLUSTER_NAME
An alternative to setting the --cluster-name option
SDM_LOG_LEVEL
An alternative to setting the --log-level option
SDM_RETRIES
An alternative to setting the --retries option
SDM_SYSTEM_BUS
An alternative to setting the --system-bus 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
SDM_USER
An alternative to setting the --user option
shardmand settings are usually specified in the
/etc/shardman/shardmand-cluster0.env file. If you want
shardmand to connect to an etcd cluster at
hosts n1-n3 using port 2379 and all
Shardman services to use the debug log level, you
can use the following env file:
SDM_STORE_ENDPOINTS=http://n1:2379,http://n2:2379,http://n3:2379 SDM_LOG_LEVEL=debug
Note that you need to restart shardmand@cluster0 service to
apply new settings from the env file.
To look at shardmand logs, you can use a
journalctl command:
$journalctl -u shardmand@cluster0.service
You can restart all Shardman services on a node using
a systemctl command:
$systemctl restart shardmand@cluster0.service