Shardman cluster configuration is stored in etcd. Shardman cluster services are organized as systemd services. The Shardman configuration daemon shardmand monitors the cluster configuration and manages PostgreSQL instances through integrated stolon. Each node has one shardmand service, whose typical name is shardmand@CLUSTER_NAME.service. Here CLUSTER_NAME is a Shardman cluster name, cluster0 by default.

Each shardmand includes several integrated stolon keeper and stolon sentinel threads.

Each registered DBMS instance has an associated stolon keeper thread that directly manages this PostgreSQL instance. The keeper starts, stops, initializes and resyncs PostgreSQL instances according to the desired stolon cluster state.

Each registered DBMS instance has an associated stolon sentinel thread. For each replication group, stolon sentinels elect the leader among existing sentinels. This leader makes decisions about the desired cluster state (for example, which keeper should become a new master when the existing one fails). When the new master in a replication group is selected, the leader selects the keeper with the minimal lag. When all replicas are synchronous, the keeper with the maximal priority is selected to become a new master even when the master in the replication group is alive. Shardman only uses synchronous replicas (otherwise, there is a chance to lose data when a node fails).

shardmand is a systemd unit, its logs are written to journald. You can use journalctl to examine it. For example, to get all logs since 2023-05-09 10:00 for the shardmand service of cluster cluster0, you can use the following command:

                $ journalctl -u shardmand@cluster0 --since '2023-05-09 10:00'
            

To control the log verbosity for all Shardman services, set SDM_LOG_LEVEL in the shardmand configuration file.