Docs for all releases
Page History
...
Command | Description |
---|---|
start | Start System Service Takes "--wait" option in order to wait and exit only when service finishes its execution. |
stop | Stop System Service |
restart | Stop and then start System Service |
reload | Send reload (HUP) signal to the System Service (forces reload of settings, connections, etc) |
status | Show current status of the System Service |
all-start | Start all required System Services (list of services varies depending on the role of the current node in the cluster) |
all-stop | Stop all running System Services |
all-status | Show status of all System Services on the current node |
Usage Examples
Code Block | ||||
---|---|---|---|---|
| ||||
<APP_PATH>/bin/system/service restart bbradiusd |
...
The tool is used to manage nodes in the cluster deployment. It allows to initialize the cluster, add a new node, promote redundancy to master, etc.
...
The tool requires root permissions. The list of arguments and other requirements depend on the command used. Please refer to the below table for a summary and respective sections for details.
Command | Description | Nodes | Root Required |
---|---|---|---|
status | Show status of the cluster | Any node | No |
init-master | Init Master Node configuration | Master | Yes |
init-slave | Init Slave Node configuration | Master | Yes |
promote | Promote current node to Master | Redundancy | Yes |
sync-files | Sync files from Master | Redundancy, Reporting, Processing | No |
remove-node | Remove Node from the Cluster | Master | Yes |
Init Master
Cluster Status
The command shows Cluster Status, including all nodes with their roles, IP addresses, current lag to Master, and overall status.
Code Block | ||
---|---|---|
| ||
<APP_PATH>/bin/system/cluster status |
The command can be executed on the Master in order to get the most detailed information about the cluster:
Alternatively, the command can be executed at any other node - in this case, only the status of the connection between this particular node and the Master will be shown.
If any node failed and has been disconnected from the cluster it will be shown like this:
In this case, you have to re-check failed node, fix it and then return to the cluster using the "init-slave" command.
Init Master
The command is used for the initial configuration of the Master NodeThe command is run on Master and used for Master to configure its parameters.
Code Block | ||
---|---|---|
| ||
<VCS<APP_PATH>/bin/system/cluster init-master --ip=<IP-of-master>ADDRESS> [<extra-options>]<options>] |
Command has to be executed on the Master node and requires root permissions. The following options are supportedThis command may require additional options:
Option | Description | Default |
---|---|---|
<IP- |
ADDRESS> | IP Address of the Master server (required) |
none
| |
--ssh-port=<port> | SSH Port |
as the master |
node | 22 |
--pg-data=<path> | Path to PostgreSQL data |
directory | autodetect |
--vcs-path=<path>
<VCS_PATH>
...
Init Slave
The command is run on the Master and used for:is used to add a node to the cluster. There are different contexts when it is required:
- First-time deployment of the cluster
- Addition of a new slave node to the cluster
- Addition of the
- first-time initialization of the cluster;
- addition of the new slave node to the cluster;
- addition of the old master to work as a slave after after failover.
Code Block | ||
---|---|---|
| ||
<VCS<APP_PATH>/bin/system/cluster init-slave --ip=<IP-of-slave>ADDRESS> [<extra-options>] |
This command encapsulates 4 sub-commands:
- configuration of the Master to ship replication logs (
init-master
) - configuration of the Master to accept connections from the Slave (
init-master-access
) - configuration of the Slave to receive replication logs (
init-slave
) - show status of the cluster (
status
).
Each of these commands may be performed separately if you know exactly what you need.
This command may require additional options:
<options>] |
Command has to be executed on the Master node and requires root permissions. The following options are supported:
Option | Description | Default |
---|---|---|
<IP-ADDRESS> | IP Address of the Slave server (required) |
|
--role=<role> | Role of the new node:
| redundancy |
--ip=<ip>
--ssh-port=<port> | SSH Port at the |
remote node | 22 |
-- |
ssh-user= |
<user> | SSH User at the remote node |
jerasupport | |
--pg-data=<path> | Path to PostgreSQL data |
same as master
--vcs-path=<path>
<VCS_PATH>
--role=<role>
redundancy
...
directory at the remove node | autodetect |
Promote to Master
The command is run on the Slave and used to promote the current Slave Redundancy node to Master.
Code Block | ||
---|---|---|
| ||
<VCS<APP_PATH>/bin/system/cluster promote |
Command has to be executed on the Redundancy node and requires root permissions. Reporting node can be used as a last resort if there are no Redundancy node alive. There are no options required.
After the promotion is performed, all required System Services will be started on the current node (new master)The command is used for failover. After you fix the old Master, you may add it as a new Slave using the "init-slave" command.
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Attention In case when you have more than 2 nodes in the cluster, you need to re-init all other slaves nodes from this new Master. |
...
Sync Files
The command is run on the Slave and used to synchronize files sync data and application files from the Master. The command is mostly used in crontab for auto-sync.
Code Block | ||
---|---|---|
| ||
<VCS<APP_PATH>/bin/system/cluster sync-files |
During initialization of the cluster, tool adds this command to the crontab (/etc/cron.d/vcs-cluster) at the Slave node.
Cluster Status
Command has to be executed on the Redundancy node and by default, it is added to the crontab for automatic synchronization.
Remove Node
The command may be run on any node and used to get status of the cluster. The command is used to remove a node from the cluster.
Code Block | ||
---|---|---|
| ||
<VCS<APP_PATH>/bin/system/cluster status |
When the command is run on the Master, it shows the type of the node and attached Slaves that are up to date:
Code Block |
---|
[ NOTICE ] Cluster Status
ifconfig | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d: -f2 | awk '{ print $1}'
Master (master ip): ACTIVE
Redundancy (slave ip): ACTIVE |
When the command is run on the Slave, it shows the type of the node and synchronization delay.
Code Block |
---|
[ NOTICE ] Cluster Status
ifconfig | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d: -f2 | awk '{ print $1}'
Master (master ip): NOT AVAILABLE | Activity delay: -00:00:58.393423
Redundancy (slave ip): ACTIVE |
Please don't worry if you see the following:
Code Block |
---|
the row: Master (master ip): NOT AVAILABLE |
It's normal behavior. Instead, please pay attention to Activity delay parameter − it shows large values if replication is broken and servers are not in sync.
...
remove-node <IP-ADDRESS> |
Command has to be executed on the Master node. The node in question shouldn't have any active database replication. The following options are supported:
Option | Description | Default |
---|---|---|
<IP-ADDRESS> | IP Address of the remote node (required) |
|