Timeline for Why did writes stop working when a secondary in my replica set went down?
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 19, 2022 at 18:10 | comment | added | Claudiu |
So the default write concern was {w: 1}. i would expect that this would mean any query which writes, would return as long as one writing member is available. What happened though is that when I made a query that inserted with only 2 of 3 writing nodes available, the query would block and not return. Eventually (once 3rd writing node was up) the query update went through. So it seems it was still waiting for 2 confirms even though the write concern was set to only wait for 1.
|
|
| Dec 19, 2022 at 8:09 | comment | added | Wernfried Domscheit | What do you mean by "not working"? See my update, | |
| Dec 18, 2022 at 20:44 | comment | added | Claudiu |
This makes sense, except I had already set the default write concern to w, and I did a test query from a mongosh session connected to the replica set. Wouldn't this use the default and therefore not have come across this issue?
|
|
| Dec 15, 2022 at 14:38 | history | edited | Wernfried Domscheit | CC BY-SA 4.0 |
added 58 characters in body
|
| Dec 15, 2022 at 14:23 | history | answered | Wernfried Domscheit | CC BY-SA 4.0 |