从DataStax数据中心移除Seed节点：除nodetool decommission外需额外步骤吗？

Alright, let's walk through this clearly based on your Cassandra cluster setup. To answer your core question: yes, removing a seed node does require extra steps beyond just running nodetool decommission—seed nodes play a critical role in cluster discovery, so you need to update the cluster's seed configuration first before decommissioning them.

First, let's recap your current cluster state for clarity:

Your cluster node status:

• UN 10.10.1.56 339.96 MiB 1 ? rack1
• UN 10.10.1.46 334.72 MiB 1 ? rack1
• UN 10.10.2.76 307.72 MiB 1 ? rack2
• UN 10.10.2.66 296.15 MiB 1 ? rack2
• UN 10.10.2.86 316.89 MiB 1 ? rack2
• UN 10.10.1.36 375.69 MiB 1 ? rack1
  You have 3 seed nodes, plan to remove all 3 rack2 nodes, and reduce seeds to 2 (all in rack1).

Here's the step-by-step process to safely do this:

Step 1: Identify your current seed nodes #

First, confirm which 3 nodes are configured as seeds. Log into any node and check the cassandra.yaml file for the seed_provider section. It will look something like this:

seed_provider:
    - class_name: org.apache.cassandra.locator.SimpleSeedProvider
      parameters:
          - seeds: "10.10.1.56,10.10.1.46,10.10.2.76"

Make note of which seeds are in rack2 (these are the ones you'll need to replace in the config).

Step 2: Update the seed list on EVERY node (critical extra step) #

Since you want to keep 2 seeds in rack1, pick 2 rack1 nodes to be your new seeds (e.g., 10.10.1.56 and 10.10.1.46). Then:

• Log into every node (both rack1 keepers and rack2 nodes to be removed)
• Edit the cassandra.yaml file, update the seeds parameter to your new seed list:

  seeds: "10.10.1.56,10.10.1.46"
  

• Don't restart any nodes yet—just save the config changes across all nodes first. This ensures that when you remove the old seed nodes, all remaining nodes (and any future restarts) will use the new seed list to discover the cluster.

Step 3: Decommission non-seed rack2 nodes first (if applicable) #

If any of your rack2 nodes aren't seeds, start with those. Log into the node you want to remove and run:

nodetool decommission

Wait for the command to finish—you can check progress with nodetool netstats until you see a "DECOMMISSIONED" status. The node will show as DN (Down) in nodetool status once done.

Step 4: Decommission the rack2 seed node(s) #

Once all non-seed rack2 nodes are removed, log into each rack2 seed node and run the same decommission command:

nodetool decommission

Again, wait for the process to complete fully before moving on.

Step 5: Restart remaining rack1 nodes (optional but recommended) #

While Cassandra can pick up seed list changes at runtime, it's a good practice to restart each remaining rack1 node one at a time (to avoid cluster downtime) to ensure the new seed config is fully applied. After each restart, verify the node comes back up as UN with nodetool status.

Key Notes to Avoid Issues #

• Never remove all seeds at once: You're already planning to keep 2, so this is covered—but always ensure the new seed list is in place before removing old seeds.
• Don't force shut down nodes: Let nodetool decommission finish completely to ensure all data is migrated to remaining nodes (prevents data loss or cluster inconsistency).
• Verify after each step: Use nodetool status and nodetool netstats to confirm the cluster is healthy before moving to the next step.

内容的提问来源于stack exchange，提问作者Sreeraju V