[SERVER-837] Assertion failure ! _progressMeter.isActive() db/curop.h 247, replication restarts over and over Created: 26/Mar/10 Updated: 12/Jul/16 Resolved: 28/Mar/10 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 1.4.0 |
| Fix Version/s: | 1.4.1, 1.5.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jeremy Andrews | Assignee: | Eliot Horowitz (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
64-bit CentOS Linux. Xeon X5272 @ 3.40GHz. |
||
| Participants: |
| Description |
|
I'm starting a MongoDB slave with the following options: It start syncing files, but ultimately fails and then autorsyncs thanks to the --autoresync option. [root@mongo1 ~]# grep "An earlier initial" /var/log/mongodb/mongodb.log Here's the errors in the log prior to one instance if the above error line (the same error occurs each time it gets this far in the replication process): for mydb_loadtest.fields_current I was originally running 1.3.4 on the master and 1.3.3 on the slave. I upgraded both to 1.4.0 today, removed the local data directory, and tried again but ran into the same identical problem. |
| Comments |
| Comment by Eliot Horowitz (Inactive) [ 26/Apr/10 ] |
|
in a release |
| Comment by Narayan Newton [ 29/Mar/10 ] |
|
I just tested the latest nightly for the 1.4 branch and this does appear to be fixed. Thanks! However, there is some odd output you may want to know about, it seems completely harmless from what I've seen. On the slave after a full DB clone of a fairly large db I get this: While on the master I see this: This is fully reproducible, but seems like it might be by design? It doesn't block my usage in any way, but wanted to let you know. Thanks again for fixing this. -N |
| Comment by Eliot Horowitz (Inactive) [ 28/Mar/10 ] |
|
ok - should be really fixed now |
| Comment by Narayan Newton [ 27/Mar/10 ] |
|
Absolutely, here is the startup banner from the nightly version: and here is the startup banner from the direct from git version: |
| Comment by Eliot Horowitz (Inactive) [ 27/Mar/10 ] |
|
can you send the startup banner so can see the git version? |
| Comment by Narayan Newton [ 27/Mar/10 ] |
|
Adding to this, I just grabbed git master and ran this test again, following assertions happened: Sat Mar 27 12:02:21 building new index on { _bundle: 1, status: 1 } for examiner_loadtest.fields_current background Thanks. -N |
| Comment by Narayan Newton [ 27/Mar/10 ] |
|
I just grabbed the nightly 1.4 build from March-27th at 7:41AM, linux/mongodb-linux-x86_64-v1.4-latest.tgz. We updated the slave to this version, cleared the data dir and did a resync. However, a slightly different assertion is now happening: Sat Mar 27 11:14:06 building new index on { _bundle: 1, status: 1 } for examiner_loadtest.fields_current background Did I grab the wrong nightly version or is this bug still outstanding? Thanks! -N |
| Comment by auto [ 26/Mar/10 ] |
|
Author: {'login': 'erh', 'name': 'Eliot Horowitz', 'email': 'eliot@10gen.com'}Message: reset curop in repl thread |
| Comment by auto [ 26/Mar/10 ] |
|
Author: {'login': 'erh', 'name': 'Eliot Horowitz', 'email': 'eliot@10gen.com'}Message: reset curop in repl thread |