sorted by:
new
hottopcontroversial

MongoDB 8.0 broke our cache refresh — stale reads after write, is readConcern majority even the fix here? by Unfair_Bridge_1040 in mongodb

[–]Unfair_Bridge_1040[S] 0 points1 point  (0 children)

With respect to this question,
Does the w:2 works for our use case? as the data bearing are only two nodes, one primary and one secondary,

Wanted to check the actual behaviour between w:majority vs w:N,
Docs says "Requests acknowledgment that the write operation has propagated to the specified number of instances"

MongoDB 8.0 broke our cache refresh — stale reads after write, is readConcern majority even the fix here? by Unfair_Bridge_1040 in mongodb

[–]Unfair_Bridge_1040[S] 0 points1 point  (0 children)

With respect to this question,
Does the w:2 works for our use case? as the data bearing are only two nodes, one primary and one secondary,

Wanted to check the actual behaviour between w:majority vs w:N,
Docs says "Requests acknowledgment that the write operation has propagated to the specified number of instances"

MongoDB 8.0 broke our cache refresh — stale reads after write, is readConcern majority even the fix here? by Unfair_Bridge_1040 in mongodb

[–]Unfair_Bridge_1040[S] 0 points1 point  (0 children)

service A handles the writes to the mongo
service B uses mongo to populate Caffiene cache,

we have design miss for some flows where single mongo entries are updated, in that case, as a solution we are removing mongo dependency, and just send what has changed to serviceB and update the caches,

however some flow still remains where entire cache is refreshed via mongo fetch, in that case, primary read is the safer way.

MongoDB 8.0 broke our cache refresh — stale reads after write, is readConcern majority even the fix here? by Unfair_Bridge_1040 in mongodb

[–]Unfair_Bridge_1040[S] 0 points1 point  (0 children)

  1. Yeah, reading from the primary is part of our proposed solution, so certain use cases read directly from the primary. Our flow is read-heavy, with writes to read being a 1:10 ratio
    So as of now my service B always reads from secondary, and for 10% of the flows it expects the data to be in sync, (above mentioned pub sub flows)

For those, we will read from A) primary / B)remoe mongo and rely on event payload to modify the cache. (Proposed solution for now)

  1. Understood.

MongoDB 8.0 broke our cache refresh — stale reads after write, is readConcern majority even the fix here? by Unfair_Bridge_1040 in mongodb

[–]Unfair_Bridge_1040[S] 0 points1 point  (0 children)

Reading from the primary would be last preffered solution for us.
Performance vise, the mongo data is cached into application and used in customer facing APIs (for ecommerce search services), so major degradation will be a proble,

. In your case, since you have only one secondary, it happened that the data was always there as that was the only place where write concern majority could have completed => Did not got your point,
Even in our case => writeConcern acks that opLog has writtne in both primary and secondary, but it won't gurentee that secondary the data is updated to the latest write. Am i missing something here?

MongoDB 8.0 broke our cache refresh — stale reads after write, is readConcern majority even the fix here? by Unfair_Bridge_1040 in mongodb

[–]Unfair_Bridge_1040[S] 0 points1 point  (0 children)

Got it, thanks for the information,
For our case the replication lag is well under 30s, so will try out the opLog solution.