[mathias_10gen]

That line was referring to restarting just the mongod process on a running machine (eg, when upgrading or changing config flags). In that case, the data should still be in the OS file cache and will result in minor rather than major pagefaults when mongod accesses data so it will not go to disk. The case where you do a full reboot is mentioned two sentences later: "Of course on a full server reboot MongoDB must reheat too."

[antirez]

Sorry I missed that sentence where you mentioned it was just if you restart the server.

And I agree it is an advantage that at least in this scenario no reboot is needed, for instance if you plan to upgrnde MongoDB version. Actually when you can plan the downtime it is usually simpler to handle in the general case of many cache hosts running at the same time when you can do the upgrade incrementally, but it is nice that a single big server can be upgraded without the problem of the cache reheating.

Apologizes again for not reading the article with more care.

[Locke1689]

Yeah but the relevance drops precipitously as soon as you talk about only restarting the DB server. Planned downtime is less of a problem than unplanned downtime.

For example, at Google my caching strategies could be exported in production with only a few minor changes to the code. If we experienced data center downtime I could actually offload a hot cache to the other backing stores in round-robin configuration. The problem isn't when one database server gets taken down, it's when all the servers in the datacenter get taken down at once without any warning.