From beec05686ccc3bee8461f9a5a02c607a02352ae1 Mon Sep 17 00:00:00 2001
From: Flavio Curella <flavio.curella@gmail.com>
Date: Tue, 20 May 2014 14:54:56 -0500
Subject: Fixed #22667 -- Replaced leader/follower terminology with
 primary/replica

---
 docs/topics/testing/advanced.txt | 39 ++++++++++++++++++++-------------------
 1 file changed, 20 insertions(+), 19 deletions(-)

(limited to 'docs/topics/testing')

diff --git a/docs/topics/testing/advanced.txt b/docs/topics/testing/advanced.txt
index de9c09b919..1a82af8b04 100644
--- a/docs/topics/testing/advanced.txt
+++ b/docs/topics/testing/advanced.txt
@@ -64,16 +64,17 @@ The following is a simple unit test using the request factory::
 Tests and multiple databases
 ============================
 
-.. _topics-testing-leaderfollower:
+.. _topics-testing-primaryreplica:
 
-Testing leader/follower configurations
+Testing primary/replica configurations
 -----------------------------------
 
-If you're testing a multiple database configuration with leader/follower
-replication, this strategy of creating test databases poses a problem.
+If you're testing a multiple database configuration with primary/replica
+(referred to as master/slave by some databases) replication, this strategy of
+creating test databases poses a problem.
 When the test databases are created, there won't be any replication,
-and as a result, data created on the leader won't be seen on the
-follower.
+and as a result, data created on the primary won't be seen on the
+replica.
 
 To compensate for this, Django allows you to define that a database is
 a *test mirror*. Consider the following (simplified) example database
@@ -83,34 +84,34 @@ configuration::
         'default': {
             'ENGINE': 'django.db.backends.mysql',
             'NAME': 'myproject',
-            'HOST': 'dbleader',
+            'HOST': 'dbprimary',
              # ... plus some other settings
         },
-        'follower': {
+        'replica': {
             'ENGINE': 'django.db.backends.mysql',
             'NAME': 'myproject',
-            'HOST': 'dbfollower',
+            'HOST': 'dbreplica',
             'TEST_MIRROR': 'default'
             # ... plus some other settings
         }
     }
 
-In this setup, we have two database servers: ``dbleader``, described
-by the database alias ``default``, and ``dbfollower`` described by the
-alias ``follower``. As you might expect, ``dbfollower`` has been configured
-by the database administrator as a read follower of ``dbleader``, so in
-normal activity, any write to ``default`` will appear on ``follower``.
+In this setup, we have two database servers: ``dbprimary``, described
+by the database alias ``default``, and ``dbreplica`` described by the
+alias ``replica``. As you might expect, ``dbreplica`` has been configured
+by the database administrator as a read replica of ``dbprimary``, so in
+normal activity, any write to ``default`` will appear on ``replica``.
 
 If Django created two independent test databases, this would break any
-tests that expected replication to occur. However, the ``follower``
+tests that expected replication to occur. However, the ``replica``
 database has been configured as a test mirror (using the
 :setting:`TEST_MIRROR` setting), indicating that under testing,
-``follower`` should be treated as a mirror of ``default``.
+``replica`` should be treated as a mirror of ``default``.
 
-When the test environment is configured, a test version of ``follower``
-will *not* be created. Instead the connection to ``follower``
+When the test environment is configured, a test version of ``replica``
+will *not* be created. Instead the connection to ``replica``
 will be redirected to point at ``default``. As a result, writes to
-``default`` will appear on ``follower`` -- but because they are actually
+``default`` will appear on ``replica`` -- but because they are actually
 the same database, not because there is data replication between the
 two databases.
 
-- 
cgit v1.3