Subject: Re: Getting rid of Master/Slave nomenclature in Solr
Here is some of the work I did to remedy this effort before I knew about this
email:
https://github.com/apache/lucene-solr/pull/1712
https://issues.apache.org/jira/browse/SOLR-14702page=com.atlassian.jira.plugin.system.issuetabpanels
Here is some of the work I did to remedy this effort before I knew about this
email:
https://github.com/apache/lucene-solr/pull/1712
https://issues.apache.org/jira/browse/SOLR-14702page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel=17169865
It makes me sick to read
On 28/06/2020 14:42, Erick Erickson wrote:
> We need to draw a sharp distinction between standalone “going away”
> in terms of our internal code and going away in terms of the user
> experience.
It'll be hard to make it completely transparant in terms of user
experience. For instance, tere is
Wandering off topic, but still apropos Solr.
On Sun, Jun 28, 2020 at 12:14:56PM +0200, Ilan Ginzburg wrote:
> I disagree Ishan. We shouldn't get rid of standalone mode.
> I see three layers in Solr:
>
>1. Lucene (the actual search libraries)
>2. The server infra ("standalone Solr"
Please start another thread to discuss removal of standalone mode, and stay
on-topic in this one.
> 28. jun. 2020 kl. 14:42 skrev Erick Erickson :
>
> We need to draw a sharp distinction between standalone “going away”
> in terms of our internal code and going away in terms of the user
>
We need to draw a sharp distinction between standalone “going away”
in terms of our internal code and going away in terms of the user
experience.
Usually when we’re talking about standalone going a way, it’s the
former. The assumption is that we’ll use an embedded ZK that
fires up automatically
Cost of maintaining feature parity across the two modes is an overhead.
Security plugins, package manager (that doesn't work in standalone), UI,
etc. Our codebase is littered with checks to ascertain if we're zkAware.
There are massive benefits to maintainability if standalone mode were to go
I would like to know under which situations (except for the various bugs
that will be fixed eventually) would a SolrCloud solution not suffice.
AFAICT, pull replicas and tlog replicas can provide similar replication
strategies commonly used with standalone Solr. I understand that running ZK
is an
I disagree Ishan. We shouldn't get rid of standalone mode.
I see three layers in Solr:
1. Lucene (the actual search libraries)
2. The server infra ("standalone Solr" basically)
3. Cluster management (SolrCloud)
There's value in using lower layers without higher ones.
SolrCloud is a good
Rather than getting rid of the terminology, we should get rid of the
standalone mode Solr altogether. I totally understand that SolrCloud is
broken in many ways today, but we should attempt to fix it and have it as
the only mode in Solr.
On Wed, 24 Jun, 2020, 8:17 pm Mike Drob, wrote:
> Brend,
Brend,
I appreciate that you are trying to examine this issue from multiple sides
and consider future implications, but I don’t think that is a stirring
argument. By analogy, if we are out of eggs and my wife asks me to go to
the store to get some, refusing to do so on the basis that she might
Hi all,
Here is how I see it and explain to others that are not too familiar with Solr:
Solr comes in two flavours - Cloud and Standalone. In any mode Solr writes to
primary core(s). There is option to have different types of replicas, but in
Standalone mode one can only have pull replica. In
On Wed, Jun 24, 2020 at 12:45:25PM +0200, Jan Høydahl wrote:
> Master/slave and standalone are used interchangably to mean zk-less Solr. I
> have a feeling that master/slave is the more popular of the two, but
> personally I have been using both.
I've been trying to stay quiet and let the
I agree with Bernd. I believe also that change is natural so eventually one
needs to evolve the terminology or create a complete new product. To evolve the
terminology one can write a page in the ref guide for translating it and over
time adapt it in Solr etc.
> Am 24.06.2020 um 13:30 schrieb
I'm following this thread now for a while and I can understand
the wish to change some naming/wording/speech in one or the other
programs but I always get back to the one question:
"Is it the weapon which kills people or the hand controlled by
the mind which fires the weapon?"
The thread started
Master/slave and standalone are used interchangably to mean zk-less Solr. I
have a feeling that master/slave is the more popular of the two, but personally
I have been using both.
Jan
> 24. jun. 2020 kl. 06:34 skrev Noble Paul :
>
> Do we even call it the master/slave mode? I thought we had 2
Distributer/Fetcher?
On Wed, 24 Jun 2020 at 10:04, Noble Paul wrote:
> Do we even call it the master/slave mode? I thought we had 2 modes
>
> * Standalone mode
> * SolrCloud mode
>
> On Wed, Jun 24, 2020 at 3:00 AM Tomás Fernández Löbbe
> wrote:
> >
> > I agree in general with what Trey and
Do we even call it the master/slave mode? I thought we had 2 modes
* Standalone mode
* SolrCloud mode
On Wed, Jun 24, 2020 at 3:00 AM Tomás Fernández Löbbe
wrote:
>
> I agree in general with what Trey and Jan said and have suggested. I
> personally like to use "leader/follower". It's true that
I agree in general with what Trey and Jan said and have suggested. I
personally like to use "leader/follower". It's true that somewhat collides
with SolrCloud terminology, but that's not a problem IMO, now that replica
types exist, the “role” of the replica (leader vs. non-leader/follower)
doesn’t
> On Jun 19, 2020, at 7:48 AM, Phill Campbell
> wrote:
>
> Delegator - Handler
>
> A common pattern we are all aware of. Pretty simple.
The Solr master does not delegate and the slave does not handle.
The master is a server that handles replication requests from the
slave.
Delegator/handler
Time to decouple from the weighty semantics of human experience and look to
nature?
queens/workers/drones/swarms?
On Wed, 17 Jun 2020 at 20:38, Anshum Gupta wrote:
> Hi everyone,
>
> Moving a conversation that was happening on the PMC list to the public
> forum. Most of the following is
Might be confusing with the nested doc terminology
> Am 19.06.2020 um 20:14 schrieb Atita Arora :
>
> I see so many topics being discussed in this thread and I literary got lost
> somewhere , but was just thinking can we call it Parent -Child
> architecture, m sure no one will raise an
I see so many topics being discussed in this thread and I literary got lost
somewhere , but was just thinking can we call it Parent -Child
architecture, m sure no one will raise an objection there.
Although, looking at comments above I still feel it would be a bigger
effort to convince everyone
On Fri, Jun 19, 2020 at 09:22:49AM -0400, j.s. wrote:
> On 6/18/20 9:50 PM, Rahul Goswami wrote:
> > So +1 on "slave" being the problematic term IMO, not "master".
>
> but you cannot have a master without a slave, n'est-ce pas?
Well, yes. In education: Master of Science, Arts, etc. In law:
The entire idea of removing a word out of our language is problematic.
There will have to be a lot of history books that detail the terrible
conditions of peoples over recorded history changed, or removed.
I find the “F” word extremely offensive. I find references to Deity while
cursing
+1 to Jan's "clustered" vs "non clustered".
If we clean up terminology, I suggest we also clarify the meaning and use
of Slice vs Shard vs Leader vs Replica vs Core. Here's my understanding:
I consider Slice == Shard (and would happily drop Slice): a logical concept
of a specific subset of a
hi
solr is very helpful.
On 6/18/20 9:50 PM, Rahul Goswami wrote:
So +1 on "slave" being the problematic term IMO, not "master".
but you cannot have a master without a slave, n'est-ce pas?
i think it is better to use the metaphor of copying rather than one of
hierarchy. language has so
gt;>
>>>>> Jason
>>>>>
>>>>>
>>>>> On Thu, Jun 18, 2020 at 7:33 AM Demian Katz >>
>>>>> wrote:
>>>>>>
>>>>>> Regarding people having a problem with the word "master&quo
t; >>>>>> 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 t
mentation, 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
> > >>&g
> >>>>>> 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.
> >>>>>
icial to broaden the range of candidates.
From: Walter Underwood
Sent: Thursday, June 18, 2020 10:34 PM
To: solr-user@lucene.apache.org
Subject: Re: [EXTERNAL] Getting rid of Master/Slave nomenclature in Solr
We don’t get to decide whether “master” is a problem. The rest of the world
has already
;>> 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 fallin
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:
> >>>>
> >>>>
> >&
should.
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>>
>>>>>> On Thu, Jun 18, 2020 at 7:33 AM Demian Katz <
>> demian.k...@villanova.edu>
>>>>>> wrote:
>>>>>>>
>>>
nch 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:
> >>>>>
> >>>>>
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/
>>>>
e/
>>>>
>>>> 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
>
First off: Forgive me if my comments/questions are redundent or uninformed
bsaed o nthe larger discussion taking place. I have not
caught up on the whole thread before replying -- but that's solely based
on a lack of time on my part, not a lack of willingness to embrace this
change.
>From
Actually, the term “master” is a problem, so master/follower doesn’t work.
GitLab is renaming the master branch to main.
Rice University renamed College Masters to College Magisters in 2017.
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/ (my blog)
> On Jun 18,
ng
> > 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 an
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
> > Sent: Thursday, June 18, 2020 1:51 AM
Primary / satellite?
--
Mark H. Wood
Lead Technology Analyst
University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu
signature.asc
Description: PGP signature
king changes at different points in
> time.
>
> - Demian
>
> -Original Message-
> From: Noble Paul
> 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
points in time.
- Demian
-Original Message-
From: Noble Paul
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 v
+1 Noble and Ilan !!
On Thu, Jun 18, 2020 at 7:51 AM Noble Paul wrote:
> 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
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
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 wrote:
> > On Jun 17, 2020, at 4:00 PM, Shawn Heisey wrote:
> >
> > It has been interesting watching this discussion play out on multiple
>
> On Jun 17, 2020, at 4:00 PM, Shawn Heisey 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
Master/slave is not going away in our company. That cluster has zero downtime
in five years. I can’t say that about our Solr Cloud clusters.
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/ (my blog)
> On Jun 17, 2020, at 9:36 PM, Noble Paul wrote:
>
> I really do
I really do not see a reason why a master/slave terminology is a problem.
We do not have slavery anywhere in the world. Should we also remove it from
the dictionary?
The old mode is going to go away anyway. Why waste time bikeshedding on
this?
On Thu, Jun 18, 2020, 12:04 PM Trey Grainger wrote:
@Shawn,
Ok, yeah, apologies, my semantics were wrong.
I was thinking that a TLog replica is a follower role only and becomes an
NRT replica if it gets elected leader. From a pure semantics standpoint,
though, I guess technically the TLog replica doesn't "become" an NRT
replica, but just "acts
I agree with Shawn that the top contenders so far (from my
perspective) are "primary/secondary" and "publisher/subscriber", and
agree with Walter that whatever term pair is used should ideally be
usable *as a pair* (to identify a cluster type) in addition to
individually (to identify the
Perhaps Apache could provide a nomenclature suggestion that the projects could
adopt. This would stand well for the whole Apache community in regards to
BLM.
My two cents as a “user”
Good luck.
Sent from Yahoo Mail for iPhone
On Wednesday, June 17, 2020, 6:00 PM, Shawn Heisey wrote:
On 6/17/2020 2:36 PM, Trey Grainger wrote:
2) TLOG - which can only serve in the role of follower
This is inaccurate. TLOG can become leader. If that happens, then it
functions exactly like an NRT leader.
I'm aware that saying the following is bikeshedding ... but I do think
it would be
Master/slave is not just two roles, but a kind of cluster. I really don’t think
“Standalone” captures the non-Cloud cluster. Nobody in Chegg would
have any idea that “standalone” meant “no Zookeeper”.
I’ve never thought that master/slave accurately described the traditional
replication model,
Sorry:
>
> but I maintain that leader vs. follower behavior is inconsistent here.
Sorry, that should have said "I maintain that leader vs. follower behavior
is consistent here."
Trey Grainger
Founder, Searchkernel
https://searchkernel.com
On Wed, Jun 17, 2020 at 6:03 PM Trey Grainger wrote:
Hi Walter,
>In Solr Cloud, the leader knows about each follower and updates them.
Respectfully, I think you're mixing the "TYPE" of replica with the role of
the "leader" and "follower"
In SolrCloud, only if the TYPE of a follower is NRT or TLOG does the leader
push updates those followers.
When
+1 for simplifying and using the Leader/Follower Terminology. Our company
operates both SolrCloud, Standalone Solr, and Master/Slave Configurations,
outside of the Solr Developer community, it's painful and confusing to talk
about Master/Slave and Leader/Replica. It would be easier if we had the
But they are not the same. In Solr Cloud, the leader knows about each
follower and updates them. In standalone, the master has no idea that
slaves exist until a replication request arrives.
In Solr Cloud, the leader is elected. In standalone, that role is fixed at
config load time.
Looking ahead
+1 for Leader-Follower. How about Publisher-Subscriber?
On Wed, Jun 17, 2020 at 5:19 PM Rahul Goswami wrote:
> +1 on avoiding SolrCloud terminology. In the interest of keeping it obvious
> and simple, may I I please suggest primary/secondary?
>
> On Wed, Jun 17, 2020 at 5:14 PM Atita Arora
I guess I don't see it as polysemous, but instead simplifying.
In my proposal, the terms "leader" and "follower" would have the exact same
meaning in both SolrCloud and standalone mode. The only difference would be
that SolrCloud automatically manages the leaders and followers, whereas in
+1 on avoiding SolrCloud terminology. In the interest of keeping it obvious
and simple, may I I please suggest primary/secondary?
On Wed, Jun 17, 2020 at 5:14 PM Atita Arora wrote:
> I agree avoiding using of solr cloud terminology too.
>
> I may suggest going for "prime" and "clone"
> (Short
I agree avoiding using of solr cloud terminology too.
I may suggest going for "prime" and "clone"
(Short and precise as Master and Slave).
Best,
Atita
On Wed, 17 Jun 2020, 22:50 Walter Underwood, wrote:
> I strongly disagree with using the Solr Cloud leader/follower terminology
> for
I strongly disagree with using the Solr Cloud leader/follower terminology
for non-Cloud clusters. People in my company are confused enough without
using polysemous terminology.
“This node is the leader, but it means something different than the leader
in this other cluster.” I’m dreading that
Proposal:
"A Solr COLLECTION is composed of one or more SHARDS, which each have one
or more REPLICAS. Each replica can have a ROLE of either:
1) A LEADER, which can process external updates for the shard
2) A FOLLOWER, which receives updates from another replica"
(Note: I prefer "role" but if
Hi everyone,
Moving a conversation that was happening on the PMC list to the public
forum. Most of the following is just me recapping the conversation that has
happened so far.
Some members of the community have been discussing getting rid of the
master/slave nomenclature from Solr.
While this
67 matches
Mail list logo
