Replace master/slave with primary/secondary. The reasons include:

  1. This change has also already been evaluated and made by the Django community,
  2. The word "slave" has negative connotations (although this might or might not be relevant in the naming of a technical term) including multi-century history of slavery to benefit European colonial powers, prison laborers today forced to work in conditions at times resembling that slavery, young girls sold into sex slavery in many parts of the world today
  3. Somehow even this has a sexist angle: in the Django issue a devops person (presumedly female) complains about others making dominatrix jokes at her because of master/slave terminology


Xano’s picture

Assigned: Xano » Unassigned
Status: Active » Needs review
22.07 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch drupal_2275877_1.patch. Unable to apply patch. See the log in the details link for more information. View

Status: Needs review » Needs work

The last submitted patch, 1: drupal_2275877_1.patch, failed testing.

Les Lim’s picture

Status: Needs work » Needs review
50.4 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 71,947 pass(es). View

+1 for this. New patch for the post-PSR-4 core.

Xano’s picture

Thanks! Do you know why the new patch is 30KB larger than the original? Is it more than just a re-roll?

chx’s picture

I am against this. I have never seen such wording used. Here's,_Clustering,_and_Connection... PostgreSQL terminology, master-slave abound. Redis uses master-slave too. MSSQL uses a different word set but not "primary/replica" for sure. However, Active Directory (tangential but interesting) uses the words Master-Slave. Even MongoDB which does use the phrase "replica set" never uses the word "replica" for the slave: "Primary and master nodes are the nodes that can accept writes. / Secondary and slave nodes are read-only nodes that replicate from the primary."

Please tell me which databases uses "replica" for slave and which database are you running where "master" would not be understandable.

michaelfavia’s picture

Issue tags: +Needs upstream bugfix

I understand the sentiment but agree with chx here.

I started assembling the same list. This is about drupalisms and discoverability.

Damien Tournoud’s picture

The Primary/Secondary pair is increasingly common.

Mixologic’s picture

This is an opportunity for Drupal to promote inclusiveness, to be a part of a charge that demonstrates that amongst the plethora of stories about tech discrimination, we listen, and we react, and we try to change to make everybody feel welcome.

The first question is whether or not the terminology itself is actually loaded.

The vast majority of people involved might be inclined to say "no, its not loaded, it's just a name token that has taken on a whole new meaning, and in the context of servers and databases, it doesn't have a negative connotations. Its merely meant to express different roles". To those people I would say this: If you are not from a heritage that has ever experienced slavery, if you're not from a world where that name token could be hurled at you as an epithet, If you don't know what it's like to feel even the slightest twinge of uncomfortableness encountering those terms for the first time in a tech context, then your opinion cannot, and does not, invalidate those feelings in other people. If the first time somebody is learning about these terms feels like they are just bumping up against yet another example of institutionalized power, no amount of "yeah but its always been that way" is going to help alleviate those feelings.

So, if we have community members who express that this naming is problematic, and causes them consternation or stress, thats not up for debate. These terms cause them problems. Examples:

Therefore the choice is between making a change that will increase the inclusiveness of working with Drupal, or keeping things the way they are to maintain the status quo.

So the second question is if we *do* replace the terminology, then, *with what*?

This in another opportunity for better naming, primarily because the usage of Master and Slave actually mean two completely different things in different contexts. One context is a server or process who's responsibility is to direct, control, or delegate other servers/processes. The other is a canonical copy of a dataset/service, and a replication of that dataset/service.

Most usages that I see in drupal core are the latter. Many terms have been suggested - 'leader/follower', 'primary/replicant' etc. Personally I think that primary/replica works well for expressing what those are. Or maybe canonical/replica.


I have never seen such wording used.

Is orthogonal to the discussion. Its not about maintaining compatibility with historic naming. It's not about making a Drupalism (its a Djangoism too now) either. Its about pointing the way and being a leader in inclusiveness, and not being yet another tech project that says "We value diversity, just not if it means we'd have to have a minor setback in understandability/discoverability"

Other reading:

Les Lim’s picture

#8 is beautifully put.

Of course, the context is different. I don't think anyone is confused about the intent there. But context shouldn't be used a shield to protect us from the need to have consideration for fellow human beings.

For many, "master/slave" has an overriding context that cannot be unselected. And it's not even a proper metaphor for the thing we're describing. I don't ever want to have to say to anyone that it was more important, to our community, to continue using those imprecise terms, than it was to make you feel welcome.

This is a uniquely useful time to make a change like this: Drupal is still pre-beta, and Drupal following on the heels of Django might lend some momentum for other projects.

Les Lim’s picture

Re: #4, it looked like there were a number of instances of "slave" that were left in by the patch in #1, so I started from scratch with the latest 8.x commit.

forreststevens’s picture

