[ 
https://issues.apache.org/jira/browse/CASSANDRA-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis reopened CASSANDRA-833:
--------------------------------------

      Assignee: Jonathan Ellis  (was: Sylvain Lebresne)

Well, WTF.

{noformat}
commit 063c8f6cf7b12e976b0d7067037c52c548c6c0db
Author: Jonathan Ellis <[email protected]>
Date:   Thu Jun 9 00:16:27 2011 +0000

    revert 1133443
    
    git-svn-id: 
https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8@1133610 
13f79535-47bb-0310-9956-ffa450edef68

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

    fix inconsistency window duringbootstrap
    patch by slebresne; reviewed by jbellis for CASSANDRA-833
    
    git-svn-id: 
https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8@1133443 
13f79535-47bb-0310-9956-ffa450edef68
{noformat}

I have no memory of this. :)

Maybe it caused a regression?
                
> fix consistencylevel during bootstrap
> -------------------------------------
>
>                 Key: CASSANDRA-833
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-833
>             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: http://www.atlassian.com/software/jira

Reply via email to