Understand replicas

Learn about replicas in the MPF Operational Analytics.

Shards contain the actual data that is sent from the MobileFirst Server. The master node keeps track of which shards are on which nodes so that it can evenly distribute incoming requests. Because of the way shards are distributed among nodes, performance can be increased by adding another node and allowing the shards to be distributed.

But what happens if a node fails? The data that was stored in the lost shards is no longer available. Incoming analytics data might no longer be indexable. Search requests for data on a particular shard fail. To increase shard availability to avoid these problems, create a replica of each shard. By using JNDI properties, we can tell the MPF Operational Analytics to create a specified number of replicas for each shard.

The following images show how replicas work.

Here is a cluster with one node, three shards, and one replica for each shard.

In this case, the replicas are redundant. Because there is only one node, having a replica exist on the same node does not accomplish anything. If the single node fails, the shards and replicas are all lost.

Now two more nodes are added to the cluster to improve performance:

Notice that the shards and replicas are both automatically distributed evenly among the nodes. Now consider the scenario where a node fails due to a network or hardware issue.

The analytics cluster can still operate normally because a replica of the lost shards still exists on one of the remaining nodes.

When the failed node comes back online and rejoins the cluster, the shards and replicas are again evenly distributed. The cluster returns to the state it was in before one of the nodes failed.

But what happens when two of the nodes fail simultaneously?

The cluster cannot operate normally. Even with one replica per shard, if two nodes were to fail, we would still lose information that was stored in the lost shards.

The answer to this problem is to use two replicas per shard.

Now even when two nodes fail, all of the data is available and the cluster can still operate normally.

Having replica shards can also increase performance because an incoming request can be handled by either a primary or replica shard.

The ideal number of replicas for each shard varies based on several factors such as:

• Hardware limitations.

• Availability requirements.

• Clustering topology.

Parent topic: Clustering terminology