2013-05-01 19:33:42 UTC
instance server on the same machine as our web app. We've reached a point
where its time to move to a replica set.
I've setup a replica set internally in a development environment on one
computer with 3 instances on a Windows Server 2008R2 machine.
1 primary, priority 2, on port 27017
1 secondary, priority 1, on port 27018
1 secondary, priority 0, hidden on port 27019
"_id" : "rs0",
"version" : 4,
"members" : [
"_id" : 0,
"host" : "192.168.0.10:27017",
"priority" : 2
"_id" : 1,
"host" : "192.168.0.10:27018"
"_id" : 2,
"host" : "192.168.0.10:27019",
"priority" : 0,
"hidden" : true
My application is built on node.js with Mongoose middleware for connection
I start up the application and run an initialization script to fill the
database with about 200 sample records in 25 collections in total. It takes
about 3 seconds to run.
This will work when the database on the replica set is freshly created. I
can run our initialization script 10 times in a row with no issues when the
replica set is freshly initialized.
The problem is a few hours later when I run this same initialization script
again I start getting assertions thrown and "bad file number values"
To fix it I have to shut down the primary, delete its entire database
directory, and then turn it back on and have it sync from the secondary.
Then I can run my initialization script again just fine.
Here is a log of what shows up in my mongod console on the primary when I
run the script when it fails:
Wed May 01 11:08:54.425 [conn15] CMD: drop mydb.courses
Wed May 01 11:08:55.183 [conn18] getFile(): n=-2
Wed May 01 11:08:55.185 [conn18] Assertion: 10295:getFile(): bad file
number value (corrupt db?): run repair
Wed May 01 11:08:55.806 [conn18] mongod.exe
Wed May 01 11:08:55.807 [conn18] mongod.exe
Wed May 01 11:08:55.809 [conn18] mongod.exe
Wed May 01 11:08:55.811 [conn18] mongod.exe
Wed May 01 11:08:55.813 [conn18] mongod.exe
Wed May 01 11:08:55.814 [conn18] mongod.exe
Wed May 01 11:08:55.816 [conn18] mongod.exe
Wed May 01 11:08:55.818 [conn18] mongod.exe
Wed May 01 11:08:55.819 [conn18] mongod.exe
Wed May 01 11:08:55.821 [conn18] mongod.exe
Wed May 01 11:08:55.822 [conn18] mongod.exe
Wed May 01 11:08:55.824 [conn18] mongod.exe
Wed May 01 11:08:55.825 [conn18] mongod.exe
Wed May 01 11:08:55.827 [conn18] mongod.exe
Wed May 01 11:08:55.829 [conn18] mongod.exe
Wed May 01 11:08:55.832 [conn18] mongod.exe
Wed May 01 11:08:55.833 [conn18] mongod.exe
Wed May 01 11:08:55.835 [conn18]
Wed May 01 11:08:55.837 [conn18] insert mydb.system.indexes keyUpdates:0
exception: getFile(): bad file number value (corrupt db?): run repair
code:10295 locks(micros) w:653752 653ms
sometimes I also get this assertion in tandem with the above:
[repl prefetch worker] Assertion: 10334:BSONObj size: 0 (0x00000000) is
invalid. Size must be between 0 and 16793600(16MB) First element: EOO
There is also another Assertion which is sometimes thrown:
[conn1025] mydb warning assertion failure n == 1 src\mongo\db\index.cpp 221
The replica set seems to be working fine when I create it initially and my
application is running on another machine and can connect and send data
back and forth ok. The issue is the primary becoming corrupt after just a
few hours and needing to be wiped and brought back up empty and resynced.
Has anyone else run into this problem with replica sets on Windows Server
I've tried running the mongod processes as a service, or just in a console
window and I have the same problem either way. The dev machine has 16GB of
ram which is more than plenty as mongod is using about 40-45MB each.
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to firstname.lastname@example.org
To unsubscribe from this group, send email to
See also the IRC channel -- freenode.net#mongodb
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+unsubscribe-/JYPxA39Uh5TLH3MbocFF+Gemail@example.com
For more options, visit https://groups.google.com/groups/opt_out.