SERVER-11021, the dbhash command results for config servers are cached, until new data is written in those collections. The moveChunk/splitChunk commands use the applyOps command to propagate the changes to the config.chunks collection on the config servers. This causes the cached dbhash for the config.chunks collection to not be updated, and afterwards return the old cached dbhash from before the write.
This issue is only present in the 2.4.7 (stable release) version of MongoDB. This issue does not affect correctness – the config.chunks collection is written to properly. However, if only one config server is restarted, it can end up with a different dbhash for the config.chunks than the other config servers upon startup. This can prevent new mongos processes from starting until the dbhash for all config servers agree. If the balancer is on, mongos will periodically log a message warning that it has detected that the "config servers differ" and will prevent further migrations from occurring.
Operations applied to the config server collections with the applyOps command need to call logOpForDbHash to invalidate the dbhash cache.
It is safe to downgrade only the config servers to 2.4.6 to avoid this cache invalidation problem.
Production release v2.4.8 contains the fix for this issue.