gistfile1.txt

bootstrap procedure

* new node joins the network
* new partition ownership gets computed
* each node compiles two lists of partitions: those that it is losing and those that it is gaining, regardless of where it appears in the preference list
* each node is then responsible for initiating any receiving processes for partitions it is gaining and sending processes for only the master (first in the pref list) partitions it is losing
* if a receiving process comes up for a partition that appears to contain data on disk, that partition folder will be moved to a backup name and an alert registered in the alert API
* sending processes should be able to broadcast packets to more than one receiver in the case where several replicas must be bootstrapped
* the bootstrap processes are all registered in local bootstrap managers
* each node is responsible for tracking the status of any local bootstrap processes
* if an error happens in the bootstrap, the error must be noted and based on what kind of error the bootstrap may be restarted with the last file or key moved.
* after the bootstrap is complete both sides must verify the integrity of the moved data.  each file should be hashed for integrity purposes
* if verification is successful the new partition can come up and register itself in the local membership server
* the new partition should do a one off sync with any other replicas that were running at the time that it was moved
* any old partitions still running on nodes not responsible for them will then begin to shutdown
* after being shutdown the data from the old replicas will be deleted