Getting rid of Master/Slave nomenclature in Solr

classic Classic list List threaded Threaded
68 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Getting rid of Master/Slave nomenclature in Solr

Anshum Gupta
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 may require a non-trivial effort, a general consensus so far
seems to be to start this process and switch over incrementally, if a
single change ends up being too big.

There have been a lot of suggestions around what the new nomenclature might
look like, a few people don’t want to overlap the naming here with what
already exists in SolrCloud i.e. leader/follower.

Primary/Replica was an option that was suggested based on what other
vendors are moving towards based on Wikipedia:
https://en.wikipedia.org/wiki/Master/slave_(technology)
, however there were concerns around the use of “replica” as that denotes a
very specific concept in SolrCloud. Current terminology clearly
differentiates the use of the traditional replication model from SolrCloud
and reusing the names would make it difficult for that to happen.

There were similar concerns around using Leader/follower.

Let’s continue this conversation here while making sure that we converge
without much bike-shedding.

-Anshum
Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of Master/Slave nomenclature in Solr

Trey Grainger
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 others think it's too overloaded due to the
overseer role, we could replace it with "mode" or something similar)
-------------------------------------------

To be explicit with the above definitions:
1) In SolrCloud, the roles of leaders and followers can dynamically change
based upon the status of the cluster. In standalone mode, they can be
changed by manual intervention.
2) A leader does not have to have any followers (i.e. only one active
replica)
3) Each shard always has one leader.
4) A follower can also pull updates from another follower instead of a
leader (traditionally known as a REPEATER). A repeater is still a follower,
but would not be considered a leader because it can't process external
updates.
5) A replica cannot be both a leader and a follower.

In addition to the above roles, each replica can have a TYPE of one of:
1) NRT - which can serve in the role of leader or follower
2) TLOG - which can only serve in the role of follower
3) PULL - which can only serve in the role of follower

A replica's type may be changed automatically in the event that its role
changes.

I think this terminology is consistent with the current Leader/Follower
usage while also being able to easily accomodate a rename of the historical
master/slave terminology without mental gymnastics or the introduction or
more cognitive load through new terminology. I think adopting the
Primary/Replica terminology will be incredibly confusing given the already
specific and well established meaning of "replica" within Solr.

All the Best,

Trey Grainger
Founder, Searchkernel
https://searchkernel.com



On Wed, Jun 17, 2020 at 3:38 PM Anshum Gupta <[hidden email]> wrote:

> 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 may require a non-trivial effort, a general consensus so far
> seems to be to start this process and switch over incrementally, if a
> single change ends up being too big.
>
> There have been a lot of suggestions around what the new nomenclature might
> look like, a few people don’t want to overlap the naming here with what
> already exists in SolrCloud i.e. leader/follower.
>
> Primary/Replica was an option that was suggested based on what other
> vendors are moving towards based on Wikipedia:
> https://en.wikipedia.org/wiki/Master/slave_(technology)
> , however there were concerns around the use of “replica” as that denotes a
> very specific concept in SolrCloud. Current terminology clearly
> differentiates the use of the traditional replication model from SolrCloud
> and reusing the names would make it difficult for that to happen.
>
> There were similar concerns around using Leader/follower.
>
> Let’s continue this conversation here while making sure that we converge
> without much bike-shedding.
>
> -Anshum
>
Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of Master/Slave nomenclature in Solr

Walter Underwood
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 conversation.

I like “principal”. How about “clone” for the slave role? That suggests that
it does not accept updates and that it is loosely-coupled, only depending
on the state of the no-longer-called-master.

Chegg has five production Solr Cloud clusters and one production master/slave
cluster, so this is not a hypothetical for us. We have 100+ Solr hosts in production.

wunder
Walter Underwood
[hidden email]
http://observer.wunderwood.org/  (my blog)

> On Jun 17, 2020, at 1:36 PM, Trey Grainger <[hidden email]> wrote:
>
> 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 others think it's too overloaded due to the
> overseer role, we could replace it with "mode" or something similar)
> -------------------------------------------
>
> To be explicit with the above definitions:
> 1) In SolrCloud, the roles of leaders and followers can dynamically change
> based upon the status of the cluster. In standalone mode, they can be
> changed by manual intervention.
> 2) A leader does not have to have any followers (i.e. only one active
> replica)
> 3) Each shard always has one leader.
> 4) A follower can also pull updates from another follower instead of a
> leader (traditionally known as a REPEATER). A repeater is still a follower,
> but would not be considered a leader because it can't process external
> updates.
> 5) A replica cannot be both a leader and a follower.
>
> In addition to the above roles, each replica can have a TYPE of one of:
> 1) NRT - which can serve in the role of leader or follower
> 2) TLOG - which can only serve in the role of follower
> 3) PULL - which can only serve in the role of follower
>
> A replica's type may be changed automatically in the event that its role
> changes.
>
> I think this terminology is consistent with the current Leader/Follower
> usage while also being able to easily accomodate a rename of the historical
> master/slave terminology without mental gymnastics or the introduction or
> more cognitive load through new terminology. I think adopting the
> Primary/Replica terminology will be incredibly confusing given the already
> specific and well established meaning of "replica" within Solr.
>
> All the Best,
>
> Trey Grainger
> Founder, Searchkernel
> https://searchkernel.com
>
>
>
> On Wed, Jun 17, 2020 at 3:38 PM Anshum Gupta <[hidden email]> wrote:
>
>> 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 may require a non-trivial effort, a general consensus so far
>> seems to be to start this process and switch over incrementally, if a
>> single change ends up being too big.
>>
>> There have been a lot of suggestions around what the new nomenclature might
>> look like, a few people don’t want to overlap the naming here with what
>> already exists in SolrCloud i.e. leader/follower.
>>
>> Primary/Replica was an option that was suggested based on what other
>> vendors are moving towards based on Wikipedia:
>> https://en.wikipedia.org/wiki/Master/slave_(technology)
>> , however there were concerns around the use of “replica” as that denotes a
>> very specific concept in SolrCloud. Current terminology clearly
>> differentiates the use of the traditional replication model from SolrCloud
>> and reusing the names would make it difficult for that to happen.
>>
>> There were similar concerns around using Leader/follower.
>>
>> Let’s continue this conversation here while making sure that we converge
>> without much bike-shedding.
>>
>> -Anshum
>>

Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of Master/Slave nomenclature in Solr

Atita Arora
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, <[hidden email]> wrote:

> 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 conversation.
>
> I like “principal”. How about “clone” for the slave role? That suggests
> that
> it does not accept updates and that it is loosely-coupled, only depending
> on the state of the no-longer-called-master.
>
> Chegg has five production Solr Cloud clusters and one production
> master/slave
> cluster, so this is not a hypothetical for us. We have 100+ Solr hosts in
> production.
>
> wunder
> Walter Underwood
> [hidden email]
> http://observer.wunderwood.org/  (my blog)
>
> > On Jun 17, 2020, at 1:36 PM, Trey Grainger <[hidden email]> wrote:
> >
> > 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 others think it's too overloaded due to the
> > overseer role, we could replace it with "mode" or something similar)
> > -------------------------------------------
> >
> > To be explicit with the above definitions:
> > 1) In SolrCloud, the roles of leaders and followers can dynamically
> change
> > based upon the status of the cluster. In standalone mode, they can be
> > changed by manual intervention.
> > 2) A leader does not have to have any followers (i.e. only one active
> > replica)
> > 3) Each shard always has one leader.
> > 4) A follower can also pull updates from another follower instead of a
> > leader (traditionally known as a REPEATER). A repeater is still a
> follower,
> > but would not be considered a leader because it can't process external
> > updates.
> > 5) A replica cannot be both a leader and a follower.
> >
> > In addition to the above roles, each replica can have a TYPE of one of:
> > 1) NRT - which can serve in the role of leader or follower
> > 2) TLOG - which can only serve in the role of follower
> > 3) PULL - which can only serve in the role of follower
> >
> > A replica's type may be changed automatically in the event that its role
> > changes.
> >
> > I think this terminology is consistent with the current Leader/Follower
> > usage while also being able to easily accomodate a rename of the
> historical
> > master/slave terminology without mental gymnastics or the introduction or
> > more cognitive load through new terminology. I think adopting the
> > Primary/Replica terminology will be incredibly confusing given the
> already
> > specific and well established meaning of "replica" within Solr.
> >
> > All the Best,
> >
> > Trey Grainger
> > Founder, Searchkernel
> > https://searchkernel.com
> >
> >
> >
> > On Wed, Jun 17, 2020 at 3:38 PM Anshum Gupta <[hidden email]>
> wrote:
> >
> >> 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 may require a non-trivial effort, a general consensus so far
> >> seems to be to start this process and switch over incrementally, if a
> >> single change ends up being too big.
> >>
> >> There have been a lot of suggestions around what the new nomenclature
> might
> >> look like, a few people don’t want to overlap the naming here with what
> >> already exists in SolrCloud i.e. leader/follower.
> >>
> >> Primary/Replica was an option that was suggested based on what other
> >> vendors are moving towards based on Wikipedia:
> >> https://en.wikipedia.org/wiki/Master/slave_(technology)
> >> , however there were concerns around the use of “replica” as that
> denotes a
> >> very specific concept in SolrCloud. Current terminology clearly
> >> differentiates the use of the traditional replication model from
> SolrCloud
> >> and reusing the names would make it difficult for that to happen.
> >>
> >> There were similar concerns around using Leader/follower.
> >>
> >> Let’s continue this conversation here while making sure that we converge
> >> without much bike-shedding.
> >>
> >> -Anshum
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of Master/Slave nomenclature in Solr

Rahul Goswami
+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 <[hidden email]> wrote:

> 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, <[hidden email]>
> wrote:
>
> > 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 conversation.
> >
> > I like “principal”. How about “clone” for the slave role? That suggests
> > that
> > it does not accept updates and that it is loosely-coupled, only depending
> > on the state of the no-longer-called-master.
> >
> > Chegg has five production Solr Cloud clusters and one production
> > master/slave
> > cluster, so this is not a hypothetical for us. We have 100+ Solr hosts in
> > production.
> >
> > wunder
> > Walter Underwood
> > [hidden email]
> > http://observer.wunderwood.org/  (my blog)
> >
> > > On Jun 17, 2020, at 1:36 PM, Trey Grainger <[hidden email]> wrote:
> > >
> > > 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 others think it's too overloaded due to
> the
> > > overseer role, we could replace it with "mode" or something similar)
> > > -------------------------------------------
> > >
> > > To be explicit with the above definitions:
> > > 1) In SolrCloud, the roles of leaders and followers can dynamically
> > change
> > > based upon the status of the cluster. In standalone mode, they can be
> > > changed by manual intervention.
> > > 2) A leader does not have to have any followers (i.e. only one active
> > > replica)
> > > 3) Each shard always has one leader.
> > > 4) A follower can also pull updates from another follower instead of a
> > > leader (traditionally known as a REPEATER). A repeater is still a
> > follower,
> > > but would not be considered a leader because it can't process external
> > > updates.
> > > 5) A replica cannot be both a leader and a follower.
> > >
> > > In addition to the above roles, each replica can have a TYPE of one of:
> > > 1) NRT - which can serve in the role of leader or follower
> > > 2) TLOG - which can only serve in the role of follower
> > > 3) PULL - which can only serve in the role of follower
> > >
> > > A replica's type may be changed automatically in the event that its
> role
> > > changes.
> > >
> > > I think this terminology is consistent with the current Leader/Follower
> > > usage while also being able to easily accomodate a rename of the
> > historical
> > > master/slave terminology without mental gymnastics or the introduction
> or
> > > more cognitive load through new terminology. I think adopting the
> > > Primary/Replica terminology will be incredibly confusing given the
> > already
> > > specific and well established meaning of "replica" within Solr.
> > >
> > > All the Best,
> > >
> > > Trey Grainger
> > > Founder, Searchkernel
> > > https://searchkernel.com
> > >
> > >
> > >
> > > On Wed, Jun 17, 2020 at 3:38 PM Anshum Gupta <[hidden email]>
> > wrote:
> > >
> > >> 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 may require a non-trivial effort, a general consensus so
> far
> > >> seems to be to start this process and switch over incrementally, if a
> > >> single change ends up being too big.
> > >>
> > >> There have been a lot of suggestions around what the new nomenclature
> > might
> > >> look like, a few people don’t want to overlap the naming here with
> what
> > >> already exists in SolrCloud i.e. leader/follower.
> > >>
> > >> Primary/Replica was an option that was suggested based on what other
> > >> vendors are moving towards based on Wikipedia:
> > >> https://en.wikipedia.org/wiki/Master/slave_(technology)
> > >> , however there were concerns around the use of “replica” as that
> > denotes a
> > >> very specific concept in SolrCloud. Current terminology clearly
> > >> differentiates the use of the traditional replication model from
> > SolrCloud
> > >> and reusing the names would make it difficult for that to happen.
> > >>
> > >> There were similar concerns around using Leader/follower.
> > >>
> > >> Let’s continue this conversation here while making sure that we
> converge
> > >> without much bike-shedding.
> > >>
> > >> -Anshum
> > >>
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of Master/Slave nomenclature in Solr

Trey Grainger
In reply to this post by Walter Underwood
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
standalone mode you have to manage them manually (as is the case with most
things in SolrCloud vs. Standalone).

My view is that having an entirely different set of terminology describing
the same thing is way more cognitive overhead than having consistent
terminology.

Trey Grainger
Founder, Searchkernel
https://searchkernel.com

On Wed, Jun 17, 2020 at 4:50 PM Walter Underwood <[hidden email]>
wrote:

> 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 conversation.
>
> I like “principal”. How about “clone” for the slave role? That suggests
> that
> it does not accept updates and that it is loosely-coupled, only depending
> on the state of the no-longer-called-master.
>
> Chegg has five production Solr Cloud clusters and one production
> master/slave
> cluster, so this is not a hypothetical for us. We have 100+ Solr hosts in
> production.
>
> wunder
> Walter Underwood
> [hidden email]
> http://observer.wunderwood.org/  (my blog)
>
> > On Jun 17, 2020, at 1:36 PM, Trey Grainger <[hidden email]> wrote:
> >
> > 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 others think it's too overloaded due to the
> > overseer role, we could replace it with "mode" or something similar)
> > -------------------------------------------
> >
> > To be explicit with the above definitions:
> > 1) In SolrCloud, the roles of leaders and followers can dynamically
> change
> > based upon the status of the cluster. In standalone mode, they can be
> > changed by manual intervention.
> > 2) A leader does not have to have any followers (i.e. only one active
> > replica)
> > 3) Each shard always has one leader.
> > 4) A follower can also pull updates from another follower instead of a
> > leader (traditionally known as a REPEATER). A repeater is still a
> follower,
> > but would not be considered a leader because it can't process external
> > updates.
> > 5) A replica cannot be both a leader and a follower.
> >
> > In addition to the above roles, each replica can have a TYPE of one of:
> > 1) NRT - which can serve in the role of leader or follower
> > 2) TLOG - which can only serve in the role of follower
> > 3) PULL - which can only serve in the role of follower
> >
> > A replica's type may be changed automatically in the event that its role
> > changes.
> >
> > I think this terminology is consistent with the current Leader/Follower
> > usage while also being able to easily accomodate a rename of the
> historical
> > master/slave terminology without mental gymnastics or the introduction or
> > more cognitive load through new terminology. I think adopting the
> > Primary/Replica terminology will be incredibly confusing given the
> already
> > specific and well established meaning of "replica" within Solr.
> >
> > All the Best,
> >
> > Trey Grainger
> > Founder, Searchkernel
> > https://searchkernel.com
> >
> >
> >
> > On Wed, Jun 17, 2020 at 3:38 PM Anshum Gupta <[hidden email]>
> wrote:
> >
> >> 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 may require a non-trivial effort, a general consensus so far
> >> seems to be to start this process and switch over incrementally, if a
> >> single change ends up being too big.
> >>
> >> There have been a lot of suggestions around what the new nomenclature
> might
> >> look like, a few people don’t want to overlap the naming here with what
> >> already exists in SolrCloud i.e. leader/follower.
> >>
> >> Primary/Replica was an option that was suggested based on what other
> >> vendors are moving towards based on Wikipedia:
> >> https://en.wikipedia.org/wiki/Master/slave_(technology)
> >> , however there were concerns around the use of “replica” as that
> denotes a
> >> very specific concept in SolrCloud. Current terminology clearly
> >> differentiates the use of the traditional replication model from
> SolrCloud
> >> and reusing the names would make it difficult for that to happen.
> >>
> >> There were similar concerns around using Leader/follower.
> >>
> >> Let’s continue this conversation here while making sure that we converge
> >> without much bike-shedding.
> >>
> >> -Anshum
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of Master/Slave nomenclature in Solr

gnandre
In reply to this post by Rahul Goswami
+1 for Leader-Follower. How about Publisher-Subscriber?

On Wed, Jun 17, 2020 at 5:19 PM Rahul Goswami <[hidden email]> 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 <[hidden email]> wrote:
>
> > 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, <[hidden email]>
> > wrote:
> >
> > > 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 conversation.
> > >
> > > I like “principal”. How about “clone” for the slave role? That suggests
> > > that
> > > it does not accept updates and that it is loosely-coupled, only
> depending
> > > on the state of the no-longer-called-master.
> > >
> > > Chegg has five production Solr Cloud clusters and one production
> > > master/slave
> > > cluster, so this is not a hypothetical for us. We have 100+ Solr hosts
> in
> > > production.
> > >
> > > wunder
> > > Walter Underwood
> > > [hidden email]
> > > http://observer.wunderwood.org/  (my blog)
> > >
> > > > On Jun 17, 2020, at 1:36 PM, Trey Grainger <[hidden email]>
> wrote:
> > > >
> > > > 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 others think it's too overloaded due to
> > the
> > > > overseer role, we could replace it with "mode" or something similar)
> > > > -------------------------------------------
> > > >
> > > > To be explicit with the above definitions:
> > > > 1) In SolrCloud, the roles of leaders and followers can dynamically
> > > change
> > > > based upon the status of the cluster. In standalone mode, they can be
> > > > changed by manual intervention.
> > > > 2) A leader does not have to have any followers (i.e. only one active
> > > > replica)
> > > > 3) Each shard always has one leader.
> > > > 4) A follower can also pull updates from another follower instead of
> a
> > > > leader (traditionally known as a REPEATER). A repeater is still a
> > > follower,
> > > > but would not be considered a leader because it can't process
> external
> > > > updates.
> > > > 5) A replica cannot be both a leader and a follower.
> > > >
> > > > In addition to the above roles, each replica can have a TYPE of one
> of:
> > > > 1) NRT - which can serve in the role of leader or follower
> > > > 2) TLOG - which can only serve in the role of follower
> > > > 3) PULL - which can only serve in the role of follower
> > > >
> > > > A replica's type may be changed automatically in the event that its
> > role
> > > > changes.
> > > >
> > > > I think this terminology is consistent with the current
> Leader/Follower
> > > > usage while also being able to easily accomodate a rename of the
> > > historical
> > > > master/slave terminology without mental gymnastics or the
> introduction
> > or
> > > > more cognitive load through new terminology. I think adopting the
> > > > Primary/Replica terminology will be incredibly confusing given the
> > > already
> > > > specific and well established meaning of "replica" within Solr.
> > > >
> > > > All the Best,
> > > >
> > > > Trey Grainger
> > > > Founder, Searchkernel
> > > > https://searchkernel.com
> > > >
> > > >
> > > >
> > > > On Wed, Jun 17, 2020 at 3:38 PM Anshum Gupta <[hidden email]
> >
> > > wrote:
> > > >
> > > >> 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 may require a non-trivial effort, a general consensus so
> > far
> > > >> seems to be to start this process and switch over incrementally, if
> a
> > > >> single change ends up being too big.
> > > >>
> > > >> There have been a lot of suggestions around what the new
> nomenclature
> > > might
> > > >> look like, a few people don’t want to overlap the naming here with
> > what
> > > >> already exists in SolrCloud i.e. leader/follower.
> > > >>
> > > >> Primary/Replica was an option that was suggested based on what other
> > > >> vendors are moving towards based on Wikipedia:
> > > >> https://en.wikipedia.org/wiki/Master/slave_(technology)
> > > >> , however there were concerns around the use of “replica” as that
> > > denotes a
> > > >> very specific concept in SolrCloud. Current terminology clearly
> > > >> differentiates the use of the traditional replication model from
> > > SolrCloud
> > > >> and reusing the names would make it difficult for that to happen.
> > > >>
> > > >> There were similar concerns around using Leader/follower.
> > > >>
> > > >> Let’s continue this conversation here while making sure that we
> > converge
> > > >> without much bike-shedding.
> > > >>
> > > >> -Anshum
> > > >>
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of Master/Slave nomenclature in Solr

Walter Underwood
In reply to this post by Trey Grainger
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 in my email inbox, publisher/subscriber is an excellent choice.

wunder
Walter Underwood
[hidden email]
http://observer.wunderwood.org/  (my blog)

> On Jun 17, 2020, at 2:21 PM, Trey Grainger <[hidden email]> wrote:
>
> 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
> standalone mode you have to manage them manually (as is the case with most
> things in SolrCloud vs. Standalone).
>
> My view is that having an entirely different set of terminology describing
> the same thing is way more cognitive overhead than having consistent
> terminology.
>
> Trey Grainger
> Founder, Searchkernel
> https://searchkernel.com
>
> On Wed, Jun 17, 2020 at 4:50 PM Walter Underwood <[hidden email]>
> wrote:
>
>> 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 conversation.
>>
>> I like “principal”. How about “clone” for the slave role? That suggests
>> that
>> it does not accept updates and that it is loosely-coupled, only depending
>> on the state of the no-longer-called-master.
>>
>> Chegg has five production Solr Cloud clusters and one production
>> master/slave
>> cluster, so this is not a hypothetical for us. We have 100+ Solr hosts in
>> production.
>>
>> wunder
>> Walter Underwood
>> [hidden email]
>> http://observer.wunderwood.org/  (my blog)
>>
>>> On Jun 17, 2020, at 1:36 PM, Trey Grainger <[hidden email]> wrote:
>>>
>>> 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 others think it's too overloaded due to the
>>> overseer role, we could replace it with "mode" or something similar)
>>> -------------------------------------------
>>>
>>> To be explicit with the above definitions:
>>> 1) In SolrCloud, the roles of leaders and followers can dynamically
>> change
>>> based upon the status of the cluster. In standalone mode, they can be
>>> changed by manual intervention.
>>> 2) A leader does not have to have any followers (i.e. only one active
>>> replica)
>>> 3) Each shard always has one leader.
>>> 4) A follower can also pull updates from another follower instead of a
>>> leader (traditionally known as a REPEATER). A repeater is still a
>> follower,
>>> but would not be considered a leader because it can't process external
>>> updates.
>>> 5) A replica cannot be both a leader and a follower.
>>>
>>> In addition to the above roles, each replica can have a TYPE of one of:
>>> 1) NRT - which can serve in the role of leader or follower
>>> 2) TLOG - which can only serve in the role of follower
>>> 3) PULL - which can only serve in the role of follower
>>>
>>> A replica's type may be changed automatically in the event that its role
>>> changes.
>>>
>>> I think this terminology is consistent with the current Leader/Follower
>>> usage while also being able to easily accomodate a rename of the
>> historical
>>> master/slave terminology without mental gymnastics or the introduction or
>>> more cognitive load through new terminology. I think adopting the
>>> Primary/Replica terminology will be incredibly confusing given the
>> already
>>> specific and well established meaning of "replica" within Solr.
>>>
>>> All the Best,
>>>
>>> Trey Grainger
>>> Founder, Searchkernel
>>> https://searchkernel.com
>>>
>>>
>>>
>>> On Wed, Jun 17, 2020 at 3:38 PM Anshum Gupta <[hidden email]>
>> wrote:
>>>
>>>> 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 may require a non-trivial effort, a general consensus so far
>>>> seems to be to start this process and switch over incrementally, if a
>>>> single change ends up being too big.
>>>>
>>>> There have been a lot of suggestions around what the new nomenclature
>> might
>>>> look like, a few people don’t want to overlap the naming here with what
>>>> already exists in SolrCloud i.e. leader/follower.
>>>>
>>>> Primary/Replica was an option that was suggested based on what other
>>>> vendors are moving towards based on Wikipedia:
>>>> https://en.wikipedia.org/wiki/Master/slave_(technology)
>>>> , however there were concerns around the use of “replica” as that
>> denotes a
>>>> very specific concept in SolrCloud. Current terminology clearly
>>>> differentiates the use of the traditional replication model from
>> SolrCloud
>>>> and reusing the names would make it difficult for that to happen.
>>>>
>>>> There were similar concerns around using Leader/follower.
>>>>
>>>> Let’s continue this conversation here while making sure that we converge
>>>> without much bike-shedding.
>>>>
>>>> -Anshum
>>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of Master/Slave nomenclature in Solr

Sameer Maggon-5
In reply to this post by gnandre
+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
following:

The internal differences between manual configuration or SolrCloud being
smart about managing and assigning roles are just the evolution of the
design and details of a particular mode/implementation and shouldn't matter
to the end-user.

Today, when someone not involved in the Solr development looks at the
terminology, it looks new terminology is introduced without thinking about
existing customers or thinking through the system as a whole and how to
best evolve it (not saying that's what happened, but just a perception).
Adding new terminology should be introduced carefully and +1 on reducing
the cognitive load on an average guy like me.

- There are leaders and there are followers
- Solr Clusters can be configured in two modes/implementation (SolrCloud or
Master/Slave). This one is hard because you don't want to introduce yet
another name here as people are now already familiar with it.
- These modes happen to have different designs and depending upon the mode,
you can go into the design differences of these two modes.

Cheers!
--

*Sameer Maggon*
*SearchStax* | www.searchstax.com


On Wed, Jun 17, 2020 at 2:22 PM gnandre <[hidden email]> wrote:

> +1 for Leader-Follower. How about Publisher-Subscriber?
>
> On Wed, Jun 17, 2020 at 5:19 PM Rahul Goswami <[hidden email]>
> 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 <[hidden email]>
> wrote:
> >
> > > 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, <[hidden email]>
> > > wrote:
> > >
> > > > 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 conversation.
> > > >
> > > > I like “principal”. How about “clone” for the slave role? That
> suggests
> > > > that
> > > > it does not accept updates and that it is loosely-coupled, only
> > depending
> > > > on the state of the no-longer-called-master.
> > > >
> > > > Chegg has five production Solr Cloud clusters and one production
> > > > master/slave
> > > > cluster, so this is not a hypothetical for us. We have 100+ Solr
> hosts
> > in
> > > > production.
> > > >
> > > > wunder
> > > > Walter Underwood
> > > > [hidden email]
> > > > http://observer.wunderwood.org/  (my blog)
> > > >
> > > > > On Jun 17, 2020, at 1:36 PM, Trey Grainger <[hidden email]>
> > wrote:
> > > > >
> > > > > 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 others think it's too overloaded due
> to
> > > the
> > > > > overseer role, we could replace it with "mode" or something
> similar)
> > > > > -------------------------------------------
> > > > >
> > > > > To be explicit with the above definitions:
> > > > > 1) In SolrCloud, the roles of leaders and followers can dynamically
> > > > change
> > > > > based upon the status of the cluster. In standalone mode, they can
> be
> > > > > changed by manual intervention.
> > > > > 2) A leader does not have to have any followers (i.e. only one
> active
> > > > > replica)
> > > > > 3) Each shard always has one leader.
> > > > > 4) A follower can also pull updates from another follower instead
> of
> > a
> > > > > leader (traditionally known as a REPEATER). A repeater is still a
> > > > follower,
> > > > > but would not be considered a leader because it can't process
> > external
> > > > > updates.
> > > > > 5) A replica cannot be both a leader and a follower.
> > > > >
> > > > > In addition to the above roles, each replica can have a TYPE of one
> > of:
> > > > > 1) NRT - which can serve in the role of leader or follower
> > > > > 2) TLOG - which can only serve in the role of follower
> > > > > 3) PULL - which can only serve in the role of follower
> > > > >
> > > > > A replica's type may be changed automatically in the event that its
> > > role
> > > > > changes.
> > > > >
> > > > > I think this terminology is consistent with the current
> > Leader/Follower
> > > > > usage while also being able to easily accomodate a rename of the
> > > > historical
> > > > > master/slave terminology without mental gymnastics or the
> > introduction
> > > or
> > > > > more cognitive load through new terminology. I think adopting the
> > > > > Primary/Replica terminology will be incredibly confusing given the
> > > > already
> > > > > specific and well established meaning of "replica" within Solr.
> > > > >
> > > > > All the Best,
> > > > >
> > > > > Trey Grainger
> > > > > Founder, Searchkernel
> > > > > https://searchkernel.com
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Jun 17, 2020 at 3:38 PM Anshum Gupta <
> [hidden email]
> > >
> > > > wrote:
> > > > >
> > > > >> 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 may require a non-trivial effort, a general consensus
> so
> > > far
> > > > >> seems to be to start this process and switch over incrementally,
> if
> > a
> > > > >> single change ends up being too big.
> > > > >>
> > > > >> There have been a lot of suggestions around what the new
> > nomenclature
> > > > might
> > > > >> look like, a few people don’t want to overlap the naming here with
> > > what
> > > > >> already exists in SolrCloud i.e. leader/follower.
> > > > >>
> > > > >> Primary/Replica was an option that was suggested based on what
> other
> > > > >> vendors are moving towards based on Wikipedia:
> > > > >> https://en.wikipedia.org/wiki/Master/slave_(technology)
> > > > >> , however there were concerns around the use of “replica” as that
> > > > denotes a
> > > > >> very specific concept in SolrCloud. Current terminology clearly
> > > > >> differentiates the use of the traditional replication model from
> > > > SolrCloud
> > > > >> and reusing the names would make it difficult for that to happen.
> > > > >>
> > > > >> There were similar concerns around using Leader/follower.
> > > > >>
> > > > >> Let’s continue this conversation here while making sure that we
> > > converge
> > > > >> without much bike-shedding.
> > > > >>
> > > > >> -Anshum
> > > > >>
> > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of Master/Slave nomenclature in Solr

Trey Grainger
In reply to this post by Walter Underwood
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 the TYPE of a follower is PULL, then it does not.  In Standalone mode,
the type of a (currently) master would be NRT, and the type of the
(currently) slaves is always PULL.

As such, this behavior is consistent across both SolrCloud and Standalone
mode. It is true that Standalone mode does not currently have support for
two of the replica TYPES that SolrCloud mode does, but I maintain that
leader vs. follower behavior is inconsistent here.

Trey Grainger
Founder, Searchkernel
https://searchkernel.com



On Wed, Jun 17, 2020 at 5:41 PM Walter Underwood <[hidden email]>
wrote:

> 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 in my email inbox, publisher/subscriber is an excellent
> choice.
>
> wunder
> Walter Underwood
> [hidden email]
> http://observer.wunderwood.org/  (my blog)
>
> > On Jun 17, 2020, at 2:21 PM, Trey Grainger <[hidden email]> wrote:
> >
> > 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
> > standalone mode you have to manage them manually (as is the case with
> most
> > things in SolrCloud vs. Standalone).
> >
> > My view is that having an entirely different set of terminology
> describing
> > the same thing is way more cognitive overhead than having consistent
> > terminology.
> >
> > Trey Grainger
> > Founder, Searchkernel
> > https://searchkernel.com
> >
> > On Wed, Jun 17, 2020 at 4:50 PM Walter Underwood <[hidden email]>
> > wrote:
> >
> >> 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 conversation.
> >>
> >> I like “principal”. How about “clone” for the slave role? That suggests
> >> that
> >> it does not accept updates and that it is loosely-coupled, only
> depending
> >> on the state of the no-longer-called-master.
> >>
> >> Chegg has five production Solr Cloud clusters and one production
> >> master/slave
> >> cluster, so this is not a hypothetical for us. We have 100+ Solr hosts
> in
> >> production.
> >>
> >> wunder
> >> Walter Underwood
> >> [hidden email]
> >> http://observer.wunderwood.org/  (my blog)
> >>
> >>> On Jun 17, 2020, at 1:36 PM, Trey Grainger <[hidden email]> wrote:
> >>>
> >>> 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 others think it's too overloaded due to
> the
> >>> overseer role, we could replace it with "mode" or something similar)
> >>> -------------------------------------------
> >>>
> >>> To be explicit with the above definitions:
> >>> 1) In SolrCloud, the roles of leaders and followers can dynamically
> >> change
> >>> based upon the status of the cluster. In standalone mode, they can be
> >>> changed by manual intervention.
> >>> 2) A leader does not have to have any followers (i.e. only one active
> >>> replica)
> >>> 3) Each shard always has one leader.
> >>> 4) A follower can also pull updates from another follower instead of a
> >>> leader (traditionally known as a REPEATER). A repeater is still a
> >> follower,
> >>> but would not be considered a leader because it can't process external
> >>> updates.
> >>> 5) A replica cannot be both a leader and a follower.
> >>>
> >>> In addition to the above roles, each replica can have a TYPE of one of:
> >>> 1) NRT - which can serve in the role of leader or follower
> >>> 2) TLOG - which can only serve in the role of follower
> >>> 3) PULL - which can only serve in the role of follower
> >>>
> >>> A replica's type may be changed automatically in the event that its
> role
> >>> changes.
> >>>
> >>> I think this terminology is consistent with the current Leader/Follower
> >>> usage while also being able to easily accomodate a rename of the
> >> historical
> >>> master/slave terminology without mental gymnastics or the introduction
> or
> >>> more cognitive load through new terminology. I think adopting the
> >>> Primary/Replica terminology will be incredibly confusing given the
> >> already
> >>> specific and well established meaning of "replica" within Solr.
> >>>
> >>> All the Best,
> >>>
> >>> Trey Grainger
> >>> Founder, Searchkernel
> >>> https://searchkernel.com
> >>>
> >>>
> >>>
> >>> On Wed, Jun 17, 2020 at 3:38 PM Anshum Gupta <[hidden email]>
> >> wrote:
> >>>
> >>>> 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 may require a non-trivial effort, a general consensus so
> far
> >>>> seems to be to start this process and switch over incrementally, if a
> >>>> single change ends up being too big.
> >>>>
> >>>> There have been a lot of suggestions around what the new nomenclature
> >> might
> >>>> look like, a few people don’t want to overlap the naming here with
> what
> >>>> already exists in SolrCloud i.e. leader/follower.
> >>>>
> >>>> Primary/Replica was an option that was suggested based on what other
> >>>> vendors are moving towards based on Wikipedia:
> >>>> https://en.wikipedia.org/wiki/Master/slave_(technology)
> >>>> , however there were concerns around the use of “replica” as that
> >> denotes a
> >>>> very specific concept in SolrCloud. Current terminology clearly
> >>>> differentiates the use of the traditional replication model from
> >> SolrCloud
> >>>> and reusing the names would make it difficult for that to happen.
> >>>>
> >>>> There were similar concerns around using Leader/follower.
> >>>>
> >>>> Let’s continue this conversation here while making sure that we
> converge
> >>>> without much bike-shedding.
> >>>>
> >>>> -Anshum
> >>>>
> >>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of Master/Slave nomenclature in Solr

Trey Grainger
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 <[hidden email]> 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 the TYPE of a follower is PULL, then it does not.  In Standalone
> mode, the type of a (currently) master would be NRT, and the type of the
> (currently) slaves is always PULL.
>
> As such, this behavior is consistent across both SolrCloud and Standalone
> mode. It is true that Standalone mode does not currently have support for
> two of the replica TYPES that SolrCloud mode does, but I maintain that
> leader vs. follower behavior is inconsistent here.
>
> Trey Grainger
> Founder, Searchkernel
> https://searchkernel.com
>
>
>
> On Wed, Jun 17, 2020 at 5:41 PM Walter Underwood <[hidden email]>
> wrote:
>
>> 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 in my email inbox, publisher/subscriber is an excellent
>> choice.
>>
>> wunder
>> Walter Underwood
>> [hidden email]
>> http://observer.wunderwood.org/  (my blog)
>>
>> > On Jun 17, 2020, at 2:21 PM, Trey Grainger <[hidden email]> wrote:
>> >
>> > 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
>> > standalone mode you have to manage them manually (as is the case with
>> most
>> > things in SolrCloud vs. Standalone).
>> >
>> > My view is that having an entirely different set of terminology
>> describing
>> > the same thing is way more cognitive overhead than having consistent
>> > terminology.
>> >
>> > Trey Grainger
>> > Founder, Searchkernel
>> > https://searchkernel.com
>> >
>> > On Wed, Jun 17, 2020 at 4:50 PM Walter Underwood <[hidden email]
>> >
>> > wrote:
>> >
>> >> 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 conversation.
>> >>
>> >> I like “principal”. How about “clone” for the slave role? That suggests
>> >> that
>> >> it does not accept updates and that it is loosely-coupled, only
>> depending
>> >> on the state of the no-longer-called-master.
>> >>
>> >> Chegg has five production Solr Cloud clusters and one production
>> >> master/slave
>> >> cluster, so this is not a hypothetical for us. We have 100+ Solr hosts
>> in
>> >> production.
>> >>
>> >> wunder
>> >> Walter Underwood
>> >> [hidden email]
>> >> http://observer.wunderwood.org/  (my blog)
>> >>
>> >>> On Jun 17, 2020, at 1:36 PM, Trey Grainger <[hidden email]>
>> wrote:
>> >>>
>> >>> 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 others think it's too overloaded due to
>> the
>> >>> overseer role, we could replace it with "mode" or something similar)
>> >>> -------------------------------------------
>> >>>
>> >>> To be explicit with the above definitions:
>> >>> 1) In SolrCloud, the roles of leaders and followers can dynamically
>> >> change
>> >>> based upon the status of the cluster. In standalone mode, they can be
>> >>> changed by manual intervention.
>> >>> 2) A leader does not have to have any followers (i.e. only one active
>> >>> replica)
>> >>> 3) Each shard always has one leader.
>> >>> 4) A follower can also pull updates from another follower instead of a
>> >>> leader (traditionally known as a REPEATER). A repeater is still a
>> >> follower,
>> >>> but would not be considered a leader because it can't process external
>> >>> updates.
>> >>> 5) A replica cannot be both a leader and a follower.
>> >>>
>> >>> In addition to the above roles, each replica can have a TYPE of one
>> of:
>> >>> 1) NRT - which can serve in the role of leader or follower
>> >>> 2) TLOG - which can only serve in the role of follower
>> >>> 3) PULL - which can only serve in the role of follower
>> >>>
>> >>> A replica's type may be changed automatically in the event that its
>> role
>> >>> changes.
>> >>>
>> >>> I think this terminology is consistent with the current
>> Leader/Follower
>> >>> usage while also being able to easily accomodate a rename of the
>> >> historical
>> >>> master/slave terminology without mental gymnastics or the
>> introduction or
>> >>> more cognitive load through new terminology. I think adopting the
>> >>> Primary/Replica terminology will be incredibly confusing given the
>> >> already
>> >>> specific and well established meaning of "replica" within Solr.
>> >>>
>> >>> All the Best,
>> >>>
>> >>> Trey Grainger
>> >>> Founder, Searchkernel
>> >>> https://searchkernel.com
>> >>>
>> >>>
>> >>>
>> >>> On Wed, Jun 17, 2020 at 3:38 PM Anshum Gupta <[hidden email]>
>> >> wrote:
>> >>>
>> >>>> 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 may require a non-trivial effort, a general consensus so
>> far
>> >>>> seems to be to start this process and switch over incrementally, if a
>> >>>> single change ends up being too big.
>> >>>>
>> >>>> There have been a lot of suggestions around what the new nomenclature
>> >> might
>> >>>> look like, a few people don’t want to overlap the naming here with
>> what
>> >>>> already exists in SolrCloud i.e. leader/follower.
>> >>>>
>> >>>> Primary/Replica was an option that was suggested based on what other
>> >>>> vendors are moving towards based on Wikipedia:
>> >>>> https://en.wikipedia.org/wiki/Master/slave_(technology)
>> >>>> , however there were concerns around the use of “replica” as that
>> >> denotes a
>> >>>> very specific concept in SolrCloud. Current terminology clearly
>> >>>> differentiates the use of the traditional replication model from
>> >> SolrCloud
>> >>>> and reusing the names would make it difficult for that to happen.
>> >>>>
>> >>>> There were similar concerns around using Leader/follower.
>> >>>>
>> >>>> Let’s continue this conversation here while making sure that we
>> converge
>> >>>> without much bike-shedding.
>> >>>>
>> >>>> -Anshum
>> >>>>
>> >>
>> >>
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of Master/Slave nomenclature in Solr

Walter Underwood
In reply to this post by Trey Grainger
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, but I can’t remember what terms I preferred because
that was ten years ago. A master gives commands. That isn’t how Solr
masters work. It is closer to how an NRT or TLOG leader works, actually.

A Solr master just sits there and waits for other nodes to copy the index.

wunder
Walter Underwood
[hidden email]
http://observer.wunderwood.org/  (my blog)

> On Jun 17, 2020, at 3:03 PM, Trey Grainger <[hidden email]> 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 the TYPE of a follower is PULL, then it does not.  In Standalone mode,
> the type of a (currently) master would be NRT, and the type of the
> (currently) slaves is always PULL.
>
> As such, this behavior is consistent across both SolrCloud and Standalone
> mode. It is true that Standalone mode does not currently have support for
> two of the replica TYPES that SolrCloud mode does, but I maintain that
> leader vs. follower behavior is inconsistent here.
>
> Trey Grainger
> Founder, Searchkernel
> https://searchkernel.com
>
>
>
> On Wed, Jun 17, 2020 at 5:41 PM Walter Underwood <[hidden email]>
> wrote:
>
>> 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 in my email inbox, publisher/subscriber is an excellent
>> choice.
>>
>> wunder
>> Walter Underwood
>> [hidden email]
>> http://observer.wunderwood.org/  (my blog)
>>
>>> On Jun 17, 2020, at 2:21 PM, Trey Grainger <[hidden email]> wrote:
>>>
>>> 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
>>> standalone mode you have to manage them manually (as is the case with
>> most
>>> things in SolrCloud vs. Standalone).
>>>
>>> My view is that having an entirely different set of terminology
>> describing
>>> the same thing is way more cognitive overhead than having consistent
>>> terminology.
>>>
>>> Trey Grainger
>>> Founder, Searchkernel
>>> https://searchkernel.com
>>>
>>> On Wed, Jun 17, 2020 at 4:50 PM Walter Underwood <[hidden email]>
>>> wrote:
>>>
>>>> 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 conversation.
>>>>
>>>> I like “principal”. How about “clone” for the slave role? That suggests
>>>> that
>>>> it does not accept updates and that it is loosely-coupled, only
>> depending
>>>> on the state of the no-longer-called-master.
>>>>
>>>> Chegg has five production Solr Cloud clusters and one production
>>>> master/slave
>>>> cluster, so this is not a hypothetical for us. We have 100+ Solr hosts
>> in
>>>> production.
>>>>
>>>> wunder
>>>> Walter Underwood
>>>> [hidden email]
>>>> http://observer.wunderwood.org/  (my blog)
>>>>
>>>>> On Jun 17, 2020, at 1:36 PM, Trey Grainger <[hidden email]> wrote:
>>>>>
>>>>> 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 others think it's too overloaded due to
>> the
>>>>> overseer role, we could replace it with "mode" or something similar)
>>>>> -------------------------------------------
>>>>>
>>>>> To be explicit with the above definitions:
>>>>> 1) In SolrCloud, the roles of leaders and followers can dynamically
>>>> change
>>>>> based upon the status of the cluster. In standalone mode, they can be
>>>>> changed by manual intervention.
>>>>> 2) A leader does not have to have any followers (i.e. only one active
>>>>> replica)
>>>>> 3) Each shard always has one leader.
>>>>> 4) A follower can also pull updates from another follower instead of a
>>>>> leader (traditionally known as a REPEATER). A repeater is still a
>>>> follower,
>>>>> but would not be considered a leader because it can't process external
>>>>> updates.
>>>>> 5) A replica cannot be both a leader and a follower.
>>>>>
>>>>> In addition to the above roles, each replica can have a TYPE of one of:
>>>>> 1) NRT - which can serve in the role of leader or follower
>>>>> 2) TLOG - which can only serve in the role of follower
>>>>> 3) PULL - which can only serve in the role of follower
>>>>>
>>>>> A replica's type may be changed automatically in the event that its
>> role
>>>>> changes.
>>>>>
>>>>> I think this terminology is consistent with the current Leader/Follower
>>>>> usage while also being able to easily accomodate a rename of the
>>>> historical
>>>>> master/slave terminology without mental gymnastics or the introduction
>> or
>>>>> more cognitive load through new terminology. I think adopting the
>>>>> Primary/Replica terminology will be incredibly confusing given the
>>>> already
>>>>> specific and well established meaning of "replica" within Solr.
>>>>>
>>>>> All the Best,
>>>>>
>>>>> Trey Grainger
>>>>> Founder, Searchkernel
>>>>> https://searchkernel.com
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Jun 17, 2020 at 3:38 PM Anshum Gupta <[hidden email]>
>>>> wrote:
>>>>>
>>>>>> 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 may require a non-trivial effort, a general consensus so
>> far
>>>>>> seems to be to start this process and switch over incrementally, if a
>>>>>> single change ends up being too big.
>>>>>>
>>>>>> There have been a lot of suggestions around what the new nomenclature
>>>> might
>>>>>> look like, a few people don’t want to overlap the naming here with
>> what
>>>>>> already exists in SolrCloud i.e. leader/follower.
>>>>>>
>>>>>> Primary/Replica was an option that was suggested based on what other
>>>>>> vendors are moving towards based on Wikipedia:
>>>>>> https://en.wikipedia.org/wiki/Master/slave_(technology)
>>>>>> , however there were concerns around the use of “replica” as that
>>>> denotes a
>>>>>> very specific concept in SolrCloud. Current terminology clearly
>>>>>> differentiates the use of the traditional replication model from
>>>> SolrCloud
>>>>>> and reusing the names would make it difficult for that to happen.
>>>>>>
>>>>>> There were similar concerns around using Leader/follower.
>>>>>>
>>>>>> Let’s continue this conversation here while making sure that we
>> converge
>>>>>> without much bike-shedding.
>>>>>>
>>>>>> -Anshum
>>>>>>
>>>>
>>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of Master/Slave nomenclature in Solr

Shawn Heisey-2
In reply to this post by Trey Grainger
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 as mistake to use any existing SolrCloud terminology for
non-cloud deployments, including the word "replica".  The top contenders
I have seen to replace master/slave in Solr are primary/secondary and
publisher/subscriber.

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.

Thanks,
Shawn
Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of Master/Slave nomenclature in Solr

Scott C. Cote
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 <[hidden email]> 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 as mistake to use any existing SolrCloud terminology for
non-cloud deployments, including the word "replica".  The top contenders
I have seen to replace master/slave in Solr are primary/secondary and
publisher/subscriber.

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.

Thanks,
Shawn



Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of Master/Slave nomenclature in Solr

Michael Gibney
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 individual roles in that cluster).

To take the "bikeshedding" metaphor in another direction, I'd submit
"hub/spoke"? It's a little overloaded, but afaict mainly in domains
other than cluster architecture. It's very usable as a pair; it
manages to convey the singular nature of the "hub" and the
equivalent/final nature of the "spokes" in a way that
"primary/secondary" doesn't really; and it avoids implying an active
role in cluster maintenance for the "hub" (cf. "publisher", which
could be misleading in this regard).

Michael

On Wed, Jun 17, 2020 at 9:12 PM Scott Cote <[hidden email]> wrote:

>
> 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 <[hidden email]> 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 as mistake to use any existing SolrCloud terminology for
> non-cloud deployments, including the word "replica".  The top contenders
> I have seen to replace master/slave in Solr are primary/secondary and
> publisher/subscriber.
>
> 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.
>
> Thanks,
> Shawn
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of Master/Slave nomenclature in Solr

Trey Grainger
In reply to this post by Shawn Heisey-2
@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 the same" as if it was an NRT replica when it gets
elected as leader. From the docs regarding TLog replicas: "This type of
replica maintains a transaction log but does not index document changes
locally... When this type of replica needs to update its index, it does so
by replicating the index from the leader... If it does become a leader, it
will behave the same as if it was a NRT type of replica."

The Tlog replicas are a bit of a red herring to the point I was making,
though, which is that Pull Replicas in SolrCloud mode and Slaves in
non-SolrCloud mode both just pull the index from the leader/master and as
opposed to updates being pushed the other way. As such, I don't see a
meaningful distinction between master/slave and leader/follower behavior in
non-SolrCloud mode vs. SolrCloud mode for the specific functionality we're
talking about renaming (Solr cores that pull indices from other Solr cores).

At any rate, this is not a hill I care to die on. My belief is that it's
better to have consistent terminology for what I see as essentially the
same functionality. I respect that others disagree and would rather
introduce new terminology to clearly distinguish between modes. Regardless
of the naming decided on, I'm in support of removing the master/slave
nomenclature.

Trey Grainger
Founder, Searchkernel
https://searchkernel.com

On Wed, Jun 17, 2020 at 7:00 PM Shawn Heisey <[hidden email]> 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 as mistake to use any existing SolrCloud terminology for
> non-cloud deployments, including the word "replica".  The top contenders
> I have seen to replace master/slave in Solr are primary/secondary and
> publisher/subscriber.
>
> 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.
>
> Thanks,
> Shawn
>
Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of Master/Slave nomenclature in Solr

Noble Paul നോബിള്‍  नोब्ळ्
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 <[hidden email]> 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 the same" as if it was an NRT replica when it gets
> elected as leader. From the docs regarding TLog replicas: "This type of
> replica maintains a transaction log but does not index document changes
> locally... When this type of replica needs to update its index, it does so
> by replicating the index from the leader... If it does become a leader, it
> will behave the same as if it was a NRT type of replica."
>
> The Tlog replicas are a bit of a red herring to the point I was making,
> though, which is that Pull Replicas in SolrCloud mode and Slaves in
> non-SolrCloud mode both just pull the index from the leader/master and as
> opposed to updates being pushed the other way. As such, I don't see a
> meaningful distinction between master/slave and leader/follower behavior in
> non-SolrCloud mode vs. SolrCloud mode for the specific functionality we're
> talking about renaming (Solr cores that pull indices from other Solr
> cores).
>
> At any rate, this is not a hill I care to die on. My belief is that it's
> better to have consistent terminology for what I see as essentially the
> same functionality. I respect that others disagree and would rather
> introduce new terminology to clearly distinguish between modes. Regardless
> of the naming decided on, I'm in support of removing the master/slave
> nomenclature.
>
> Trey Grainger
> Founder, Searchkernel
> https://searchkernel.com
>
> On Wed, Jun 17, 2020 at 7:00 PM Shawn Heisey <[hidden email]> 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 as mistake to use any existing SolrCloud terminology for
> > non-cloud deployments, including the word "replica".  The top contenders
> > I have seen to replace master/slave in Solr are primary/secondary and
> > publisher/subscriber.
> >
> > 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.
> >
> > Thanks,
> > Shawn
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of Master/Slave nomenclature in Solr

Walter Underwood
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
[hidden email]
http://observer.wunderwood.org/  (my blog)

> On Jun 17, 2020, at 9:36 PM, Noble Paul <[hidden email]> wrote:
>
> 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 <[hidden email]> 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 the same" as if it was an NRT replica when it gets
>> elected as leader. From the docs regarding TLog replicas: "This type of
>> replica maintains a transaction log but does not index document changes
>> locally... When this type of replica needs to update its index, it does so
>> by replicating the index from the leader... If it does become a leader, it
>> will behave the same as if it was a NRT type of replica."
>>
>> The Tlog replicas are a bit of a red herring to the point I was making,
>> though, which is that Pull Replicas in SolrCloud mode and Slaves in
>> non-SolrCloud mode both just pull the index from the leader/master and as
>> opposed to updates being pushed the other way. As such, I don't see a
>> meaningful distinction between master/slave and leader/follower behavior in
>> non-SolrCloud mode vs. SolrCloud mode for the specific functionality we're
>> talking about renaming (Solr cores that pull indices from other Solr
>> cores).
>>
>> At any rate, this is not a hill I care to die on. My belief is that it's
>> better to have consistent terminology for what I see as essentially the
>> same functionality. I respect that others disagree and would rather
>> introduce new terminology to clearly distinguish between modes. Regardless
>> of the naming decided on, I'm in support of removing the master/slave
>> nomenclature.
>>
>> Trey Grainger
>> Founder, Searchkernel
>> https://searchkernel.com
>>
>> On Wed, Jun 17, 2020 at 7:00 PM Shawn Heisey <[hidden email]> 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 as mistake to use any existing SolrCloud terminology for
>>> non-cloud deployments, including the word "replica".  The top contenders
>>> I have seen to replace master/slave in Solr are primary/secondary and
>>> publisher/subscriber.
>>>
>>> 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.
>>>
>>> Thanks,
>>> Shawn
>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of Master/Slave nomenclature in Solr

Walter Underwood
In reply to this post by Shawn Heisey-2
> On Jun 17, 2020, at 4:00 PM, Shawn Heisey <[hidden email]> 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
[hidden email]
http://observer.wunderwood.org/  (my blog)

Reply | Threaded
Open this post in threaded view
|

Re: Getting rid of Master/Slave nomenclature in Solr

Ilan Ginzburg
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 <[hidden email]> wrote:

> > On Jun 17, 2020, at 4:00 PM, Shawn Heisey <[hidden email]> 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
> [hidden email]
> http://observer.wunderwood.org/  (my blog)
>
>
1234