I don't know the exact behavior of master to slave replication, I am assuming something similar to LinkedIn's Espresso.
typically "need to bootstrap" check is done as part of the offline-slave transition. There needs to be some way for the slave to check that it is almost close to the current master so that it does not need a bootstrap. Just checking for the prior existence of a partition is not good enough because the node might have gone down for days and when it comes back up, its probably better to re-bootstrap instead of catching up from the changelogs. On Mon, Jan 22, 2018 at 11:12 PM, Bo Liu <[email protected]> wrote: > Hi There, > > I am using FULL_AUTO with MasterSlave and DelayedAutoRebalancer. How can a > participant differentiate between these two cases: > > 1) when a participant first joins a cluster, it will be requested to > transit from OFFLINE to SLAVE. Since the participant doesn't have any data > for this partition, it needs to bootstrap and download data from another > participant or a data source. > 2) when a participant loses its ZK session, the controller will > automatically change the participant to be OFFLINE in ZK. If the > participant manages to establish a new session to ZK before the delayed > time threshold, the controller will send a request to it to switch from > OFFLINE to SLAVE. In this case, the participant already has the data for > the partition, so it doesn't need to bootstrap from other data sources. > > -- > Best regards, > Bo > >
