Skip to content
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

Closed
antirez opened this issue Sep 7, 2018 · 116 comments
Closed

Changing Redis master-slave replication terms with something else #5335

antirez opened this issue Sep 7, 2018 · 116 comments

Comments

@antirez
Copy link
Contributor

antirez commented Sep 7, 2018

(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:

  • PRs will no longer apply.
  • We have commands such as INFO and ROLE that reply with protocol containing the slave term.
  • There are 1500 occurrences inside the source code of the term slave.
  • People having private trees and merging things as needed will get a lot of problems.

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:

  1. Change the documentation to refer to master-replica. If we take master, which should not offend anybody in 2018 (next year we'll see...), at least there are less things to change. Replicas is very used and is also used inside Redis Cluster already.
  2. Alias SLAVEOF to REPLICAOF. You can still use SLAVEOF but now there is an option.
  3. Refer to REPLICAOF inside the documentation.
  4. Change the configuration directive as well from slaveof to replicaof.
  5. Leave all the internals as they are mentioning still slave at source level as a first step. Changing all those things now would be a big issue because we are at release candidate state, and there are too many pending PRs.
  6. Continue to reply with slave to INFO and ROLE, because this is a major breakage, for now.

Long term changes

  1. At some point in the future, write an alternative to INFO, since anyway INFO is not the future of Redis data gathering... It's too limited, provides too many info at once, clients need to have to parse it. We'll design a new command, and in the new command we'll not refer to slaves, but to replicas.
  2. When we are going to break a lot of things anyway, like for example with the inclusion of RESPv3, also change the 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".
  3. The first thing that we'll have to replace a lot of things internally, because of some technical reason, so that many PRs will not apply anyway, switch the variable and function names as well. However this is not acceptable to do as a change out of context, because it will cause really a lot of problems. We have to put this inside a much larger change somewhere.

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

@dvirsky
Copy link
Contributor

dvirsky commented Sep 7, 2018

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 slave replica. May I suggest FOLLOW <master>? it's not a perfect analogy but to me conveys less semantic ambiguity, which REPLICATE certainly does.

@antirez
Copy link
Contributor Author

antirez commented Sep 7, 2018

@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.

@NickCraver
Copy link

NickCraver commented Sep 7, 2018

I think REPLICAOF would to me be an easier migration and feels more right than REPLICATE - totally subjective though and curious what others 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.

@dvirsky
Copy link
Contributor

dvirsky commented Sep 7, 2018

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.

@dvirsky
Copy link
Contributor

dvirsky commented Sep 7, 2018

+1 for REPLICAOF

@mgravell
Copy link

mgravell commented Sep 7, 2018 via email

@antirez
Copy link
Contributor Author

antirez commented Sep 7, 2018

Indeed Marc, I think that ROLE could just return "master" and "replica" as well, exactly like we'll call them in other parts. However about the word master I want to be sure it is considered an acceptable replacement... If it's ok, I would love to at least take "master", because I find switching from "slave" to "replica" much simpler compared to calling the master something else, because when talking about Redis it was already in use to say replicas sometimes, but masters are always masters in the past documentation, in the way people talk when referring to Redis and so forth.

@antirez
Copy link
Contributor Author

antirez commented Sep 7, 2018

I'm updating the proposal with the suggestions so far.

@ChrisMcKee
Copy link

Seems the best solution for what is mostly an unnecessary situation. Not breaking the entire ecosystem is good and +1 for ReplicaOf.

@tongpu
Copy link

tongpu commented Sep 8, 2018

I'm with @NickCraver regarding replacing "master" with "primary". PostgreSQL has been using the same nomenclature for a long time now.

@mythz
Copy link

mythz commented Sep 8, 2018

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.

@simonw
Copy link

simonw commented Sep 8, 2018

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.

@mgravell
Copy link

mgravell commented Sep 8, 2018 via email

@antirez
Copy link
Contributor Author

antirez commented Sep 8, 2018

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.

@CBaquero
Copy link

CBaquero commented Sep 8, 2018

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.

@weq
Copy link

weq commented Sep 8, 2018

@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.

@Yiftach
Copy link
Collaborator

Yiftach commented Sep 8, 2018 via email

@mratsim
Copy link

mratsim commented Sep 8, 2018

Relevant issue in Django: django/django#2692
They changed to leader/follower.

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.

@antirez
Copy link
Contributor Author

antirez commented Sep 8, 2018

@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.

@sripathikrishnan
Copy link

A few more places where aliases may be needed:

  1. redis-cli has --slave mode, this can be easily changed to --replica mode.
  2. cluster replicas as an alias to cluster slaves.
  3. You may want to consider including additional fields in the info command. Currently, we have connected_slaves and slave0 through slaveN. Perhaps it makes sense to duplicate these fields as connected_replicas and replica0 through replicaN?
  4. Is there another term for role that is acceptable? For example, function or node_type? If so, perhaps we can add this new term in the info output, and also make a new alias for the role command?
  5. The cluster nodes command outputs a list of flags. One of the flags is slave. Perhaps we can add another replica as another flag in addition to slave? This doesn't break the format - a parser is expected to parse multiple flags for a node anyways. And eventually, the slave flag can be removed.

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.

@dmitrypol
Copy link

dmitrypol commented Sep 9, 2018

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).

@redis redis deleted a comment from flaneur2020 Sep 9, 2018
@redis redis deleted a comment from atolia Sep 9, 2018
@redis redis deleted a comment from dernasherbrezon Sep 9, 2018
@antirez
Copy link
Contributor Author

antirez commented Sep 9, 2018

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.

@alikon
Copy link

alikon commented Sep 9, 2018

I don’t believe that terminology out of context is offensive

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.
it seems that nowadays you cannot even use the name of some acient egypt gods to mark the intern codename relaeses like as has been done already for several years...

@tirkarthi
Copy link

tirkarthi commented Sep 9, 2018

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.

@houyujiangjun
Copy link

this is funny... when we use master/slave,we didn't mean 'the' master/slave.

@minzhang
Copy link

minzhang commented Sep 9, 2018

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:

  • Make multiple changes in one shot, reduce efforts
  • Guide new software development and help fix existing software
  • It's a quite educational thing for new programmers and engineers
  • It could be used when doing a PC censorship check. For example, Github could use it to scan repositories and pull those don't follow the rule down from public accessing. Enterprise private VCS can use it preventing check-in which contains certain words

@zhujinhe
Copy link

zhujinhe commented Sep 9, 2018

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.

@MrSorcus
Copy link

SJW is terrorists of 21 century.
Everyone who support they - terrorists too.

@byte777
Copy link

byte777 commented Sep 12, 2018

m

@HOHOHOTangoDown
Copy link

If you start using the word 'Replica', than my language will get a new anglicism. It's a trash for language to have 2 completely different meanings of one word, when one meaning is a native and another is not.

People who suggests such silly changes do not respect the right of other people to keep their mother tongue free from not-native words :-)

