[
https://issues.apache.org/jira/browse/COUCHDB-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14011214#comment-14011214
]
Alexander Shorin commented on COUCHDB-2248:
-------------------------------------------
>> there is no "master/replica" known replication topology. It's was always
>> named as "master-slave".
> This is false. Engine Yard refers to this setup as master/replica. So do the
> Django docs now. The term "database replica" has 24,100 hits in Google.
"database replica" means not the same as "master/slave" - different terms, with
different meaning. That's the current root of the misunderstood between us.
Replacing "master/slave" with "master/replica" makes no sense since:
1. It clashes with Master Replica term
2. It doesn't have any references to Authority sources (only IBM docs with own
use-case context)
3. Google doesn't helps with any search by "master/replica"
Removing the term is looks as a workaround for me: we can remove the word from
docs, but we cannot remove ability to support such replication case and we have
somehow name it if we'll being asked about.
> 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)