Agree with #8 and wanted to voice my support for the patch. This is not even about being "politically correct," this is about being terminologically more accurate. And if you can make a change that also removes loaded meaning which makes a large number of people uneasy, thereby removing a barrier to inclusiveness, you really should get behind it. I think any argument to the contrary amounts to a, "Get of my lawn," mentality at best, or bigotry at worst.

michaelfavia’s picture

This isnt a new issue. To be totally clear here I'm not advocating that its a GOOD term. Far from it. It is purely a descriptive and currently necessary one. Anyone using the functionality in question will have to become comfortable with it because they'll be typing this all day in the system that this code actually references.


Simply put, this is about consistency and discoverability. It is the term that all of our supported RDBMs upstream use. If you're going to do a google search to figure out how to configure or use the new functionality you discovered you need to use those terms until they are changed upstream and documented for searching. How else will i make it to stack overflow!? ;) Try it for yourself. No results.

Similarly, Apache is an offensive name for a web server to some like the Chiefs name (US football team) are offensive here in the states. Male/female cable ends are equally offensive to some.

In short i totally understand and agree with you but this is what they are canonically called upstream. Lets fix it there and do the whole world a favor. Thats why i marked it as "needs upstream fix".

Since we're bikeshedding here may I suggest "publisher"/"subscriber" as thats a better description of the actual relationship between the two entities upstream. The "Master database maintains and publishes a transaction log that the "slave" actually subscribes to and runs on its own terms and abilities. Ill make the issue upstream ( if these terms sound reasonable to anyone else.

chx’s picture

Hey. This issue is a duplicate of . But also please let me know whether you plan to rename daemons and the terminate event.

sreynen’s picture

It's nice to see that no one here has expressed some of the more distasteful responses we see in the Django thread. Yay Drupal community!

If you're going to do a google search to figure out how to configure or use the new functionality you discovered you need to use those terms until they are changed upstream and documented for searching.

This seems like an important concern, but ...

Try it for yourself. No results.

I did try it myself and I got what seem like totally relevant results. I would say the results for "master/slave" searches are more useful currently (at least on MySQL), but it doesn't look like a big difference.

Also, it's worth asking why we're doing a Google search for this. Neither Drupal's code nor documentation currently explain anything about what to do in the database system. If the Drupal documentation took a more active role in explaining how to do database replication, we could also explain the terminology different databases use.

That terminology is already different from Drupal's terminology in many cases. I discovered while doing these searches that MongoDB already uses primary/replica terminology. And MSSQL uses "master/subordinate". And PostgreSQL uses "master/standby". I'm not sure how these all relate to Drupal's "master/slave" terminology, and Google searches fall short in clearing it up.

Outside MySQL, it's already a confusing mix of different terminologies that don't align with what Drupal uses. I suggest we use this change as an opportunity to clarify the varied terminology and how it relates to Drupal.

DamienMcKenna’s picture

Title: Replace master/slave with primary/replica » Replace "master/slave" terminology

+1 for #8. We just need to agree on replacement terms.

catch’s picture

@chx @michaelfavia like lots of other issues we can make the fix ourselves then file upstream issues that might or might not get fixed.

Primary/secondary sounds best to me, and looks like MongoDB is using that in their docs already.

In terms of actual code in core we only use this in the public API as db_query_slave() and db_ignore_slave(). Everything else is in event listeners/docs supporting that feature. The database api as such doesn't know about anything except connection keys and targets, this is a layer above that. The 'master' connection is already referred to as 'default', not master, so easy to just leave that. Overall it's not much to change.

catch’s picture

Also @chx in reply to #13.

1. #343414: Rename "master/slave" terminology to "client/server" is an issue against PIFR, not core, so this is emphatically not a duplicate.

2. While that issue got won't fixed in 2008, PIFR changed its terminology to server/client in December 2009 as part of a major overhaul, and now only has a few stray references to master/slave (mainly in updates). So it turns out they did find a better terminology after all. I updated the issue to mention this since I've seen that linked from elsewhere recently too.

btopro’s picture

