Managing cluster

To manage Ezeelogin cluster, click on “Cluster” link in “Settings tab”.

Initially, the “Node state” will be “master” and “Other node” will be “Not configured”. To setup Ezeelogin cluster, first install Ezeelogin on the secondary node with “secondary” parameter and the IP address of the primary node as specified here. If you try to access the secondary Ezeelogin web panel, you'll get a message asking you to setup cluster from primary node.

On the MASTER node run:

php /usr/local/ezeelogin/grant_host.php <secondary node IP address>

On your SECONDARY node while installing Ezeelogin, the IP of the PRIMARY node followed by the word SECONDARY will need to be executed to allow connections from the primary node:

./ezeelogin_vt3.0.0_b1.run -- <primary node IP address> secondary

Now in the cluster settings on primary node, add the IP address of the secondary node and click the “Add” button. Ezeelogin will check the version, build, status etcetera of the secondary node, copy the necessary data to the secondary node, create necessary users on the secondary node and sets up the cluster. This may take some time depending on network speed between the two nodes and the amount of data. If any error occurred during cluster setup, it will display the error message. Otherwise, a success message is displayed and the new cluster state will be “master” for “Node state” and “slave” for “Other node”.

User add/edit operations which needs to modify the system user on both nodes may fail if the SSH identification of a node has changed (due to OS reload, etc.). Click the corresponding “Reset” button for “Reset fingerprint on this/other node” to authorize this change for the particular node.

The status will be “connected” by default. If the slave node goes down due to some reason, master will always check the status of slave and it may take a bit longer to load the pages in web panel and also for Ezeelogin shell to start up. You can set disconnected mode to avoid the delay until slave node is online. Click on the “Disconnect” button. The status will change to “disconnected and the button becomes “Connect”. Click on the “Connect” button later when the slave node is online.

You can click the “Verify” button to verify the database synchronization. It will display the state of all the necessary tables.

You may also login to the web panel on slave node. But no additions/modifications are allowed from the slave node. The Ezeelogin shell will work identically on slave node so you can use both nodes simultaneously.

If the master node goes down for some reason, you can make the slave node master. To take over the “master” role, login to slave node web panel and take “Settings” → “Cluster”. Click on the “Make master” button.

The slave node will become master and you can continue normal operations. When the other node eventually comes online, it will automatically synchronize database with the current master node and becomes new slave. You may optionally make the other node master again if you wish. You may also verify the database any time by clicking the “Verify” button on either node.

If a split-brain happens somehow, Ezeelogin web panel will display a message. A split-brain is a condition in which both nodes have different data. For example, slave node went down and you added a few servers during that time. Before slave node came back online, master node went down. You make the slave node “master” and added a few servers. Now when old master node comes online, it will be in a split-brain condition. In this situation, you will have to resolve the split-brain manually. Auto-synchronization will not work. To resolve such condition, click on the “Verify” button on any node. It will display the changes in both databases for each table.

You can drop any one change and keep the other to bring it back to sync. You will be warned about data loss. Make sure you keep the correct data. It is recommended that you take a backup on both nodes before resolving conflicts.

NOTE: Logs are not replicated. Hence logs will be available only on the respective node where action was performed.