1. The new replica will not begin serving data until it's all there and
caught up. You can watch the replica status on the Cloud screen to see
it catch up; when it's green, you're done. If you're trying to automate
this, you're going to look for the replica that says "recovering" in
clusterstate.json and wait until it's "active."
2. I believe this to be the case, but I'll wait for someone else to
chime in who knows better. Also, I wonder if there's a difference
between DELETEREPLICA and unloading the core directly.
Michael
On 11/7/14 10:24, Ian Rose wrote:
Howdy -
What is the current best practice for migrating shards to another machine?
I have heard suggestions that it is "add replica on new machine, wait for
it to catch up, delete original replica on old machine". But I wanted to
check to make sure...
And if that is the best method, two follow-up questions:
1. Is there a best practice for knowing when the new replica has "caught
up" or do you just do a "*:*" query on both, compare counts, and call it a
day when they are the same (or nearly so, since the slave replica might lag
a little bit)?
2. When deleting the original (old) replica, since that one could be the
leader, is the replica deletion done in a safe manner such that no
documents will be lost (e.g. ones that were recently received by the leader
and not yet synced over to the slave replica before the leader is deleted)?
Thanks as always,
Ian
