With Topic Subject, U might see there are similar topic already exists but all those existing topics didn’t have the topic related information at all. Hence I’m creating new topic.
Question : In the Replica set of 3 nodes (1 primary, 1 secondary and 1 Arbiter), Is it good Idea to have different set of indexes for Primary and Secondary node. ?
In my replica set, its more like Primary will always remain as primary and so as the secondary. So I was thinking to create all write related indexes on primary node and same write related indexes + additional read related indexes on secondary node (as My reporting related queries always run on secondary).
Is this good approach ? Will this have any impact on the performance on entire replica set that will eventually introduce to latency on the primary node
HI Dilip, while you could do that, since you’ve only got a single secondary it would be promoted to primary state should something happen to the current primary.
As for having your reporting only querying the secondary node, I’m assuming you’ve set the read preference to Secondary which means that there will be issues should your primary fail and the current secondary gets promoted. At that time you have no secondary to serve those reads.
I would only recommend having different indexes on a cluster that has a hidden secondary member. Since it’s hidden then it can never become the primary and differing indexes are of less concern in that case. However, since you’re in a PSA set up you cannot do this. Is there a reason for going with PSA?
I understand, In PSA, Different Indexing between the primary and secondary would impact in case of Fail-over switch. We actually had a plan of having Primary, Secondary and Read-only node, but with budget constraint, we got into PSA architecture.
However, You answered my question. 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.
Thank you for your time on providing this clarity.
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.
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.
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.