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

Introduce ability to change seed addresses on a running node

    Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Major
    • Resolution: Not A Problem
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Since seed nodes are not only used for bootstrap but also for gossiping it would be really useful to be able to replace seed addresses on running nodes without restarting them since at the moment you can only change seed nodes by changing configuration file and then restarting cassandra.

      My usecase is to be able to replace failed seed nodes in cassandra without having to proceed to a rolling restart of the cluster. And also to be able to start X nodes that initially might be independent but then would all join an existing ring by changing their seeds.

        Activity

        Hide
        jbellis Jonathan Ellis added a comment -

        the important part of gossip is "pick a random node, send what I know about the cluster to it." seeds are only special cased at all to make sure that we don't end up with a partitioned cluster.

        in other words, I can't think of a reason you should need to change seeds at runtime.

        Show
        jbellis Jonathan Ellis added a comment - the important part of gossip is "pick a random node, send what I know about the cluster to it." seeds are only special cased at all to make sure that we don't end up with a partitioned cluster. in other words, I can't think of a reason you should need to change seeds at runtime.
        Hide
        robinm Robin Mahony added a comment - - edited

        what about during a recovery scenario? Today if you want to replace a dead seed node, you need to promote a new seed node first before you bootstrap a new node in place of the recovered seed node. This means to replace a seed node a rolling restart of ALL Cassandra nodes is required; which is very extreme for what should be a simple procedure. I believe that is what this jira description is all about. Does this not seem like a valid use case for such a feature?

        Show
        robinm Robin Mahony added a comment - - edited what about during a recovery scenario? Today if you want to replace a dead seed node, you need to promote a new seed node first before you bootstrap a new node in place of the recovered seed node. This means to replace a seed node a rolling restart of ALL Cassandra nodes is required; which is very extreme for what should be a simple procedure. I believe that is what this jira description is all about. Does this not seem like a valid use case for such a feature?
        Hide
        brandon.williams Brandon Williams added a comment -

        Since seed providers were introduced, the seed list is reloaded anytime a seed is removed. So to avoid a restart, first promote an existing node to a seed in the yaml files, then remove the defunct seed with removenode and the promoted seed will become active.

        Show
        brandon.williams Brandon Williams added a comment - Since seed providers were introduced, the seed list is reloaded anytime a seed is removed. So to avoid a restart, first promote an existing node to a seed in the yaml files, then remove the defunct seed with removenode and the promoted seed will become active.

          People

          • Assignee:
            Unassigned
            Reporter:
            dialtone Valentino Volonghi
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development