cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Motta (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-12008) Make decommission operations resumable
Date Sat, 30 Jul 2016 01:09:20 GMT


Paulo Motta commented on CASSANDRA-12008:

Thanks for the update! See follow-up below:

bq. I've added a new strategy, please let me know what do you think about it.

Instead of building a {{streamedRangesPerEndpoints Map<InetAddress, Set<Range<Token>>}}
manually, maybe it's better to modify {{getStreamedRanges}} to take a description and keyspace
as argument an return a {{Map<InetAddress, Set<Range<Token>>}} by querying
{{"SELECT * FROM system.streamed_ranges WHERE operation = ? AND keyspace_name = ?"}}.

This way you can query {{getStreamedRanges}} directly to filter already transferred ranges
when iterating {{rangesToStreamByKeyspace}}.

bq. So instead we will obtain StreamSession from StreamTransferTask.getSession() when each
StreamTransferTask is complete i.e when StreamStateStore.handleStreamEvent is invoked. All
these means that we are going to only pass its responsible keyspace.

I think we can simplify that and instead of adding {{transferTasks}} to {{SessionCompleteEvent}}
we can simply add the session description and {{transferredRangesPerKeyspace}}, and that's
all we will need to populate the streamed ranges on {{StreamStateStore}}.

A minor nit is that the transferred ranges are always being overriden on {{addTransferRanges}}
while you should append to the existing set if it's already present on {{transferredRangesPerKeyspace}}.

bq. Don't know if there's some problem with current implementation or there's something weird
in the set-up, but it skips twice the same range:

this is for different keyspaces, so you should add the keyspace name in the log message so
it's not confusing.

bq. I think it's the set-up itself since StorageService.getChangedRangesForLeaving is also
returning the same range twice

that's probably for the same reason as above, maybe it would be a good idea to add the keyspace
name in that log as well.

> Make decommission operations resumable
> --------------------------------------
>                 Key: CASSANDRA-12008
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Streaming and Messaging
>            Reporter: Tom van der Woerdt
>            Assignee: Kaide Mu
>            Priority: Minor
> We're dealing with large data sets (multiple terabytes per node) and sometimes we need
to add or remove nodes. These operations are very dependent on the entire cluster being up,
so while we're joining a new node (which sometimes takes 6 hours or longer) a lot can go wrong
and in a lot of cases something does.
> It would be great if the ability to retry streams was implemented.
> Example to illustrate the problem :
> {code}
> 03:18 PM   ~ $ nodetool decommission
> error: Stream failed
> -- StackTrace --
> org.apache.cassandra.streaming.StreamException: Stream failed
>         at
>         at$
>         at$DirectExecutor.execute(
>         at
>         at
>         at
>         at org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(
>         at org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(
>         at org.apache.cassandra.streaming.StreamSession.closeSession(
>         at org.apache.cassandra.streaming.StreamSession.complete(
>         at org.apache.cassandra.streaming.StreamSession.messageReceived(
>         at org.apache.cassandra.streaming.ConnectionHandler$
>         at
> 08:04 PM   ~ $ nodetool decommission
> nodetool: Unsupported operation: Node in LEAVING state; wait for status to become normal
or restart
> See 'nodetool help' or 'nodetool help <command>'.
> {code}
> Streaming failed, probably due to load :
> {code}
> ERROR [STREAM-IN-/<ipaddr>] 2016-06-14 18:05:47,275 - [Stream
#<streamid>] Streaming error occurred
> null
>         at$ ~[na:1.8.0_77]
>         at ~[na:1.8.0_77]
>         at java.nio.channels.Channels$
>         at org.apache.cassandra.streaming.messages.StreamMessage.deserialize(
>         at org.apache.cassandra.streaming.ConnectionHandler$
>         at [na:1.8.0_77]
> {code}
> If implementing retries is not possible, can we have a 'nodetool decommission resume'?

This message was sent by Atlassian JIRA

View raw message