[SERVER-53015] Inserted data intermittently not seen in sharded cluster when database was just dropped Created: 21/Nov/20 Updated: 21/Dec/20 Resolved: 21/Dec/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 4.2.10 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Oleg Pudeyev (Inactive) | Assignee: | Jaume Moragues (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Operating System: | ALL | ||||||||
| Sprint: | Sharding 2020-12-14, Sharding 2020-12-28 | ||||||||
| Participants: | |||||||||
| Description |
|
I made the following test program which drops the database, inserts a document and performs countdocuments on the database in question. Eventually this program will see the document count stay at 0 for several seconds after a successful insert, after which the count increases to 1. To make this situation reproducible, I insert some more data prior to the drop to generate extra load, and I drop on only ~ 10% of the iterations.
Result:
This issue originally appeared in the transactions example tests for the Ruby driver, where instead of doing a count a find was issued, and that find returned no results after the document to be found was inserted. I tried setting read and write concerns to majority, which didn't fix the problem:
In the Ruby driver test suite this condition persists for much longer than this reproduce case shows (potentially indefinitely). To get out of it I can insert another document into the collection in question. Note in the following example how the count jumps from 0 to 2 even though I only inserted one document:
Note that even though in the above output the counts were sent to different mongoses, prior to insert both mongoses returned 0 and after the insert both returned 2. This issue seems to only affect 4.2 sharded clusters. |
| Comments |
| Comment by Oleg Pudeyev (Inactive) [ 16/Dec/20 ] | |
|
Reproduced also on 4.2.3 on ubuntu1804 using an official MongoDB server build with the count test. Find test either does not reproduce on this configuration or takes much longer. I thought the count test used estimated count but it uses countDocuments so it should be as accurate as the find test. I suggest running the count test. Server launched with:
Test was performed immediately after the launch, there was no other activity happening in this deployment. | |
| Comment by Oleg Pudeyev (Inactive) [ 14/Dec/20 ] | |
|
Original test with count: https://github.com/p-mongo/tests/blob/master/shard-phantom/test-count.rb Revised test using find instead of count: https://github.com/p-mongo/tests/blob/master/shard-phantom/test-find.rb Fails eventually as well but seemingly takes a bit longer. | |
| Comment by Githook User [ 27/Nov/20 ] | |
|
Author: {'name': 'Oleg Pudeyev', 'email': '39304720+p-mongo@users.noreply.github.com', 'username': 'p-mongo'}Message:
Co-authored-by: Oleg Pudeyev <oleg@bsdpower.com> | |
| Comment by Githook User [ 27/Nov/20 ] | |
|
Author: {'name': 'Oleg Pudeyev', 'email': '39304720+p-mongo@users.noreply.github.com', 'username': 'p-mongo'}Message:
Co-authored-by: Oleg Pudeyev <oleg@bsdpower.com> |