terminology could definitely use a refresh, have had discussions before about how conversations about aspects of tech like this when amongst non-tech sector people could be (and i'm sure often is) misconstrued. Especially as tech propagates all aspects of life, we should seek to make discussions about it less a barrier of cryptic and dated words. Solid summary in #8 without coming across as over zealous and driving away people like me who traditional would go "whatever, words are words".

primary/replica works well for expressing what those are. Or maybe canonical/replica

Personally I like the canonical term to replace Master. primary is a namespace commonly used in everyday database development as far as primary / foreign key interactions. Replica doesn't have this name spacing mis-mash though. Failover, replica, something that expresses less critical; Alpha / Omega :)

chx’s picture

Status: Needs review » Closed (won't fix)
Issue tags: +trolling

Enough of this nonsense. I asked someone with better people skills at DrupalCon to intervene but that didn't happen.


We just moved or moving Drupal to be MySQL only in core and it is already primarily MySQL. The MySQL commands are MASTER/SLAVE. That's for technical.

As for community, I am closing this down because this is clearly not by people affected by slavery but rather people who can't sleep if they can't find a cause to fight for. It's an elaborate form of trolling but it's trolling nonetheless.

This is an opportunity for Drupal to promote inclusiveness,

It is not and I am closing this down exactly because of these words -- remember the old rule "we do not negotiate with terrorists" and that's exactly what happened here, someone tried to frame this conversation in a way that if you shut it down then you are against inclusiveness. That framing I refuse.

chx’s picture

One last comment before I unfollow because I know the rebels with a cause will reopen this for sure:

A) The number of people who will be affected by this is very small. Most people don't use database clusters. So while this will cause a lot of wasted time to get every piece of documentation updated at least the number of people who will get confused by the terminology will be small and those people will likely be knowledgeable enough to not confused badly. So the harm that will happen from this issue will be low. For Drupal 8, that's a praise.

B) Replica is not a word used by anyone for slave. No, not even MongoDB, read the docs again. What you wanted is primary/secondary.

klausi’s picture

