-
Notifications
You must be signed in to change notification settings - Fork 1.7k
/
replication.txt
50 lines (36 loc) · 1.69 KB
/
replication.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
====================================
Replica Set Read and Write Semantics
====================================
.. default-domain:: mongodb
.. contents:: On this page
:local:
:backlinks: none
:depth: 1
:class: singlecol
From the perspective of a client application, whether a MongoDB
instance is running as a single server (i.e. "standalone") or a
:term:`replica set` is transparent.
By default, in MongoDB, read operations to a replica set return results
from the :doc:`primary </core/replica-set-primary>`.
Users may configure :term:`read preference` on a per-connection basis
to prefer that the read operations return results from the
:term:`secondary` members. If clients configure the :term:`read
preference` to permit secondary reads, read operations can return data
from :term:`secondary` members that have not replicated more recent
write operations.
This behavior is sometimes characterized as :term:`eventual
consistency` because the secondary member's state will *eventually*
reflect the primary's state and MongoDB cannot guarantee :term:`strict
consistency` for read operations from secondary members.
[#edge-cases-2-primaries]_
.. note::
- In MongoDB, clients can see the results of writes before they are
made durable:
.. include:: /includes/list-visibility-of-data.rst
- :term:`Sharded clusters <sharded cluster>` where the shards are
also replica sets provide the same operational semantics with
regards to write and read operations.
.. include:: /includes/toc/dfn-list-replica-set-read-write-semantics.rst
.. include:: /includes/toc/replica-set-read-write-semantics.rst
.. [#edge-cases-2-primaries]
.. include:: /includes/footnote-two-primaries-edge-cases.rst