SolrCloud模式下Configset更新异常：已注释的/spell请求处理器仍可正常工作

Let me walk through your issue and help you fix this— I’ve dealt with exactly this kind of config sync headache in SolrCloud before.

First: Are Your Steps Correct? #

Most of what you did aligns with SolrCloud best practices, but there’s a critical missing step that’s likely causing your problem. Let’s break it down:

• Creating the collection with the _default configset and letting ZooKeeper generate the amazon_products configset: Correct.
• Downloading, modifying, and re-uploading the configset to ZooKeeper: Correct.
• Restarting Solr nodes and reloading the collection: These steps are right in theory, but they don’t account for Solr’s local config caching.

Why Isn’t Your Commented-Out /spell Handler Being Disabled? #

The most common culprit here is local configset caching on Solr nodes. When a Solr node starts up in cloud mode, it downloads the configset from ZooKeeper to a local directory (usually [solr_home]/configsets/[configset_name]). If this local copy exists when you restart the node, Solr will often reuse it instead of pulling the updated version from ZooKeeper—even if the ZK copy is newer.

Other possible reasons:

• Incomplete restart: The bin/solr restart command might not have fully killed the old Solr process, leaving the original (unmodified) config loaded in memory.
• Inherited or dynamically registered handler: The /spell handler might be defined in a parent configset (like _default, which your amazon_products configset likely inherits from) or was dynamically added via the Solr API at some point, bypassing your solrconfig.xml changes.

Step-by-Step Fixes #

1. Clear Local Configset Caches on All Nodes #

This is the most important step you missed. For each Solr node:

• Stop the node first:

  bin/solr stop -p 8983  # For node1
  bin/solr stop -p 7574  # For node2
  

• Delete the local copy of the amazon_products configset:

  rm -rf example/cloud/node1/solr/configsets/amazon_products
  rm -rf example/cloud/node2/solr/configsets/amazon_products
  

2. Verify ZooKeeper Has the Updated Config #

Double-check that your changes are actually in ZK using the ZooKeeper CLI (included with Solr):

bin/zkCli.sh -server localhost:9983

Once in the CLI, run:

get /configs/amazon_products/solrconfig.xml

Confirm that the /spell request handler section is indeed commented out. Exit the CLI with quit.

3. Fully Restart All Solr Nodes #

Avoid using restart—start fresh to ensure no old processes linger:

# Start node1
bin/solr start -c -p 8983 -s example/cloud/node1/solr
# Start node2
bin/solr start -c -p 7574 -z localhost:9983 -s example/cloud/node2/solr

4. Reload the Collection (Optional but Safe) #

After nodes are up, trigger a collection reload to ensure all nodes pick up the new config:

curl "http://localhost:8983/solr/admin/collections?action=RELOAD&name=amazon_products"

5. Check for Other Handler Definitions #

If /spell still works, verify if it’s defined elsewhere:

• Check the parent _default configset’s solrconfig.xml (in ZK at /configs/_default/solrconfig.xml) to see if /spell is defined there (child configsets inherit parent settings).
• List all registered request handlers via the API:

  curl "http://localhost:8983/solr/amazon_products/admin/requestHandlers"
  

  Look for /spell and see if it has any metadata indicating where it was loaded from.

Correct Workflow for Updating SolrCloud Configsets #

To avoid this issue in the future, follow this full workflow:

1. Download the target configset from ZooKeeper to your local machine.
2. Modify the necessary files (solrconfig.xml, schema, etc.).
3. Upload the modified configset back to ZooKeeper, overwriting the existing one.
4. Delete the local configset cache on every Solr node.
5. Restart all nodes (or reload the collection, but restart is more reliable for handler changes).

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