couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noah Slater (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-2248) Replace "master" and "slave" terminology
Date Wed, 28 May 2014 00:52:02 GMT


Noah Slater commented on COUCHDB-2248:

> "master/slave" is the simplest and most descriptive term to use to describe that couchdb
can be used in a master/slave setup

This is tautological. What does master/slave communicate that master/replica does not?

The meaning might be plain. That's not what we're debating. We're debating whether it makes
sense to pick a different word. We have two arguments for doing so. One is social, and the
other is logical. Master/slave is misapplied to database tech. Master in the sense of a master
record is a much better fits. And you make copies, clones, or replicas of master records.

> I believe that is the intended functionality of a slave database in a master/slave setup,
it serves as a backup of the master

This is not the case where a a read replica is being used to take reads away from a master.

>  I remain -1 on changing away from the straightforward use of "master/slave" to something
that is less clear

"Replica" is in clear use throughout the industry. Google search "replica database" or "read
replica" (with quotes) for tens of thousands of hits. Would you feel more comfortable if we
called it a "read replica" or a "RO replica"? As a reminder: this term appears exactly once
in our documentation and is a list of example setups, so this seems fine to me.

> Replace "master" and "slave" terminology
> ----------------------------------------
>                 Key: COUCHDB-2248
>                 URL:
>             Project: CouchDB
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: Documentation
>            Reporter: Noah Slater
>            Priority: Trivial
> Inspired by the comments on this PR:
> Summary is: `master` and `slave` are racially charged terms, and it would be good to
avoid them. Django have gone for `primary` and `replica`. But we also have to deal with what
we now call multi-master setups. I propose "peer to peer" as a replacement, or just "peer"
if you're describing one node.
> As far as I can tell, the primary work here is the docs. The wiki and any supporting
material can be updated after.

This message was sent by Atlassian JIRA

View raw message