[
https://issues.apache.org/jira/browse/COUCHDB-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010062#comment-14010062
]
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: https://issues.apache.org/jira/browse/COUCHDB-2248
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Documentation
> Reporter: Noah Slater
> Priority: Trivial
>
> Inspired by the comments on this PR:
> https://github.com/django/django/pull/2692
> 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
(v6.2#6252)
