As the copyDatabase command can be resource intensive, there should be a way to pass writeConcern. The copydb command that copyDatabase uses internally does support writeConcern, so the shell helper should be able to pass that along.

Original Summary

Can you specify a write concern value on the copyDatabase operation

Original Description

When we copy large databases, we notice that a secondary in our 3 node replicate set goes into the RECOVERING state and never recovers.

I figured it's because the database we are copying is 8gb in size and the oplog isn't big enough. The replica set is configured to have a write concern of 1. So as soon as one node acknowledges the write, the Primary moves on. However these copy operations are progressing at such a pace that one of the secondaries isn't able to keep up and the master no longer has any oplog entries to allow the secondary to catch up.

Why this secondary doesn't fall back to the initial sync state I don't know. It just seems to stay in the RECOVERING state for weeks on end with no change to the optime at all.

I didn't want to change the default writeConcern to 2. Because then if one node goes down, then all the writes would fail waiting for a 2nd secondary to acknowledge the replication.

I didn't want to change the default writeConcern to "majority" based on the same fears. If one node goes down, is the majority condition determined by the majority of secondaries that are configured? Or the majority of the secondaries that are alive?

I thought it would be good if the copyDatabase operation takes a writeConcern value like the other db insert and update operations. Does mongodb do something like that? I couldn't find anything in the documentation.

Thanks