Of course, that's not a really important problem and is a joke, but changing widely used terminology is so silly.

indeed.

@it-nalon
Copy link

Buttana di Maria 'mmaculata, ma dicemu vero? C'a'mu a fari???

@Skogsfrae
Copy link

I'm a great BDSM lover and I would be really offended if the terminology had to be changed.

@nicStuff
Copy link

Those are just bullies. In this case, a Linus Torvalds - like response for these bullies would be much appreciated on the topic.

@d-lebed
Copy link

d-lebed commented Sep 12, 2018

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?

@atis2345
Copy link

What are you thinking about black color in CSS?

@uranpro
Copy link

uranpro commented Sep 12, 2018

Looks like we are SJW slaves

@pda11111
Copy link

With this change, you begin to infringe on the rights of BDSM lovers

@angganegara
Copy link

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.

@ip1981
Copy link

ip1981 commented Sep 12, 2018

Let's close Twitter instead.

@leonardfactory
Copy link

leonardfactory commented Sep 12, 2018

I think that even referring to background process as daemons might be offensive. What about divinities? We should change daemonize yes to divinize yes.

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..

@gqqnbig
Copy link

gqqnbig commented Sep 12, 2018

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.

@kasymovga
Copy link

I have nice idea.
How about replacing master/slave with man/woman or white/black?
Then it will turn really offensive and nobody will argue about master/slave.

@NeveHanter
Copy link

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.

@runningdogx
Copy link

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.

@sanicheev
Copy link

Do not support decisions/thoughts of stupid people please.

@destinywang
Copy link

I don't know why, it's just a technical term, we just have to care if it's practical.

@franklingu
Copy link

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?

@DzianisH
Copy link

Hi @NeveHanter ,
I'm just curious, how you got this numbers below, can you share it? It's possible to read all comments on GitHub and come up with some number, but i don't think it's possible on Twitter..

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

(sorry for spam, but this issue isn't technical discussion anymore :) )

@muse
Copy link

muse commented Sep 13, 2018

Ah... another solid piece of software succumbs to the SJW pressure, what a shame.

@ip1981
Copy link

ip1981 commented Sep 13, 2018

Redis is not a one hundred dollar bill, not everyone is going to like it.

@axvm
Copy link

axvm commented Sep 13, 2018

Tip for trolls:
Next level trolling is call to remove 'kill' cmd from anywhere in kernel ans OS because it looks like reference to genocide of humanity

@antirez
Copy link
Contributor Author

antirez commented Sep 13, 2018

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.

@antirez antirez closed this as completed Sep 13, 2018
@antirez
Copy link
Contributor Author

antirez commented Sep 13, 2018

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.

@axvm
Copy link

axvm commented Sep 13, 2018

Time to fork redis and revert those commits?

Voting for fork name via react:
👍- slaveredis
👎- masteredis
😄- slaverydb
❤️- bdsmdb

@ip1981
Copy link

ip1981 commented Sep 13, 2018

Time to fork redis and revert those commits?

Voting for fork name via react:

rediska ;)

@redis redis locked and limited conversation to collaborators Sep 13, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests