mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-08-31 15:57:45 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

Fixed #22667 -- Replaced leader/follower terminology with primary/replica

Browse source
This commit is contained in:
Flavio Curella 2014-05-20 14:54:56 -05:00 • committed by Tim Graham
parent ad994a3c5b
commit beec05686c
7 changed files with 85 additions and 82 deletions
Download patch file Download diff file Expand all files Collapse all files

39
docs/topics/testing/advanced.txt
View file

@ -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.