cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Reopened] (CASSANDRA-833) fix consistencylevel during bootstrap
Date Thu, 20 Sep 2012 17:42:07 GMT


Jonathan Ellis reopened CASSANDRA-833:

      Assignee: Jonathan Ellis  (was: Sylvain Lebresne)

Well, WTF.

commit 063c8f6cf7b12e976b0d7067037c52c548c6c0db
Author: Jonathan Ellis <>
Date:   Thu Jun 9 00:16:27 2011 +0000

    revert 1133443

commit 31f0ee95e927c09183dca77be7739305ba2eeab0
Author: Jonathan Ellis <>
Date:   Wed Jun 8 15:45:54 2011 +0000

    fix inconsistency window duringbootstrap
    patch by slebresne; reviewed by jbellis for CASSANDRA-833

I have no memory of this. :)

Maybe it caused a regression?
> fix consistencylevel during bootstrap
> -------------------------------------
>                 Key: CASSANDRA-833
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.5
>            Reporter: Jonathan Ellis
>            Assignee: Jonathan Ellis
>             Fix For: 1.2.0 beta 2
>         Attachments: 0001-Increase-CL-with-boostrapping-leaving-node.patch, 833-v2.txt
> As originally designed, bootstrap nodes should *always* get *all* writes under any consistencylevel,
so when bootstrap finishes the operator can run cleanup on the old nodes w/o fear that he
might lose data.
> but if a bootstrap operation fails or is aborted, that means all writes will fail until
the ex-bootstrapping node is decommissioned.  so starting in CASSANDRA-722, we just ignore
dead nodes in consistencylevel calculations.
> but this breaks the original design.  CASSANDRA-822 adds a partial fix for this (just
adding bootstrap targets into the RF targets and hinting normally), but this is still broken
under certain conditions.  The real fix is to consider consistencylevel for two sets of nodes:
>   1. the RF targets as currently existing (no pending ranges)
>   2.  the RF targets as they will exist after all movement ops are done
> If we satisfy CL for both sets then we will always be in good shape.
> I'm not sure if we can easily calculate 2. from the current TokenMetadata, though.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message