cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-195) Improve bootstrap algorithm
Date Thu, 13 Aug 2009 16:28:14 GMT


Jonathan Ellis commented on CASSANDRA-195:


> did this so that the op doesn't have to worry about re-starting correctly in bootstrap
mode if the node died during bootstrap and got restarted.

I'm really -1 on trying to be clever and second-guessing the op.  It just leads to confusion,
e.g. when we had the CF definitions stored locally as well as in the xml -- it seemed like
adding new CFs to the xml should Just Work but it didn't because Cassandra was outsmarting

+ if (StorageService.instance().isBootstrapMode())
+ {
+ logger_.error("Cannot bootstrap another node: I'm in bootstrap mode myself!");
+ return;
+ } 

still needs to be replaced w/ assert.

+    public static String rename(String tmpFilename)

why move this to SST and make it public?  SSTW is the only user, it should stay there private.

+    public static synchronized SSTableReader renameAndOpen(String dataFileName) throws IOException

I don't think this doesn't need to be synchronized -- calling it on different args doesn't
need it, and calling it twice on the same args is erroneous.

+        boolean bootstrap = false;
+        if (bs != null && bs.contains("true"))
+            bootstrap = true;

boolean bootstrap = bs != null && bs.contains("true")

     public StorageService()

should be removed

in the endpoint-finding code:
+                       if(endPoint.equals(StorageService.getLocalStorageEndPoint()) &&

the extra check should be unnecessary, since we shouldn't be looking up endpoints at all in
bootstrap mode, right?

-                       if ( StorageService.instance().isInSameDataCenter(endpoints[j]) &&
+                       if ( StorageService.instance().isInSameDataCenter(endpoints[j]) &&
+                               && !tokenMetadata_.isBootstrapping(endpoints[j]))

I don't think this is quite right.  Introducing the new node into the right place on the ring,
but then trying to special case it to not get used, seems problematic.  (What if you only
have a replication factor of one?  Then the data will just disappear until boostrap is complete.)

Can we instead not introduce the bootstraping node into the ring until it is done?  And have
the nodes providing data to it, echo writes in the bootstrap range over?

> Improve bootstrap algorithm
> ---------------------------
>                 Key: CASSANDRA-195
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>         Environment: all
>            Reporter: Sandeep Tata
>            Assignee: Sandeep Tata
>             Fix For: 0.5
>         Attachments: 195-v1.patch, 195-v2.patch, 195-v3.patch
> When you add a node to an existing cluster and the map gets updated, the new node may
respond to read requests by saying it doesn't have any of the data until it gets the data
from the node(s) the previously owned this range (the load-balancing code, when working properly
can take care of this). While this behaviour is compatible with eventual consistency, it would
be much friendlier for the new node not to "surface" in the EndPoint maps for reads until
it has transferred the data over from the old nodes.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message