Applies To:

GroupID 10


Imagine a customer using GroupID with a single server and that server fails. As long as that server is not brought back up or a new server is not configured by installing GroupID on another machine and connecting it to the same database, GroupID will remain down. In an ideal scenario, there should be more than one GroupID server, so that if one fails, GroupID services still remain functional from the other server having the exact same data as the failed one.

Business Scenario:

GroupID uses Elasticsearch for storing data and performing searches. In the case of multiple GroupID servers, one server acts as the Elasticsearch master node and others act as slave nodes, ensuring that all of them have the same/synchronized data.


The Elasticsearch master-slave relationship is created when you have more than one GroupID servers connected with the same SQL database. These servers are configured as follows:

  • On one server, the GroupID Configuration Tool is run with the Modify current GroupID 10 configurations option, thus making it the master node.

  • On all other servers, the GroupID Configuration tool is run with the Modify current GroupID 10 server with existing database configurations option, that further points to the master server’s Data Service URL. This configures these servers as Elasticsearch slave nodes.

    Note: You can disable the Imanami Replication service on all slave servers, only keeping it running on the master server. However, for this KB, we will assume that the Replication service is running on all servers so that if the master node fails, we don’t have to manually start it on the slave nodes.

Slave node failure:

  • With more than two GroupID servers
    If you have more than two GroupID servers and a slave goes down, you don’t need to change anything.
  • With only two GroupID servers
    If you have two GroupID servers (where one is the master and the other is the slave), and the slave goes down, do the following on the master server:
    1. Go to: X:\Program Files\Imanami\GroupID 10.0\ElasticSearch\elasticsearch-6.2.4\config 
      (where X is the GroupID installation drive.)
    2. Open the elasticsearch.yml file with notepad.
    3. Near the end of this file, there should be an entry:
      node.master: true
    4. Right below this entry, insert a new row and enter the following (if it is not already there): true
    5. Save your changes.
      After the change, your file should look as follows:

      Note: You can make this change in the file while deploying GroupID. In this way, you will not have to do it in case of a slave node failure.

Master node failure:

If you have two or more GroupID servers (where one is the master and the rest are slaves) and the master goes down, you don’t have to do anything. Another server will be selected as master and Elasticsearch data will be synchronized among the remaining servers. Even if the previous master server comes back up, it will not revert to its role and will act as a slave node.

Comments (0)