From TOOLS-2041:

I think the use case of doing an --oplogReplay into a pre-existing collection is fairly dubious. The point of --oplogReplay is to provide a point-in-time restore. If there's pre-existing data, you cannot guarantee the state after the restore is consistent. You would have a mix of documents from different times. This is a problem even if there aren't any duplicate key errors.

If we were to ignore duplicate key errors during oplog application and skip those ops, it would get even worse - it would be possible to have documents which aren't even internally consistent. Different fields will be from different times.

So I think it's correct that duplicate key errors during --oplogReplay do cause mongomirror to fail. If you want to restore into a pre-existing collection, it's best not to use --oplogReplay. In fact, I think in a future major version update we should consider disallowing the use of --oplogReplay without --drop.