Status: Closed (won't fix) » Active

Seems like the people that oppose this change are in the minority, so this should definitely stay open for further discussion.

+1 for replacing the master/slave terminology with primary/secondary.

duellj’s picture

Issue tags: -trolling

+1 for #8, very well said Mixologic! Whether we like it or not, this is an important issue and I'm sad to see all the attempts at derailment. Removing the "trolling" tag.

Crell’s picture

While chx's delivery needs work, he is correct that some of the comments in this thread take a very clear framing of "if you disagree then you're a bad person". That is no way to hold a conversation, it's a way to railroad. Come on Drupal, we can have an adult conversation without that sort of tactic.

So, if we have community members who express that this naming is problematic, and causes them consternation or stress

Do we? Honest question. So far this thread consists of a bunch of white men trying to extrapolate what someone else *would* think. (I cannot determine Les's ethnic background from his photo with certainty.) I do know there are two Jews in this thread (including myself), who have their own cultural history with slavery and discrimination. (That whole Exodus thing.)

We should not force a change on "might possibly could be offended". That way lies the hyper-sensitivity of the sort many complain is happening in various places; don't give them more fodder.

I also note that the problematic term, if any, is "slave", as "master" has a long history of usages that have nothing to do with the ownership of human beings. (Mastery of a craft, master of a ship, master in the martial arts sense, and various others.) Ironically, in code we already use "default" rather than master; master appears only in documentation, IIRC.

So is there an impetus for changing the terminology (and the documentation work that comes with it) that is not a hypothetical? And if so, what is the next-closest industry-common terminology? Those are the questions at hand.

(Incidentally, describing master/slave as "colonial" is both inaccurate and rather offensive in itself. Slavery as an institution existed nearly everywhere in the world amongst nearly every major culture. It was European colonialism in the 1800s that eventually ended it. I am not defending such an institution at all, just pointing out that implying it was a European colonial invention is completely and utterly false.)

chx’s picture

> And if so, what is the next-closest industry-common terminology?

Primary/secondary. This is the only thing I can answer with utter surety. Already Damien and catch agreed.

Mixologic’s picture

"if you disagree then you're a bad person"

It's not "you're a bad person" its more of a "how this makes people feel isn't subject to whether or not you agree that they should feel that way". If a blind user, using one of our sites told us that our front page made life hard on their screen reading software, there wouldn't be a debate about whether or not the problem exists. We would look at our code and see if we could address the issue.

Likewise if a person from a traditionally oppressed minority in our community tells us "master/slave makes me uncomfortable" We ought look at our code and see if we can address the issue. Also note that by "community" Im referring to the *tech* community, not just the drupal community. We're not only trying to get off the island, we're attempting to make our ports more welcoming to visitors as well.

Do we? Honest question

I've provided examples that show that this isn't just a bunch of white guys (who, incidentally are typically the gatekeepers for this type of change) pretending to do the right thing so we can pat ourselves on the back.

This was a coder of color who finds this terminology problematic:
This one was a female devop, who found the terminology problematic for sexism reasons:

Dig through that Django thread and you'll see plenty of examples of people who have found that term offensive. But I agree that we should invite more diverse voices into this thread. We may find that this is *indeed* some sort of self congratulatory attempt at inclusion that has no real impact. Or we may find that yeah, it would be nice if we didn't have those terms floating around, especially when there are more precise alternatives.

I also note that the problematic term, if any, is "slave", as "master" has a long history of usages that have nothing to do with the ownership of human beings.

100% agree. Thats why some of the nonsense over in that django thread about git having a master branch doesn't apply. Master is only a problematic term when used in conjunction with slave. On its own its not really an issue (or rather I am unaware of any examples of anybody claiming offense at it).

DamienMcKenna’s picture

@crell: Did you read the Django discussion on github? My involvement in this issue is based on the fact there were people in that discussion thanking them for the change, not because I felt like patting myself on the back.

Roy Batty’s picture

In the name of all replicants, I protest the use of the word 'replica' in such a demeaning way. You wouldn't believe what we've suffered already... I've... seen things you people wouldn't believe... Attack ships on fire off the shoulder of Orion. I watched c-beams glitter in the dark near the Tannhäuser Gate. All those... moments... will be lost in time, like tears... in... rain.

EclipseGc’s picture

And we're back to the 2 hard problems of programming...

In all fairness to everyone involved, nothing thus far has actually debunked michaelfavia's #12 in this thread. Do we want to be sensitive to as diverse a community as possible? Of course we do. Do we want to adopt that at the expense of technical discoverability and precise communication? I don't think we do. I don't really have a horse in this race one way or another, but this does seem like the sort of thing that requires an upstream patch to some degree (i.e. in MySQL/Maria). We support that by default now, and while I would generally agree that an implementation generic term is the better solution in most cases (technically) I'd also hate for someone to lose a lot of time staring at results that had nothing to do with what they actually NEED to accomplish. One of the things that makes APIs suck is not being able to discover the method you need to succeed. If I'm searching for master/slave database functions/methods and I can't find them, that's a problem.

Your zeal for the topic is laudable, but I suggest you take it upstream first. Anything else is just window-dressing. Asking for a technical change in Drupal to match MySQL afterwards should be a trivial issue (once we support that version). Also, it sounds like you might have a case for attempting to start a larger conversation in the database communities in general. Standardization of terminology, especially amongst SQL-like solutions seems like something worthwhile to strive toward.

On the flip side of this conversation, if we choose to make a change w/o upstream support, then we should likely choose the same notation as other systems before us. At least in this way we can begin to build a consensus of terminology outside the realm of those communities.


dww’s picture

Issue tags: -Needs upstream bugfix

+1 for renaming, for all the reasons I wrote at #343414: Rename "master/slave" terminology to "client/server" and what others have said (here and elsewhere). I don't think we need an upstream fix for this. Anyone who's trying to use Drupal in an environment with multiple DB servers is going to be able to figure out what "primary/secondary" means, even if that's not exactly the terminology their underlying DB implementation is using. And no offense to all the amazingly smart people who poured hundreds of hours of brilliant work into our DB abstraction layer, but it doesn't look much like the underlying DB, either, so I don't really buy the arguments in #12 or #28.

I don't see any comments in this thread even beginning to approach the level that chx and crell are portraying. No one is saying anything remotely close to "if you still want to call secondary database servers 'slaves' you're a racist pig". Everyone seems to be very tempered and civil in here. That's probably because I haven't commented, yet. ;)

I will say the implication/idea that only oppressed groups (historically, traditionally, or otherwise) should have to speak up about this sort of issue bothers me. Just like we can/should expect men to speak up about sexism and misogyny and not make it the sole responsibility of women to protest it or take offense, I'm proud that a handful of (so far) white men (myself included) are bothered by this and trying to do something about it. Hurray for allies. Surely we've all ready the First they came for the... poem by Niemöller, right? Of course the terminology in our database abstraction layer is nothing like the holocaust. That's not my point. I'm just talking about basic solidarity and why it's a good thing.

And yes, +1 to "slave" being the problem here, not "master" (although if we're going to change one, we might as well change both, since "master/secondary" seems weird). Indeed, slavery has been around a lot longer than colonialism, but let me say how terribly wrong "It was European colonialism in the 1800s that eventually ended it" is on so many levels. Probably Crell and I should hash that out over a beer sometime, not here. The component on this issue is "database system" not "people's history". :)

Phew, that was a more calm reply than I was expecting of myself. :)


chx’s picture

> That's not my point. I'm just talking about basic solidarity and why it's a good thing.

Basic solidarity with whom?

Note that #14 has its terms it all wrong; based on a cursory reading of manual pages. For example, MongoDB uses 'replica set' for all members but

Replica Set Primary
The primary is the only member of a replica set that accepts write operations.

Replica Set Secondary Members
Secondary members replicate the primary’s data set and accept read operations.

So it's primary/secondary. (DBRD also uses primary/secondary). Read #5 instead where I have more links on how PostgreSQL wiki is using mostly master/slave. But PostgreSQL is not really using anything because the core product doesn't support replication and the master/standby terminology is just a certain scenario.

While DBTNG might not look like MySQL you *will* need to explain that db_ignore_secondary() is going to ignore MySQL slaves because MySQL calls them one and then you have dreaded S word in core again. That can't be avoided.

ivanjaros’s picture


klausi’s picture

@chx: Solidarity with all people that take offense on the word "slave". Slavery carries the meaning of oppression and dehumanization, which evokes negative feelings in our community. Do we really have to force those people to speak up, should somebody tell a sad slavery story of their ancestors or something about how they are affected by human trafficking that still exists in this world? Really?

Did you consider that those people might not want to speak up? This thread had a "troll" tag at some point, and when you are already part of a marginalized group in our community you might want to avoid being tainted as troll. A lot of people in this thread can easily comment here from a safe privilege position, but others might consider it too risky. I'm disappointed that we want people to "prove" that they are offended, when already so many showed that they want this change and are offended.

So I think we have established that "slave" is a really shitty choice in naming secondary DB servers. Usually we don't wait for upstream fixes when that could take years and something causes discomfort in our software. We develop workarounds, we fix it at least on our end as good as we can. Meaning we do the rename and document it why we rather use something like primary/secondary instead of MySQL's offensive master/slave.

chx’s picture

Issue summary: View changes

Sure. Do it. Just use the right words which is primary/secondary. Updated the IS.

Mixologic’s picture

Issue summary: View changes

Reverted passive aggressive bullying.

Is there some reason you feel the need to resort to such tactics? It's toxic and alienating. The fact that many people do not hold your point of view on this issue, or *any other issue* does not give you the right to insult them. Calling people trolls because you don't agree with them isn't acceptable.

hatsch’s picture

first of all i find it great that issues like that can be discussed in a mostly respectful way on d.o.

for the issue itself i have a strong feeling that it is discussed in a very US and Euro centristic way.
like slavery has ended after Civil War or at least a little later, and is now only part of an ugly part of history.

while this might be true for a great portion of the world, there are still millions of people in working and living condition that are very close to slavery, and even legally it is globally abollished only since 2007

talking about diversity is always about the ifs and whens, so what if one of those women (because i belive they are mostly affected nowadays) can free herself, beeing smart and strong enough to find a new opportunity in website building.
will she find that terminology offensive?

the computer industry had it's start at a time when there was no such sensitivity in language and most new words and terminologies where characterized by white males. A lot of that we still carry with us, though we have a diferent kind of sensitivity in using language nowadays.

so come on opposers of this issue. it's not about abandoning a great feature ( in this case database replication ) but much more replacing an ancient terminology ( master/slave ) that we have carried around for a long time and we used to learn,
whith a self explaining, modern accurate and appropriate terminology that wil be intuitive understandable by anyone digging so deep that database repliation is needed.


both is easily understandable

ivanjaros’s picture

I think this kind of issue would be better resolved by public voting instead of few individuals taking over.

chx’s picture

Issue summary: View changes

I actually took the effort to read the github issue and there is a good reason to do this which I put in the IS. That makes sense.

donquixote’s picture

@chx (#37)
Isn't it interesting the comment you quote is not really about the comment author being offended by the term, but rather about fantasies triggered in the supposedly unaffected others, which then fire back at the comment author.

Applying that to the original argument: You don't need a specific ethnic background to be affected by this. All you need is some leftover stereotypes in your (sub)conscious, and the term can set some ugly thoughts in motion (maybe about a team member whose ethnic background you associate with slavery).

(And now I am out and leave this to others, who hopefully have put more thought into it than I have.)

EDIT: changed wording a bit.

catch’s picture


So far this thread consists of a bunch of white men

That is the main demographic of the vast majority of Drupal core issues/contributors so it is not really a surprise.

So is there an impetus for changing the terminology (and the documentation work that comes with it) that is not a hypothetical?

Repeating DamienMcKenna's question, did you read the Django PR? If you didn't, why are you posting long comments on this thread? If you did, why are you asking for non-hypotheticals when those have already been given?

For what it's worth I was originally directed to this issue by this tweet: (linked with permission).

(I cannot determine Les's ethnic background from his photo with certainty.

Please do not do this. My daughter is mixed race, superficially 'looks white', and at eight years old has already experienced racist bullying.

Appearance does not necessarily correlate with racial background. It does correspond to the likelihood of having racial slurs directed at you. Personally having had racial slurs directed at you is not something you should be required to prove to want to change some terminology though.

dww’s picture

Issue summary: View changes

Repairing the issue summary from chx's belittling changes from comment #37.

- Multi-century history of slavery to benefit European colonial powers? No problem.
- Prison laborers today forced to work in conditions at times resembling that slavery? No problem!
- Young girls sold into sex slavery in many parts of the world today? Still no problem!
- People who self-identify as a dominatrix for fun being offended? -- FINALLY, a good reason to change this!

:( @chx: we get the point. You're not in favor, you don't take this seriously, and you either don't care or are actively opposed. Fine. Duly noted. Now do yourself and the rest of us a favor and stop making yourself look like even more of a fool. As someone who's worked with you for close to 8 years on Drupal, supported you, at times defended you, I'm really disappointed. You're 100% free to not take this seriously, and no one is forcing you to work on this or spend time on it. You're choosing to do so, and you're making an ass of yourself. Please don't.


p.s. catch++, klausi++

Les Lim’s picture

Please do not do this. My daughter is mixed race, superficially 'looks white', and at eight years old has already experienced racist bullying.

I'm first-generation Indonesian American. When I was eight years old, I looked very Asian. I was already a nerd and math whiz, so I had that going against me already. I tried to ignore/dismiss the overt bullies, which was impossible, but at least it was a strategy.

I had no strategy for the other 95% of incidents that were more subtle: the questions about where I was from, how often I ate rice, whether I liked pizza, what's the square root of a billion. I didn't have a word for these interactions until college, when I learned about microaggressions, and I finally understood exactly why I never felt comfortable around new people.

So I try to be more sensitive about the microaggressions that other human beings face daily. I didn't want to express my racial bona fides before because I didn't want to misrepresent my support as being from a person of color. FWIW, my parents' lineage is Han Chinese, which, given the rich history of coolie labor, makes it possible and even likely that some distant relative worked as a de-facto slave. But I don't know for sure, and that's not where I'm coming from. I support the renaming as a member of the Drupal community.

webchick’s picture

This change is consistent with other similar English clean-ups we've done in the code base, e.g. to remove instances of "him/his" in favour of non-gender-specific pronouns. It's inline with our community values of inclusivity. I see no reason not to proceed here ("primary/secondary" has precedent, so let's go with that), especially given we have at least two core committers (myself and catch) in favour.

duellj’s picture

Status: Active » Needs review
Crell’s picture

+++ b/sites/default/default.settings.php
@@ -98,22 +98,22 @@
- * That is useful for master/slave replication, as Drupal may try to connect
- * to a slave server when appropriate and if one is not available will simply
- * fall back to the single master server.
+ * That is useful for primary/replica replication, as Drupal may try to connect
+ * to a replica server when appropriate and if one is not available will simply
+ * fall back to the single primary server.

In the interest of clarity we should probably note here, once, something like "(sometimes called master/slave replication)", as that is what the most commonly used database with Drupal still calls it. That provides a pointer to what to look for in MySQL documentation et al.

Also, the patch still says replica but it sounds like people want to use "Secondary" instead. I don't have a strong feeling between those two.

kwerey’s picture

To add another voice in... I reckon renaming it's a good move: it's getting rid of off-putting, dated terminology, and I reckon anyone who's putting enough time into development to set up database replication is gonna be able to find the documentation for it even if we change the name a bit.

In terms of names... I feel like Primary/Replica is maybe a little more clear in cases where you've got several replicas, but I think both suggestions work well.

duellj’s picture

52.85 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 71,924 pass(es). View

It seems like "secondary" has been given the thumbs up, so attached patch changes "replica" to "secondary" from #3.

mikey_p’s picture

I'd second Crell's suggestion in #44 that we could include a short note along the lines of "(commonly called master/slave in database server documentation)" and still clean up our code and terminology at the same time.

chx’s picture

Re #40 if i didn't take this seriously then why do you think I read the (long, obtuse, tiring) github issue? I do care. I do think the issue summary is all the wrong reasons and for those reasons I am against because I do believe it's made up bullshit. OTOH what I have fished out from that issue is a real, everyday problem that is worthy of addressing. At least it should be added back as an additional reason.

chx’s picture

Issue summary: View changes
Status: Needs review » Needs work
+ * Sets a session variable specifying the lag time for ignoring a secondary
+ * server.
-function db_ignore_slave() {
+function db_ignore_secondary() {
- * of potential slave databases.  Drupal will select one at random for a given
+ * of potential secondary databases

Both of these needs a reference to MySQL calling this a slave. You can't avoid the s word completely as long as MySQL calls it such.

Edit: pretty much as Crell said in #44 -- we just need to decide where to add comments.

EclipseGc’s picture

Yeah, in an attempt to be as unoffensive as possible, yet still communicate:

You can't ignore the word "slave". You cannot not say it. If you're going to change the method names then "slave" needs to continue being in the documentation, again for clarity sake. My general hesitance toward this entire issue is one of clarity for those not familiar with our community, and the fact that we are genuinely discussing up-and-renaming a common pattern deserves some documentation (at the very least). This is doubly true since it will be at odds with the default driver we ship in core (ironically I'd have less issue with this if we were still shipping mysql & postgresql, but even then they both call it master/slave and we aren't shipping postgres so... moot point).

Bottom line, if you're going to remove it from the function/method names, you have to elaborate on what it is in the docs. As I said earlier, I really feel like this is white washing a tomb so to speak. The greater problem still remains, and the people using these methods are likely to continue having to type the S word through db_query. Is this really the best technical solution available to us? I think the answer is pretty obviously "no" given our basic position, so we have to ask "Is this the best socio-political solution available to us?" If the answer to that is "yes", then by all means, let's change this. I just think you're going to end up talking about master/slave replication in the docs quite a bit to offset it and I wonder if that doesn't defeat the basic purpose.


Mixologic’s picture

It's been expressed that the technical impact on something like this is going to be minor:


The number of people who will be affected by this is very small. Most people don't use database clusters. So while this will cause a lot of wasted time to get every piece of documentation updated at least the number of people who will get confused by the terminology will be small and those people will likely be knowledgeable enough to not confused badly. So the harm that will happen from this issue will be low.


Anyone who's trying to use Drupal in an environment with multiple DB servers is going to be able to figure out what "primary/secondary" means, even if that's not exactly the terminology their underlying DB implementation is using.

Im not sure we'd need 'quite a bit' of documentation. Maybe a change record would do, or maybe just a comment. We know we cant eradicate every possible thing, and there'll have to be references, but doing the best we can is better than nothing at all, IMO.

catch’s picture

@EclipseGc there's still a decent chance we'll ship with postgres - depends entirely on the testing situation.

Crell’s picture

As I said above, a single mention in an "obvious" place is probably sufficient.

Mixologic’s picture

53.68 KB
51.13 KB
1.89 KB

Rerolled against c1a1735.

Added references per #44/#47/#49. default.settings.php seems like the most obvious place. Maybe an @see to this thread there too? I just put one on the function call @chx mentioned for dx explanations.

The do-not-test patch does not include the file renames, to allow for easier reviewing.

Mixologic’s picture

errant typo and accidental reversed patch in the do-not-test version.

David Strauss’s picture

I haven't read this entire thread, but I support changing from "master/slave" even just for reasons of clarity. The terms "master" and "slave" connote relative power and importance but not the system design. For the same reason, I do not support "primary/secondary."

I do support terminology that actually clarifies the architecture. In that sense, I would choose terms like "canonical" or "authoritative" and "replica" or "follower" to make it clear that one is the database server of record while the others are appropriate for less-authoritative needs or eventual promotion to being canonical.

ivanjaros’s picture

@David Straus: I too rather like replica instead of follower. Thugh I dislike both canonical and authoritative. Something like origin or source sounds better to me.

David Strauss’s picture

I dislike "source" because it implies that it's something that's merely read from, not written to. The same is true for "origin."

I'd be happy with "primary" and "replica," though. At least it'd be an improvement in the semantics of the latter.

webchick’s picture

Ok, since "primary" and "replica" are both more descriptive and also what Django went with, let's go with that. And now, I'm tearing down this bikeshed. :) Let's get this sucker in.

webchick’s picture

Title: Replace "master/slave" terminology » Replace "master/slave" terminology with "primary/replica"
webchick’s picture

Oh, and +1 also for the one-liner in settings.php to refer to the "traditional" names in case people are having a problem grokking. I think that's a sensible balance between using more inclusive terminology and not leaving users stranded.

Mixologic’s picture

Status: Needs work » Needs review
50.4 KB
50.27 KB
52.81 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 72,288 pass(es). View

Here's an updated patch with updated terminology.

Crell’s picture

+++ b/sites/default/default.settings.php
@@ -98,22 +98,23 @@
+ * fall back to the single primary server. The terms primary/replica are
+ * commonly referred to as master/slave in database server documentation.

From the discussion above it sounds like "sometimes" would be more accurate than "commonly". That's a nitpick, though. (Here and the other place it's mentioned.) Also, perhaps put that sentence in parentheses? I feel like it flows better that way, but I'm a fan of parentheticals. :-)

LewisNyman’s picture

From the discussion above it sounds like "sometimes" would be more accurate than "commonly".

How about “traditionally” or “previously”?

catch’s picture

'Traditionally' works.

Mixologic’s picture

841 bytes
50.28 KB
52.81 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 72,500 pass(es). View

Cools. Here's the same stuff, rebased to e4802af, with the suggested parentheticals and "traditional"

Crell’s picture

Status: Needs review » Needs work

You forgot to update the docblock on db_ignore_[replica|slave]. I think this is RTBC once that's updated.

Mixologic’s picture

639 bytes
50.28 KB
52.82 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 72,499 pass(es). View

Whoops. On the bright side I've gotten really comfortable with doing interactive rebases to keep the file rename commits on top of the code commits for making all the diffs.

duellj’s picture

Status: Needs work » Needs review

Setting to needs review for testbot

Crell’s picture

Status: Needs review » Reviewed & tested by the community

Ah, side benefits.

Unless the bot objects for some strange reason...

chx’s picture

Deleted another rant.

David Strauss’s picture

"Support for primary/replica replication" is redundant. How about "Support for primary/replica infrastructure" or maybe "split primary/replica querying."

chx’s picture

Status: Reviewed & tested by the community » Needs work

I won't let this go.

catch, Damien Tournoud, klausi and me have argued for the word "secondary".

I have challenged people (whom? I don't even see that clearly, I think Mixologic was the only one clearly arguing for it) to show me any database that uses the world "replica" in the sense "slave" or "secondary" is used. This challenge was not met. No, MongoDB doesn't, read again, I already linked here and explained that "replica set" contains a primary, any number of secondaries (and you need an arbiter as well but that's not relevant here).

Until such a challenge is met this issue is CNW given the overwhelming support for "secondary".

Let me also ask: what sort of process do we have when the preference of two database maintainers and the release manager can be overridden without any backing?

Edit: I see webchick decided for this word. With all due respect to her, she is wrong in this one -- I see no reasoning why she did.

Mixologic’s picture

Status: Needs work » Reviewed & tested by the community

@chx: I don't have any concern one way or the other as to what it gets named. Webchick said she's tearing down the bikeshed, and thats exactly what it is IMO. The terminology that we select is not intended to have any parity whatsoever with any upstream database. If django is using replica, we can use it too. The word replica isn't obtuse or obscure and anybody who's unlocked the 'manage multiple databases' achievement is certainly able to understand what replica means. The term used to describe the whole concept in the database world is Master-Slave Replication.

Given that, Its unclear why your "challenge" even needs to be met to move forward here, and seems like an artificial constraint.

David Strauss’s picture

> Edit: I see webchick decided for this word. With all due respect to her, she is wrong in this one -- I see no reasoning why she did.

Her reasoning is the same as mine: "Replica" is actually descriptive. "Secondary" isn't. "Secondary" suggests nothing about the purpose or design of the non-primary instance. "Replica" suggests that it's very similar to the primary instance but may have imperfections.

> I have challenged people (whom? I don't even see that clearly, I think Mixologic was the only one clearly arguing for it) to show me any database that uses the world "replica" in the sense "slave" or "secondary" is used.

Your challenge is artificially restricted to database servers themselves. The important thing is whether people in software and infrastructure engineering use the term "replica" as we're discussing here.

Such use is broad. IBM Rational ClearQuest [1], Microsoft System Center [2], Engine Yard [3], Django [4], and AWS [5] all use "replica" as a noun to refer to a database holding a continuously updated clone of the primary server's data for availability or scaling purposes. In the case of Amazon's RDS, it's even a MySQL "slave" in the background. Even ACM's publications [6] use the term as we're discussing.


chx’s picture

See? Now we are talking. That was a useful post, thanks David!

  • Commit b1b3b2b on 8.x by webchick:
    Issue #2275877 by Mixologic, duellj, Les Lim, Xano, David Strauss:...
webchick’s picture

Status: Reviewed & tested by the community » Fixed

Ok, sounds like we're in alignment.

Committed and pushed to 8.x. Thanks!

Also created a change notice here: Might still need some adjustment.

catch’s picture

Yeah I'm fine with using replica. The only reason I preferred secondary was because of db_ignore_slave/replica/secondary() - however I realised that it's the overall function name that's not obvious, not just what we call the replica, so I've opened #2286235: Change db_ignore_replica() to refer to the primary/default target as a follow-up.

j0rd’s picture

Has anyone asked Khaleesi what she thinks we should do? Perhaps she would have some words of wisdom.

chx’s picture

I want to clarify that I don't think the people who raised this issue or discussed it on twitter are 'trolls'". Rather that I consider the change itself to not be relevant (and if relevant, should be made upstream first). While I objected to this issue, I do care about inclusivity in the community and was not trying to react against changes that would make the community more inclusive, just in this case I didn't think the change would.

Also, while Larry agreed with me, I think guessing the race of people based on their avatars actually goes against that very inclusiveness.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

chx’s picture

For posterity: along with (do not be fooled with that draft not becoming the CoC, it certainly survived just not in the open) this issue shows how the Drupal thought police was formed. Yes, I am aware of the relevant comments to "thought police" in no matter how many years have passed since that was posted I still remember, it has been an incredibly important and useful blog post and yard stick when we actually cared and educated each other on these matters instead of snitching and lying to a secretive cabal. Back when there was a we. Now you actually have more process and community input these days into placing a space in the code base than how the CWG deals with community members.

DamienMcKenna’s picture

I've locked this issue lest we spiral into further arguments and name-calling.