Uploaded image for project: 'Cassandra'
  1. Cassandra
  2. CASSANDRA-14463

Prevent the generation of new tokens when using replace_address flag

    XMLWordPrintableJSON

    Details

    • Severity:
      Low

      Description

      This is a follow up to/replacement of CASSANDRA-14073.

      The behaviour that I want to avoid is someone trying to replace a node with the replace_address flag and mistakenly having that node listed in its own seed list which causes the node to generate a new set of random tokens before joining the ring. 

      Currently anytime an unbootstrapped node is listed in its own seed list and initial_token isn't set in the yaml, Cassandra will generate a new set of random tokens and join the ring regardless of whether it was replacing a previous node or not. 

      We could simply check for this configuration and refuse to start but I it's probably better (particularly for 3.0.X) if it's handled in the same manner as skipping streaming with the allow_unsafe_replace flag that was introduced in 3.X . This would still allow 3.0.X users the ability to re-bootstrap nodes without needing to re-stream all the data to the node again, which can be useful. 

      We currently handle replacing without streaming different;y between 3.0.X and 3.X. In 3.X we have the allow_unsafe_replace JVM flag to allow the use of auto_bootstrap: false in combination with the replace_address option.  But in 3.0.X to perform the replacement of a node with the same IP address without streaming I believe you need to:

      • Set replace_address (because the address is already in gossip)
      • Include the node in its own seed list (to skip bootstrapping/streaming)
      • Set the initial_token to the token/s owned by the previous node (to prevent it generating new tokens.

      I believe if 3.0.X simply refused to start when a node has itself in its seed list and replace_address set this will completely block this operation. 

      Example patches to fix this edge case using allow_unsafe_replace:

       

      Branch
      3.0.x
      3.x

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                VincentWhite Vincent White
                Reporter:
                VincentWhite Vincent White
                Authors:
                Vincent White
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated: