Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Command has to be executed on the Master node and requires root permissions. Following may be used:

Panel
titleIn this article
Table of Contents

...

The tool requires root permissions. The list of arguments and other requirements depend on the command used. Please refer to below table for a summary and respective sections for details.

CommandDescriptionNodesRoot Required
status
Show status of the clusterAny nodeNo
init-master
Init Master Node configurationMasterYes
init-slave
Init Slave Node configurationMasterYes
promote
Promote current node to MasterRedundancyYes
sync-files
Sync files from MasterRedundancy, Reporting, ProcessingNo
remove-node
Remove Node from the ClusterMasterYes

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
titleBash
<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:

Example of Cluster Status outputImage Added

Alternatively command can be executed at any other node - in this case only 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:

Example of Cluster Status output with failed nodeImage Added

In this case you have to re-check failed node, fix it and then return to the cluster using "init-slave" command.

Init Master

The command is used for initial configuration of the Master NodeThe command is run on Master and used for Master to configure its parameters.

Code Block
titleBash
<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. Following options are supportedThis command may require additional options:

OptionDescriptionDefault
<IP-
-ip=<ip>
ADDRESS>
IP Address of the Master server (required)
none

--ssh-port=<port>
SSH Port
at
as the master
server
node
22
--pg-data=<path>

Path to PostgreSQL data

path on the master system

directory

autodetect
--vcs-path=<path>
Path to the JeraSoft Billing on Slave
<VCS_PATH>

...

Init Slave

The command is run on the Master and used for:is used to add node to the cluster. There are different contexts when it is required:

  • First-time deployment of the cluster
  • Addition on 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 failover.after fail over
Code Block
titleBash
<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. Following options are supported:

OptionDescriptionDefault
--ip=<ip>
IP Address of the Slave server
none
OptionDescriptionDefault
<IP-ADDRESS>
IP Address of the Slave server (required)

--role=<role>

Role of the new node:

  • redundancy - fully-featured redundancy, that acts as a hot standby and can be promoted to the Master at any time (may be used for redundancy and load balancing at the same time)
  • reporting - a node that receives most of the requests for the reports, holds full snapshot of the database, however it might be delayed from Master depending on the current load and requests (might be used for fail over, as a last resort)
  • processing - lightweight node for processing of real-time requests (authentication, authorization and routing), can not be used for fail over as it does not hold any statistical data
redundancy
--ssh-port=<port>
SSH Port at the
slave server
remote node
22
--ssh-
username
user=
<login>
<user>
SSH User at the remote node
Login to the slave server
jerasupport
--pg-data=<path>

Path to PostgreSQL data

path on the slave system

same as master

--vcs-path=<path>
Path to the JeraSoft Billing on Slave
<VCS_PATH>
--role=<role>
Role of the secondary system. Could be [redundancy or reporting]
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
titleBash
<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 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 old Master, you may add it as a new Slave using "init-slave" command.

Panel
borderColor#ffffb3
bgColor#ffffb3
borderWidth2px

(warning)   Attention

In case when you have more than 2 nodes in the cluster, you need to re-init all other slaves node 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
titleBash
<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 synchronisation.

Remove Node

The command may be run on any node and used to get status of the cluster. The command is used to remove node from the cluster.

Code Block
titleBash
<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. Following options are supported:

OptionDescriptionDefault
<IP-ADDRESS>
IP Address of the remote node (required)