Hi Team,
We have a setup of 3.6.9 version, and observed two primaries on setup. Now as per this link
there can be a possibility of two P nodes being available.
As per docs, “When this occurs, clients that connect to the former primary may observe stale data despite having requested read preference primary, and new writes to the former primary will eventually roll back.”
but in our case, the writes did not happen to either of transient primary. Why is it so?
If the write was accepted by old primary then it should have been rolled back and the data is written out to the rollback directory in the mongo data directory.
https://docs.mongodb.com/v3.6/core/replica-set-rollbacks/#rollbacks-during-replica-set-failover
No, data was not accepted in either available transient primaries. There was loss of incoming trades and nothing was rolled back as per logs.
Can you expand on “two primaries on setup”
This should have resulted in an error then, was there any logging info from the application.
Due to heartbeat failure and network problem, our setup observed two primary nodes(transiently for about 2-3 seconds.) In the meantime application errors were logged for 20 seconds where it was not able to connect to primary node.
As per 3.6 documentation excerpt,
When this occurs, clients that connect to the former primary may observe stale data despite having requested read preference primary, and new writes to the former primary will eventually roll back.
We have the rollback files generated during same time of 30 seconds window when application couldn’t discover primary node to write to; can we say that the statement from documentation holds true. Means that if rollback files are generated [new writes to the former primary will eventually roll back](https://docs.mongodb.com/v3.6/core/replica-set-primary/index.html#id1) statement holds true? Is this understanding correct?
Hi Team, please help me with the query: