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
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
> Alt F: "Managed Clustering" vs. "Manual Clustering" Mode
I don’t view a set of M/S nodes as «cluster» mode, since Solr is really not
doing any cluster features. It’s like spinning up two standalone MySql servers
with a cron job that runs a SQL from one to the other to update itself. It
Another alternative for master-slave nodes might be parent-child nodes.
This was adopted in Python too afaik.
On Fri, Jun 19, 2020, 2:07 AM gnandre wrote:
> What about blacklist and whitelist for shards? May I suggest blocklist and
> safelist?
>
> On Fri, Jun 19, 2020, 1:45 AM Thomas Corthals
What about blacklist and whitelist for shards? May I suggest blocklist and
safelist?
On Fri, Jun 19, 2020, 1:45 AM Thomas Corthals wrote:
> Since "overseer" is also problematic, I'd like to propose "orchestrator" as
> an alternative.
>
> Thomas
>
> Op vr 19 jun. 2020 04:34 schreef Walter
Since "overseer" is also problematic, I'd like to propose "orchestrator" as
an alternative.
Thomas
Op vr 19 jun. 2020 04:34 schreef Walter Underwood :
> We don’t get to decide whether “master” is a problem. The rest of the world
> has already decided that it is a problem.
>
> Our task is to
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
I sometimes describe them as tightly-coupled and loosely-coupled. There is a
vast
difference in the amount of shared state in the two kinds of clusters. Old
school
clusters are essentially a REST system. The primary server knows nothing
about the leeches. The replication only assumes that the
>
> Let’s instead find a new good name for the cluster type. Standalone kind
> of works
> for me, but I see it can be confused with single-node.
Yeah, I've typically referred to it as "standalone", but I don't think it's
descriptive enough. I can see why some people have been calling it
We don’t get to decide whether “master” is a problem. The rest of the world
has already decided that it is a problem.
Our task is to replace the terms “master” and “slave” in Solr.
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/ (my blog)
> On Jun 18, 2020, at
I agree with Phill, Noble and Ilan above. The problematic term is "slave"
(not master) which I am all for changing if it causes less regression than
removing BOTH master and slave. Since some people have pointed out Github
changing the "master" terminology, in my personal opinion, it was not a
Master - Worker
Master - Peon
Master - Helper
Master - Servant
The term that is not wanted is “slave’. The term “master” is not a problem IMO.
> On Jun 18, 2020, at 3:59 PM, Jan Høydahl wrote:
>
> I support Mike Drob and Trey Grainger. We shuold re-use the leader/replica
> terminology from
I support Mike Drob and Trey Grainger. We shuold re-use the leader/replica
terminology from Cloud. Even if you hand-configure a master/slave cluster
and orchestrate what doc goes to which node/shard, and hand-code your shards
parameter, you will still have a cluster where you’d send updates to the
35 matches
Mail list logo
