Due to a surprisingly long conversion delay, the slides from my talk at MongoSF 2011 are now available:
I’m sure video will be available at some point too, which will make the slides quite a bit more useful. But if you saw the talk and wanted the slides, you’re all set now. 🙂
37.288372
-121.884958
About Jeremy Zawodny
I'm a software engineer and pilot. I work at craigslist by day, hacking on various bits of back-end software and data systems. As a pilot, I fly Glastar N97BM, Just AirCraft SuperSTOL N119AM, Bonanza N200TE, and high performance gliders in the northern California and Nevada area.
I'm also the original author of "High Performance MySQL" published by O'Reilly Media. I still speak at conferences and user groups on occasion.
Jeremy Zawodny's blog 
sorry i missed the talk. what does “replica set node resync without index rebuild” mean?
That means a failed slave could resync data from another host without having to then rebuild indexes locally.
Maybe that was added in 1.8 and I missed it, but in 1.6 a secondary appears to rebuild indexes after copying the primary’s data.
Yes that’s right. I understand now – you are saying it’s faster to copy the index than rebuild it. On a fast LAN that would make sense.
A workaround that is very similar to that is to simply copy the entire good server’s datafiles to the new or out of sync member, and then restart it with –fastsync. That should effectively do the same thing, although perhaps suboptimal in terms of how much work the administrator has to do. Also at issue is that you need a snapshot of the datafiles from the other node, so you would need something like LVM or EBS or to take the source member’s mongod down temporarily.
this gave me an idea, slightly different but should be useful:
https://jira.mongodb.org/browse/SERVER-3160
The solution proposed in that JIRA seem like a step in the right direction. I like it. 🙂