[SERVER-53339] Tenant oplog appplier should handle "NotWritablePrimary" error while writing no-ops. Created: 14/Dec/20  Updated: 29/Oct/23  Resolved: 22/Dec/20

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 4.9.0

Type: Bug Priority: Major - P3
Reporter: Suganthi Mani Assignee: Lingzhi Deng
Resolution: Fixed Votes: 0
Labels: pm-1791_milestone-B
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-53312 Enable recipient testing for tenant_m... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2020-12-28
Participants:

 Description   

This step can throw "NotWritablePrimary" error. Tenant oplog applier should handle those errors, otherwise it can crash server due to uncaught exception.



 Comments   
Comment by Ian Whalen (Inactive) [ 04/Jan/21 ]

Author:

{'username': u'evrg-bot-webhook', 'name': u'Lingzhi Deng', 'email': u'lingzhi.deng@mongodb.com'}

Message:SERVER-53339: Tenant oplog appplier should handle errors from noop writes
Branch:master
https://github.com/mongodb/mongo/commit/037bcbb99c36023115d1d6a5ee1c027f1a0288ac

Comment by Lingzhi Deng [ 22/Dec/20 ]

https://github.com/mongodb/mongo/commit/037bcbb99c36023115d1d6a5ee1c027f1a0288ac

Comment by Matthew Russotto [ 18/Dec/20 ]

Yes, it is OK to fail the no-op; if we do we will re-apply the real entries but this is idempotent so it's OK.

Comment by Suganthi Mani [ 17/Dec/20 ]

Just a note, we write this no-op for change streams and also to handle recipient failover situation. So, I am not sure whether we are allowed to fail this no-op step after writing the real recipient oplog entries CC matthew.russotto

Comment by Lingzhi Deng [ 16/Dec/20 ]

In this ticket, we should also remove this invariant. We could hit this invariant if the _writerPool is shutting down, in which case we would get a ShutdownInProgress error.

Comment by Suganthi Mani [ 14/Dec/20 ]

CC lingzhi.deng

Generated at Thu Feb 08 05:30:37 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.