Currently, hot/background indexing is not very useful in replica sets. As soon as the index finishes on the primary and gets replicated to secondaries, all the secondaries start working on that at the same time, and stop processing subsequent operations until that index build finishes, which can take a long time. This means that, for clients that use safe WriteConcern values, the replica set becomes unavailable until the index builds finish on enough secondaries so that those secondaries can catch up and start satisfying WriteConcerns for new operations.
Presumably, MongoDB 2.6 fixed this by allowing background index operations to be resumed, and therefore allowing them to run concurrently with replication application. I'm not convinced yet that is the right way to do it in TokuMX but it's a starting point.
Currently, hot/background indexing is not very useful in replica sets. As soon as the index finishes on the primary and gets replicated to secondaries, all the secondaries start working on that at the same time, and stop processing subsequent operations until that index build finishes, which can take a long time. This means that, for clients that use safe WriteConcern values, the replica set becomes unavailable until the index builds finish on enough secondaries so that those secondaries can catch up and start satisfying WriteConcerns for new operations.
Presumably, MongoDB 2.6 fixed this by allowing background index operations to be resumed, and therefore allowing them to run concurrently with replication application. I'm not convinced yet that is the right way to do it in TokuMX but it's a starting point.