couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Newson (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-2248) Replace "master" and "slave" terminology
Date Tue, 27 May 2014 18:34:02 GMT


Robert Newson commented on COUCHDB-2248:

"replica" does not mean "slave", and, as previously mentioned, and just now mentioned again,
"master replica" and "slave replica" are valid (if redundant) ways to express these terms.

in the sentence in question, "master/slave" is the simplest and most descriptive term to use
to describe that couchdb can be used in a master/slave setup. The meaning is plain. To Alex's
point about "backup", I believe that is the intended functionality of a slave database in
a master/slave setup, it serves as a backup of the master. One "fails over" to the backup
if the master fails. If you like, and to break this deadlock, I'm +1 on "primary/secondary"
but I remain -1 on changing away from the straightforward use of "master/slave" to something
that is less clear (which I feel "replica" is).

> 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