[
https://issues.apache.org/jira/browse/CASSANDRA-8494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14324434#comment-14324434
]
Yuki Morishita commented on CASSANDRA-8494:
-------------------------------------------
Now I'm having challenging part.
Bootstrapping token as it is ready can change replica placement or replica
range in the middle of bootstrapping process. We may succeed bootstrapping for
few vnodes but if we have many, it is likely to fail streaming. Or even if we
suceed, we may have over-streamed (out of range) data.
So, it may be easier to go Jake's route: proxy reads while bootstrapping. It is
simpler for bootstrapping node to decide what to do for read request based on
its bootstrapping progress, rather than coordinating (through gossip) which
tokens are up/down amoung nodes in the cluster.
To do that, I guess we need to have:
* Bootstrapping node - Anounce bootstrapping tokens as usual. Receive data
while keeping track of the completed range (This can also be used for resume).
When read request comes and it is in the completed range, just serve the data.
Otherwise forward the request to current replica to answer instead.
* Existing node - When receiving read request and it's in the pending range,
just do extra work for preparing to receive proxied response.
> incremental bootstrap
> ---------------------
>
> Key: CASSANDRA-8494
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8494
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jon Haddad
> Assignee: Yuki Morishita
> Priority: Minor
> Labels: density
> Fix For: 3.0
>
>
> Current bootstrapping involves (to my knowledge) picking tokens and streaming
> data before the node is available for requests. This can be problematic with
> "fat nodes", since it may require 20TB of data to be streamed over before the
> machine can be useful. This can result in a massive window of time before
> the machine can do anything useful.
> As a potential approach to mitigate the huge window of time before a node is
> available, I suggest modifying the bootstrap process to only acquire a single
> initial token before being marked UP. This would likely be a configuration
> parameter "incremental_bootstrap" or something similar.
> After the node is bootstrapped with this one token, it could go into UP
> state, and could then acquire additional tokens (one or a handful at a time),
> which would be streamed over while the node is active and serving requests.
> The benefit here is that with the default 256 tokens a node could become an
> active part of the cluster with less than 1% of it's final data streamed over.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
