-
Notifications
You must be signed in to change notification settings - Fork 23.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changing Redis master-slave replication terms with something else #5335
Comments
Hi Salvatore. Thanks for this post. This does make sense. One technical note - I'm not sure REPLICATE is a good alternative to SLAVEOF. It implies (at least to me) to mean what the master is doing, not the |
@dvirsky thanks for commenting. Yep I understand it may create issues, could be really cool to have the config directive that is similar to the name we give to replicas. |
I think I wonder if "master" should become "primary" for the sake of a clean break on both terms. I think it'd be much easier to explain to someone. For what it's worth, we use master and primary interchangeably when describing our topology all the time. |
In recorded media Master also means the single source of truth, and there is no term for slave, and I doubt anyone has any problem with it. So I think keeping Master should be fine. |
+1 for REPLICAOF |
I would suggest that if the "role" change is going to happen, the
nomenclature for that (i.e. what terms "role"-like-thing would return in
the future for what is currently master/slave) should be nailed down now
too - *even if* the change only happens in RESP vNext.
…On Fri, 7 Sep 2018, 21:42 Dvir Volk, ***@***.***> wrote:
+1 for REPLICAOF
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#5335 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AABDsGAjLBTwOYoYBUQac2erfOP-EfeCks5uYtolgaJpZM4Wfa-2>
.
|
Indeed Marc, I think that |
I'm updating the proposal with the suggestions so far. |
Seems the best solution for what is mostly an unnecessary situation. Not breaking the entire ecosystem is good and +1 for ReplicaOf. |
I'm with @NickCraver regarding replacing "master" with "primary". PostgreSQL has been using the same nomenclature for a long time now. |
Solid plan, seems the least invasive path forward that mitigates breaking existing clients/systems. You can always do more later so makes sense to start with the least disruptive change to fix the problematic term first. I'm fine with either "master" or "primary" but RESPv3 only gives you 1 chance at a breaking window so I'm more inclined to change it to "primary" there as well. It's minimal work for clients to handle both when adding support for RESPv3 and it's going to be prohibitively disruptive to change it later. (IMO "master" can be a more cosmetic change i.e. retain references in source but add aliases to "primary" and change defaults later in docs/config after RESPv3 becomes standard). Over time the master/replica combo is going to sound unfamiliar and unique to Redis as I'm expecting everyone else to move to primary/replica to describe that relationship, so for the sake improved clarity/familiarity for future readers it might make sense that RESPv3 adopts both terms. But if you think the risk of breaking the ecosystem is too great then we should retain it, but whatever terms RESPv3 goes with I think should be retained permanently. |
Personally I like primary/replica - it's a much more accurate metaphor than master/replica in my opinion. And using the same terminology as PostgreSQL is a big positive. |
My main thought on "primary" => "replica" is that it makes my brain itch -
"primary" => "secondary", not "replica".
I'm perfectly OK with "master" in the context "original / definitive
version" - think: audio/video recordings and the "master reel".
master => replica seems fine
…On Sat, 8 Sep 2018, 09:19 Simon Willison, ***@***.***> wrote:
Personally I like primary/replica - it's a much more accurate metaphor
than master/replica in my opinion. And using the same terminology as
PostgreSQL is a big positive.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#5335 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AABDsNaB_jqo4oEn128hoQy_KrEX10bgks5uY32EgaJpZM4Wfa-2>
.
|
Folks I'm not interested in picking the most appropriate terminology here, but the one that is the minimum delta compared to what we are used, without being offensive to certain groups at the same time. If "master-replica" is not offensive, this is what I think we should use, because "primary" is really very far from historical terminology and to what we use in Redis-land. Master & replicas we already use, so I would stick with them if master is ok. To clarify, I don't think that the semantical meaning is actually useful. Master-slave is totally bad at describing the two roles, but everybody understand what it is about, because in replication context you give to the words such meaning. However @mythz has a point IMHO in that we should make totally sure that what we pick will not be sensed as wrong in a few years. But honestly this could happen anyway given the environment that is shaping out there. |
I can't even imagine the amount of implications of the name change so I totally understand the pragmatic approach of keeping master and only renaming the slave. Anyway I went to one textbook I trust (Distributed Systems for System Architects. Authors: Veríssimo, Paulo, Rodrigues, Luís) and that was at hand and reminded myself of the different terminologies. In replication there is a division between systems following active replication (where several replicas of the same state machine execute the same sequence of actions, often disseminated by atomic multicast) and passive replication (only one replica executes commands and others periodically catch up). I guess the open source Redis case matches more the passive replication category, so lets look at the terminology there: The special (elected or pre-configured) replica that executes the commands/actions first is called primary and the other replicas can be called secondary or backup. This leads to the terminology pairs primary/backup or primary/secondary. Now I also realize that this terminology is better that master/slave because both backup and secondary terms convey more the notion that those replicas can in the future replace the role of the primary. To me the term replica does not equate immediately with something being a secondary to another entity. Also in geo-replicated settings, and others, we can have multiple active replicas and I believe the common term for this is still multi-master. The open source Redis, I believe, will fall in the single-master category. Given all this, and given that there is a clear advantage in keeping master, maybe master/backup or master/secondary would be interesting options to consider in place of master/replica. |
@mgravell removed my post to not offend any more people. Time to redirect your internet hero skills elsewhere. Too much care bear in this repo for my taste. |
Salvatore re ETA, if you believe we need to do this change, and put aside
the exact terminologies at the moment, why not just do everything
with RESPv3 release and avoid this chaos right now ?
I see the following benefits doing it that way:
1. We avoid the intermediate solution, which will create a lot of confusion
and still tons of work
2. We are responsive to community requests, and I tend to believe most
people will understand that it's not a simple thing to do and requires a
lot of code work (server, client) and documentation changes
3. It will probably make the RESPv3 release sooner
My 2 cents
…On Sat, Sep 8, 2018 at 9:58 PM Raymond Siring ***@***.***> wrote:
@mgravell <https://github.com/mgravell> removed my post to not offend any
more people. Time to redirect your internet hero skills elsewhere. Too much
care bear in this repo for my taste.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#5335 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABPklgV4I6VXKq8iGfkMYUvgCflS9v6nks5uZBNrgaJpZM4Wfa-2>
.
--
Yiftach Shoolman
+972-54-7634621
|
Relevant issue in Django: django/django#2692 Please do not rush this and consider that Redis is used in many companies, by many consultants, trainers and users and that there is a consensus and a context to the use of master/slave just like there is to the use of various animal names. Twitter users will just add a checkmark on their scoreboards and move on to a new target while your community will be left to deal with the aftermath. |
@Yiftach I want to proceed with the first part, which should not be a huge amount of work at all, to give a first signal, because implementing the rest may likely take years... I don't want to do any ETA in the phase two. We'll slowly deprecate the "slave" term from the API and source code, but always when we have also a change at hand to justify it. RESPv3 for instance is the moment to fix ROLE, while for the INFO reply, we'll have to wait the introduction of an alternative to the INFO command. For removing it from the source code, it will be a very gradual process where from time to time a file or a part of a file is changed, so that we don't break a lot of PRs in the process. And so forth... So it's better to act right now with the part that gives a signal of change. This alone will change the documentation, that is the most exposed part of Redis, and will add the aliases, not breaking any compatibility, so it is definitely a doable stage-1. For all the rest, the community will have to understand that it is a big change that will require N years. |
A few more places where aliases may be needed:
With a little duplication and aliases, and assuming the changes are backported - clients can start using the new terms right away. Then a few releases later, the older terms can be dropped - perhaps when RESPv3 is introduced. |
I like idea of striking middle ground (creating replica/replicaof alias) but keeping things backwards compatible. But the time spent on this means less time to work on other features (like Streams or module port of Disque). |
I just removed a few sarcastic comments. Please don't post any more of comments of this kind and only comment if you got some idea to contribute to the issue. |
especially if the context is the software how much it will costs this change ? for the sake of ? kindly suggest you to act like a benevolent dictator (here we are again), so please consider my words in the software context i strongly think that "time" should be spent in a more usefull way my 2eurocent, p.s. |
Just as a headsup it's on the front page of r/programming and might make way for unwanted comments. Post Thanks much for Redis and all your efforts throughout the years. |
this is funny... when we use master/slave,we didn't mean 'the' master/slave. |
Can we engineers work with activists to create of a black word list by reviewing computer engineering terms currently used, before just made a change on 'slave' in Redis? Such a list will be quite useful:
|
I (probably other people also) have some scripts that reference the 'master/slave' keywords. My suggestion is that anyone who is not happy with these terms can fork this project, change the terms whatever they like and leave the master/slave keywords of this project alone. |
SJW is terrorists of 21 century. |
m |
indeed. |
Buttana di Maria 'mmaculata, ma dicemu vero? C'a'mu a fari??? |
I'm a great BDSM lover and I would be really offended if the terminology had to be changed. |
Those are just bullies. In this case, a Linus Torvalds - like response for these bullies would be much appreciated on the topic. |
What is this discussion about? When people are slaves that's bad. When Redis process is slave that's… what? Do you think it suffers? Should we start pay it some money for it's work? What will be changed if we will call it with some other word? |
What are you thinking about |
Looks like we are SJW slaves |
With this change, you begin to infringe on the rights of BDSM lovers |
If you're affected by the Twitter poll, know that it's possible that the majority of Redis users were just busy with their jobs and unaware of said poll, while those so called "activist" got nothing better to do and teaming up in arms to vote for the changes. |
Let's close Twitter instead. |
I think that even referring to background process as Sarcasm aside, I think master/slave terms are pretty common and well known in the industry and no one in the field may even think about slavery when talking about it. Alias could be ok, but dropping them.. |
I think the change request is ridiculous and doesn't worth the effort at all. The master-slave terminology rooted back in early computer science history, as seen in https://en.m.wikipedia.org/wiki/Master/slave_(technology). It's ridiculous for people to connect slavery in the architecture context to the one in society. The best way to fix the so-called political incorrectness is to fix these people's minds, instead of changing Redis code. I totally support the activitists maintain their own version of Redis, change the terminology however they like. The burden of appeasing the activitists should be on the activitists themselves. |
I have nice idea. |
That's funny that 72% of people voting here in the opening message disagree with the change and 53% of the people on Twitter agree, maybe that's problem's with Twitter's pool anonymity or mostly toxic culture, I'm not sure... But I think people here compared to the people on Twitter want backward compatibility and no terminology confusion more instead of bringing unnecessary name changes which in the end brings only the problems in every integration area starting from source code compatibility, auxiliary scripts and ending on software made to inter-operate with the Redis, i.e. Ansible, python's redis, etc.. I'm not even mentioning confusion it will bring after so many years of using different naming used in nearly every piece of software, master/slave in USB and all the books existing, maybe they will even burn the books just because there's such terminology? Anyway, it's FOSS, they are all free to fork the source code and make their version without offensive terminology, so don't force yourself and these name changes just because some minority wants it, don't break like people from Django, Drupal, Facebook, Python who make the changes just because couple of some people had their different non-constructive thoughts. |
I find it offensive that Redis has decided to appropriate replicant culture by using the term "replica". Why is "slave" any more offensive than "master", anyway? The "master" is the source of the problem, right? This is absurd. SJWs need to grow up, but they can't because their parents, colleges, and even some workplaces now are coddling them. See Jonathan Haidt's new book, for instance. This whole situation is pathetic. |
Do not support decisions/thoughts of stupid people please. |
I don't know why, it's just a technical term, we just have to care if it's practical. |
The whole idea of relating technical terms to politics or social justice is absurd! If people use that word to insult someone, then you should say that is not allowed; if we did not mean that at all and before some SJWs jump out and say this is wrong nobody actually realizes that, I do not see any reason why anything has to be changed. I wonder what is the next step then if this got changed as well -- maybe uWSGI needs to stop using emperor in their documentation as well. Those algorithms like Raft or Paxos need to change to be more diplomatic? |
Hi @NeveHanter ,
(sorry for spam, but this issue isn't technical discussion anymore :) ) |
Ah... another solid piece of software succumbs to the SJW pressure, what a shame. |
Redis is not a one hundred dollar bill, not everyone is going to like it. |
Tip for trolls: |
I finished the word change, closing this issue. I see that people opposing the change are exactly as extremist as people very vocal about doing the change. Ok, I'm part of the persons that say that this is probably totally useless, create confusion and so forth, and that it is mostly an American issue. However trust me that I received many emails and messages on Twitter even from very valuable members, including ones that wrote non trivial code in the core of Redis, that said "this is a good move", so our sensibility, of people that do not care and believe this is bullshit, is not the only possible sensibility and opinion. And there are at least ,let's say, 10% of people that are not activist and are big Redis users that feel like this is the direction. Given that changing the word in a backward compatible manner creates very little troubles to the other 90%, I feel like in that case, that minority needed to be taken care of. So... that's all, and we can move forward. |
Another thing that many of you did not understand is that I would never do that change if it was just for the very vocal activists and their aggressiveness. The point is the relatively silent persons that at this point developed such sensibility and are member of our communities. So if you say "Oh that SWJ are ruining the world as they ruined Redis!" this is not history, it is not how things happened this time around. |
Time to fork redis and revert those commits? Voting for fork name via react: |
rediska ;) |
(Note: I'll update the description here as the discussion evolves)
Background
It was asked multiple times by activists in the area of inclusiveness for Redis to migrate to a different terminology than master-slave, specifically one that has no reference to slavery. Personally I do not consider the effort worthwhile, but this is my personal opinion. On the other hand different Twitter threads, especially an exchange with DHH, together with many accounts of people starting to suggest to never use Redis again, made me reflecting about a few things. Specifically I think that it could be a problem for engineers just willing to use Redis because they believe is the right too for the job, to apply it in certain workplaces, because the terminology used in Redis may be a problem. I don't want, as a result of my ideas, to create problems to the Redis community.
At the same time once I started to be more open to the possibility of renaming such terms, I started to receive private complains from multiple people that contribute to the project for years, that are annoyed by the fact we'll have to do work that will not change the system in any way, and that will be costly, create compatibility issues.
My idea is to find a middle ground between all those things, because there are multiple issues caused by the change of terminology:
INFO
andROLE
that reply with protocol containing the slave term.So this change can potentially create a lot of issues. Moreover many folks on Twitter do not understand the Redis culture of backward compatibility. Redis 5 that is now release candidate is backward compatible with the first stable version of Redis released, to the point it's a drop in replacement. This culture traditionally made sure that upgrade operations are simple, there is no useless work to do in the client side, and so forth. This is something big to consider.
Possible soltuion
Yet I want to give a signal, because in a Twitter pool I started too many people asked for the terminology to be changed. While I handle the Redis community, I do not want to be its king, I need to serve people here. A signal however does not need to create a number of problems across the community, so this is what I propose to do.
Short term changes
To start we do the following:
slaveof
toreplicaof
.slave
to INFO and ROLE, because this is a major breakage, for now.Long term changes
ROLE
command to output replica instead of slave. If clients detect it's a RESPv3 server, they now that ROLE will reply differently, that is, instead of "slave" it will reply with "replica".We'll provide no ETA for the second step, and I hope the community will understand our technical issues here. However I hope that people will appreciate that at least somebody is listening here. Certain people demanding this change are vocal and hostile, but I saw a huge amount of people on Twitter just asking peacefully to see some improvement. One thing is for sure: the master-slave terminology is not going to be used in the future, so let's make this change together, and move forward to our actual work, that is, to make Redis better and available.
Please provide your POV if you are among the contributors of Redis
I know this may seem gross, but I would like most comments here to be provided by people that did something in Redis-land in the latest few years. People sending PRs, opening issues, writing a client library, using Redis at scale and provided hints regularly, and so forth, don't just comment if you are a casual Github user jumping here to say "change it!" or "don't change it". This will just create noise. Thanks.
Off topic and offensive comments will be removed
The text was updated successfully, but these errors were encountered: