> Alt F: "Managed Clustering" vs. "Manual Clustering" Mode
I don’t view a set of M/S nodes as «cluster» mode, since Solr is really not doing any cluster features. It’s like spinning up two standalone MySql servers with a cron job that runs a SQL from one to the other to update itself. It provides replication, but the client app still needs to know about each individual MySql DB and choose to manually send INSERTs to the «leader» and the client also would need to know up front that those two servers are part of a «shard» so you could add LB across them. When the first MySql crashes, the cron script would start failing and it would not recover, until you manually decide in your APP that the «replica» is to become «leader». Solr Master/Slave is the same, nothing is really clustered from the application’s point of view. So perhaps just Alt G: "Clustered" vs «Non-clustered» For non-clustered mode we can then refer to shards, where each shard will have a leader that is the one you have to index to, and one or more replicas that act like PULL replicas, no other types supported in non-clustered mode. PS: I’d rather not include ZK in the naming, since we try to hide ZK and perhaps replace it with something else. Jan > 19. jun. 2020 kl. 04:40 skrev Trey Grainger <solrt...@gmail.com>: > >> >> Let’s instead find a new good name for the cluster type. Standalone kind >> of works >> for me, but I see it can be confused with single-node. > > Yeah, I've typically referred to it as "standalone", but I don't think it's > descriptive enough. I can see why some people have been calling it > "master/slave" mode in lieu of a more descriptive alternative. I think a > new name (other than "standalone" or "legacy") would be superb. > > We have also discussed replacing SolrCloud (which is a terrible name) with >> something more descriptive. > > Today: SolrCloud vs Master/slave >> Alt A: SolrCloud vs Standalone >> Alt B: SolrCloud vs Legacy >> Alt C: Clustered vs Independent >> Alt D: Clustered vs Manual mode > > > +1 SolrCloud is even less descriptive and IMHO just sounds silly at this > point. > > re: "Clustered" vs Independent/Manual. The thing I don't like about that is > that you typically have clusters in both modes. I think the key distinction > is whether Solr "manages" the cluster automatically for you or whether you > manage it manually yourself. > > What do you think about: > Alt E: "Managed Clustering" vs. "Unmanaged Clustering" Mode > Alt F: "Managed Clustering" vs. "Manual Clustering" Mode > ? > > I think I prefer option F. > > Trey Grainger > Founder, Searchkernel > https://searchkernel.com > > On Thu, Jun 18, 2020 at 5:59 PM Jan Høydahl <jan....@cominvent.com> wrote: > >> I support Mike Drob and Trey Grainger. We shuold re-use the leader/replica >> terminology from Cloud. Even if you hand-configure a master/slave cluster >> and orchestrate what doc goes to which node/shard, and hand-code your >> shards >> parameter, you will still have a cluster where you’d send updates to the >> leader of >> each shard and the replicas would replicate the index from the leader. >> >> Let’s instead find a new good name for the cluster type. Standalone kind >> of works >> for me, but I see it can be confused with single-node. We have also >> discussed >> replacing SolrCloud (which is a terrible name) with something more >> descriptive. >> >> Today: SolrCloud vs Master/slave >> Alt A: SolrCloud vs Standalone >> Alt B: SolrCloud vs Legacy >> Alt C: Clustered vs Independent >> Alt D: Clustered vs Manual mode >> >> Jan >> >>> 18. jun. 2020 kl. 15:53 skrev Mike Drob <md...@apache.org>: >>> >>> I personally think that using Solr cloud terminology for this would be >> fine >>> with leader/follower. The leader is the one that accepts updates, >> followers >>> cascade the updates somehow. The presence of ZK or election doesn’t >> really >>> change this detail. >>> >>> However, if folks feel that it’s confusing, then I can’t tell them that >>> they’re not confused. Especially when they’re working with others who >> have >>> less Solr experience than we do and are less familiar with the >> intricacies. >>> >>> Primary/Replica seems acceptable. Coordinator instead of Overseer seems >>> acceptable. >>> >>> Would love to see this in 9.0! >>> >>> Mike >>> >>> On Thu, Jun 18, 2020 at 8:25 AM John Gallagher >>> <jgallag...@slack-corp.com.invalid> wrote: >>> >>>> While on the topic of renaming roles, I'd like to propose finding a >> better >>>> term than "overseer" which has historical slavery connotations as well. >>>> Director, perhaps? >>>> >>>> >>>> John Gallagher >>>> >>>> On Thu, Jun 18, 2020 at 8:48 AM Jason Gerlowski <gerlowsk...@gmail.com> >>>> wrote: >>>> >>>>> +1 to rename master/slave, and +1 to choosing terminology distinct >>>>> from what's used for SolrCloud. I could be happy with several of the >>>>> proposed options. Since a good few have been proposed though, maybe >>>>> an eventual vote thread is the most organized way to aggregate the >>>>> opinions here. >>>>> >>>>> I'm less positive about the prospect of changing the name of our >>>>> primary git branch. Most projects that contributors might come from, >>>>> most tutorials out there to learn git, most tools built on top of git >>>>> - the majority are going to assume "master" as the main branch. I >>>>> appreciate the change that Github is trying to effect in changing the >>>>> default for new projects, but it'll be a long time before that >>>>> competes with the huge bulk of projects, documentation, etc. out there >>>>> using "master". Our contributors are smart and I'm sure they'd figure >>>>> it out if we used "main" or something else instead, but having a >>>>> non-standard git setup would be one more "papercut" in understanding >>>>> how to contribute to a project that already makes that harder than it >>>>> should. >>>>> >>>>> Jason >>>>> >>>>> >>>>> On Thu, Jun 18, 2020 at 7:33 AM Demian Katz <demian.k...@villanova.edu >>> >>>>> wrote: >>>>>> >>>>>> Regarding people having a problem with the word "master" -- GitHub is >>>>> changing the default branch name away from "master," even in isolation >>>> from >>>>> a "slave" pairing... so the terminology seems to be falling out of >> favor >>>> in >>>>> all contexts. See: >>>>>> >>>>>> >>>>> >>>> >> https://www.cnet.com/news/microsofts-github-is-removing-coding-terms-like-master-and-slave/ >>>>>> >>>>>> I'm not here to start a debate about the semantics of that, just to >>>>> provide evidence that in some communities, the term "master" is causing >>>>> concern all by itself. If we're going to make the change anyway, it >> might >>>>> be best to get it over with and pick the most appropriate terminology >> we >>>>> can agree upon, rather than trying to minimize the amount of change. >> It's >>>>> going to be backward breaking anyway, so we might as well do it all now >>>>> rather than risk having to go through two separate breaking changes at >>>>> different points in time. >>>>>> >>>>>> - Demian >>>>>> >>>>>> -----Original Message----- >>>>>> From: Noble Paul <noble.p...@gmail.com> >>>>>> Sent: Thursday, June 18, 2020 1:51 AM >>>>>> To: solr-user@lucene.apache.org >>>>>> Subject: [EXTERNAL] Re: Getting rid of Master/Slave nomenclature in >>>> Solr >>>>>> >>>>>> Looking at the code I see a 692 occurrences of the word "slave". >>>>>> Mostly variable names and ref guide docs. >>>>>> >>>>>> The word "slave" is present in the responses as well. Any change in >> the >>>>> request param/response payload is backward incompatible. >>>>>> >>>>>> I have no objection to changing the names in ref guide and other >>>>> internal variables. Going ahead with backward incompatible changes is >>>>> painful. If somebody has the appetite to take it up, it's OK >>>>>> >>>>>> If we must change, master/follower can be a good enough option. >>>>>> >>>>>> master (noun): A man in charge of an organization or group. >>>>>> master(adj) : having or showing very great skill or proficiency. >>>>>> master(verb): acquire complete knowledge or skill in (a subject, >>>>> technique, or art). >>>>>> master (verb): gain control of; overcome. >>>>>> >>>>>> I hope nobody has a problem with the term "master" >>>>>> >>>>>> On Thu, Jun 18, 2020 at 3:19 PM Ilan Ginzburg <ilans...@gmail.com> >>>>> wrote: >>>>>>> >>>>>>> Would master/follower work? >>>>>>> >>>>>>> Half the rename work while still getting rid of the slavery >>>>> connotation... >>>>>>> >>>>>>> >>>>>>> On Thu 18 Jun 2020 at 07:13, Walter Underwood <wun...@wunderwood.org >>>>> >>>>> wrote: >>>>>>> >>>>>>>>> On Jun 17, 2020, at 4:00 PM, Shawn Heisey <apa...@elyograg.org> >>>>> wrote: >>>>>>>>> >>>>>>>>> It has been interesting watching this discussion play out on >>>>>>>>> multiple >>>>>>>> open source mailing lists. On other projects, I have seen a VERY >>>>>>>> high level of resistance to these changes, which I find disturbing >>>>>>>> and surprising. >>>>>>>> >>>>>>>> Yes, it is nice to see everyone just pitch in and do it on this >>>> list. >>>>>>>> >>>>>>>> wunder >>>>>>>> Walter Underwood >>>>>>>> wun...@wunderwood.org >>>>>>>> >>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fobs >>>>>>>> erver.wunderwood.org >>>> %2F&data=02%7C01%7Cdemian.katz%40villanova.e >>>>>>>> >>>> du%7C1eef0604700a442deb7e08d8134b97fb%7C765a8de5cf9444f09cafae5bf8cf >>>>>>>> >>>> a366%7C0%7C0%7C637280562684672329&sdata=0GyK5Tlq0PGsWxl%2FirJOVN >>>>>>>> VaFCELlEChdxuLJ5RxdQs%3D&reserved=0 (my blog) >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ----------------------------------------------------- >>>>>> Noble Paul >>>>> >>>> >> >>
