I dug a bit more into ReplicaPlacement, but it turns out what I think I need is variation of https://solr.apache.org/guide/solr/latest/configuration-guide/cluster-plugins.html#org-apache-solr-cluster-events-impl-collectionsrepaireventlistener
This lets me pick up node creation/deletion events and do things. However, I'm struggling to get DefaultClusterEventProducer and CollectionsRepairEventListener to work well together. Is anyone else using those capablities? On 2026/03/12 13:40:45 Gus Heck wrote: > <rant offtopic="slightly"> > > Inconsistent terminology in search has irritated me for some time. > Terminology ought to be standardized (across search software, including > elastic, OS etc). > > If I were to choose names and define them (ignoring how docs and blogs use > them otherwise) I would go with: > > *Node*: The instance of a running process that services search requests > *Server*: The hardware or VM containing the node software (possibly more > than one node on large servers) > *Collection*: The set of indexed, retreivable documents sharing a schema, > this also gets called index especially when talking about standalone or in > elastic/opensearch. Collection is better because it is clearly distinct > from the thing lucene writes to disk. (or if you're lucky it's called a > "logical index" which somewhat clarifies that one is not talking about the > physical bits on disk, but something at a higher level of abstraction), > *Corpus*: The set of documents irrespective of whether or not they are > (yet) indexed. > *Shard*: The logical slice of a collection, completely detached from any > physical manifestation. Unfortunately, it often seems to be used to mean > the first/leader replica) In code this is sometimes also called a Slice > *Replica*: A physical manifestation of a shard. When there is only one copy > of a shard we *should* be saying it has one replica. (not zero replicas, > because this obfuscates the interchangeability of replicas) > *Index*: The disk representation of the contents of a replica, written by > and interacted with via Lucene. > > The word core sometimes seems to mean index, sometimes means replica (the > things held by "CoreContainer" for example) and occasionally seems to get > used for the entire collection when there is only one shard in a small > standalone instance. Core is the worst of our terminology because in the > English language it implies centrality and unity, but in our > implementation, it actually refers to the leaf node of which we have > many... If I could, I would delete the word core from all docs and code. > Back in 2010 when I first encountered solr, the biggest stumbling block I > had in understanding Solr was disassociating the English meaning of "core" > from the way solr uses it. > > The definition in our glossary for core is self contradictory which caused > me no end of confusion when I was new (and it's still there).. it seems to > say that "core" is equivalent to "collection" above, but this doesn't match > anything in code or the rest of the documentation AFICT > > Unfortunately people hate it when you change their words for things, so we > are unlikely to achieve clarity because many folks will likely oppose > change. > > </rant> > > On Thu, Mar 12, 2026 at 8:28 AM David Eric Pugh via dev <[email protected]> > wrote: > > > David --> I oddly struggled to write the email cause I was stumbling over > > my words... I wasn't sure if I should have said "shard", and how to > > phrase a collection made up of a single core.... And then copies of that > > core... After I read your response, I thought, I should check out the > > Solr Concepts page and see what it tells me and discovered that we have > > nothing under Solr Concepts specific to this topic. I looked up in the > > glossary "SolrCloud" and it led me to > > https://solr.apache.org/guide/solr/latest/deployment-guide/cluster-types.html#solrcloud-mode. > > Only later when I scrolled up in the page did I see the section "Cluster > > Concepts". Thoughts on maybe moving that section under the Solr Concepts > > hierarchy in Ref Guide? It would have helped me use the right terms! > > > > > > > > > > On Wednesday, March 11, 2026 at 06:38:17 PM EDT, David Smiley < > > [email protected]> wrote: > > > > An aside: Remember that the leader is a replica too, so your numbers are > > off & confusing. "single shard with no replicas" -- I guessed what you > > mean but surprised to hear a misuse of SolrCloud lingo from you. AFAICT, > > leadership isn't even pertinent to your inquiry either. > > > > On Wed, Mar 11, 2026 at 5:38 PM David Eric Pugh via dev < > > [email protected]> > > wrote: > > > > > Hey all, I wanted to get some feedback from you'all on a recent usecase I > > > was asked about. I suspect the answer will be "Use Solr Operator", but > > > here goes! > > > I have an environment where I have 5 or so single shard collections. > > > Much of the time I run just a single node and each collection is a > > single > > > shard with no replicas. Sometimes, to support load, I'll add another > > node > > > or two. Then I'll add replicas so cover the new nodes, 1 per node. So > > > with three nodes, I have one leader and two replicas. Add two more > > nodes, > > > move to one leader and four replicas. > > > However, when I remove a node by shutting it down, then Zookeeper never > > > get's notified about this, and so the replica is listed as down, and the > > > node is listed as down in red in the UI. When it isn't really red, it's > > > just we don't need it for now, and it's not coming back. > > > I'd like to just declare "For this collection, I want one replica per > > node > > > based on however many nodes are current". I don't want to call the > > > various commands myself to add replicas and or remove then as nodes are > > > added or removed. And I don't want to call various apis or other complex > > > things when I add or remove a node, I just want bin/solr stop and > > bin/solr > > > start to be run ;-). > > > I think this is what Replica Placement Plugins were for maybe? Could I > > > have a Replica Placement strategy that when ZK sees a new node added, > > then > > > creates a new replica on it, and vice versa, when a node goes away, it > > just > > > removes that replica instead of treating it as "down"? > > > Thoughts? > > > Eric > > > > > > > > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
