[SERVER-37798] Crash after dropping a unique index. Created: 29/Oct/18 Updated: 27/Nov/18 Resolved: 27/Nov/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Index Maintenance |
| Affects Version/s: | 4.0.2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Antònia Tugores | Assignee: | Danny Hatcher (Inactive) |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Operating System: | ALL |
| Steps To Reproduce: |
Fresh MongoDB 4.0.2 with wired tiger, ssl and authentication (user/pwd) Create collection with some indices, one of them unique. Insert data in this collection from pymongo 3.7.1 Drop the unique index from pymongo 3.7.1 MongoDB crashes (even when both data and index are owned by mongod:mongod and permissions are 700). Restart the server and "version is too new for this mongod" arises.
|
| Participants: |
| Description |
|
In a fresh MongoDB 4.0.2 installation with wiredtiger, ssl and user/pwd authentication a unique index is dropped and the server crashes (with a permission denied error but both data and indices folder's owner is mongodb:mongodb and permissions are 700).
When trying to restart the service, another error arises:
As this is a fresh install, it cannot be an upgrade/downgrade issue, how is it possible to have inconsistent index version in this case? Server is finally restarted by removing the corrupted index file.
|
| Comments |
| Comment by Danny Hatcher (Inactive) [ 27/Nov/18 ] |
|
Hello Antònia, Unfortunately, as neither of us can reproduce the issue, I am going to close this ticket as "Cannot Reproduce". If you do happen to encounter this error again please let us know on this ticket and we can resume the investigation. Thank you, Danny |
| Comment by Antònia Tugores [ 27/Nov/18 ] |
|
In the RS that crashed there was no downgrade, it was a fresh 4.0.2 install. And when I tried to reproduce it we did the same steps: three servers with a fresh Ubuntu 18.04 server installation (ntp, no THP, and ad-hoc ulimits), added your repo and installed 4.0.2 (we followed the instructions in your documentation page), added authorization (user/pwd), certificates, moved to preferSSL, and configured the RS (two computers with data + one arbiter). There was no downgrade, no other versions were installed in any case (as in the production environment). In fact we tried reproducing it with 2+arbiter and 2+0arbiters (in both cases we installed/configured it from scratch, OS included)
|
| Comment by Danny Hatcher (Inactive) [ 26/Nov/18 ] |
|
Hello Antònia, The redirect to the 4.2 documentation is because the old link was pointing to a version of 3.4 which is the last time that index compatibility between versions changed. It appears that this was a change introduced in 4.0.2 per Unfortunately, I have been unable to reproduce your problem. You mentioned that you have been unable to reproduce as well; were your reproduction attempts also on 4.0.2 or were they on a different version? Thank you, Danny |
| Comment by Antònia Tugores [ 20/Nov/18 ] |
|
Hello, Sorry for the delay. We tried but we were not able to reproduce it even though we used the original scripts to configure the db and imported the same data (but just a few gigabytes). The error message (version too new for this mongod) and the redirection to the 4.2 help page confuse me. Is there any mismatch between 4.0.* internal data? The redirection can be a simple error with the link completion (by using the last available version), but what about the version mismatch error? |
| Comment by Danny Hatcher (Inactive) [ 14/Nov/18 ] |
|
Hello Antònia, Have you been able to reproduce the issue? Thank you, Danny |
| Comment by Antònia Tugores [ 30/Oct/18 ] |
|
Hello Daniel, This morning we tried to reproduce it but we could not (we were using the same installation, but yesterday afternoon we upgraded the RS to 4.0.3). We'll try with an standalone 4.0.2 server asap.
Thanks, antònia |
| Comment by Danny Hatcher (Inactive) [ 29/Oct/18 ] |
|
Hello Antònia, I have been unable to reproduce the problem following the steps that you provided. Can you please confirm if you are able to reproduce the issue when following the above steps? Please also provide the following:
Thank you, Danny |