For performance reasons I'd like to movePrimary the databases over a number of shards after adding a few new shards. Otherwise all unsharded collections will all remain on the first shard.

After some local testing on a sharded setup it seems this command is absolutely fatal to run on a non-drained shard. What I'm seeing now is that movePrimary will happily run anyway. It moves over all data from the current primary to the 'to' primary in the movePrimary command and then drop the database. This will result in a pretty broken setup where the data for the 'old' primary has been moved over to the new one but the chunking configuration is the same, resulting in that data being effectively lost for mongos until you move it back again. Also, since the database has been dropped, indexes have been dropped along with it. All this time the old primary is still an active participant in the shard so new data gets saved correctly but will soon be too much to query on given the fact that there are no indexes left.

I'm not sure this is related but in the previous scenario after the move, the non-sharded collections are empty for all other mongos processes except for the one doing the movePrimary. After a reboot of these mongos processes the data is visible again.

The documentation at http://www.mongodb.org/display/DOCS/movePrimary+Command does have some pretty solid warnings but the example is slightly confusing, giving me the impression that can actually movePrimary on an active shard. I think movePrimary should:

1). be fixed so that it can run on active shards or
2). Throw an error when calling it on a shard that is not in the proper state for it (drained?).

In the latter case, how should one move over non-sharded collections on a running cluster?