Replica Nodes with Different Indexes

[Stennie_X (Stennie)]

@Dilip_D

If we get an additional Read-Only node which will never be involved in the primary election, then we can create reporting specific indexes on the Read-Only node which will not have any impact during primary secondary switch.

Hi @Dilip_D,

If you want a more robust set up, I’d strongly recommend replacing the arbiter with a hidden secondary that can be used to address your reporting requirements and provide data redundancy in the event one of your data bearing replica set members is unavailable.

Arbiters add significant operational caveats per Replica set with 3 DB Nodes and 1 Arbiter - #8 by Stennie_X.

I would also evaluate whether distinct indexes on a hidden secondary are actually required for your current usage. The hidden secondary introduces a single point of failure for your analytics queries.

Starting with a standard Primary-Secondary-Secondary (PSS) replica set with your analytics queries using secondary read preferences would provide fault tolerance for your primary and for your data analytics queries. You can always evolve your deployment resources to suit your workload requirements.

@Dilip_D

In my replica set, its more like Primary will always remain as primary and so as the secondary.

If you definitely do not want any fault tolerance (i.e. your secondary can never be elected as a primary) and you also want unique indexes on a secondary for reporting, you could also deploy an atypical Primary-Hidden replica set. Setting up zero fault tolerance is not a recommended configuration as the typical goals of a replica set are to support data redundancy and high availability. However, in this scenario you would only have a single member eligible to be primary and have another member dedicated for reporting purposes.

Regards,
Stennie