|
1 | 1 | .. uses high-availability.rst
|
2 | 2 |
|
| 3 | +.. _pymongo-connection-options: |
| 4 | + |
| 5 | +================== |
| 6 | +Connection Options |
| 7 | +================== |
| 8 | + |
| 9 | +.. contents:: On this page |
| 10 | + :local: |
| 11 | + :backlinks: none |
| 12 | + :depth: 1 |
| 13 | + :class: singlecol |
| 14 | + |
| 15 | +.. facet:: |
| 16 | + :name: genre |
| 17 | + :values: reference |
| 18 | + |
| 19 | +.. meta:: |
| 20 | + :keywords: connect |
| 21 | + |
| 22 | +On this page, you can learn about connection options that you can configure with |
| 23 | +your ``MongoClient``. |
| 24 | + |
3 | 25 | .. _secondary-reads:
|
4 | 26 |
|
5 | 27 | Secondary Reads
|
6 |
| -~~~~~~~~~~~~~~~ |
| 28 | +--------------- |
7 | 29 |
|
8 |
| -By default an instance of MongoClient sends queries to |
9 |
| -the primary member of the replica set. To use secondaries for queries |
10 |
| -we have to change the read preference: |
| 30 | +By default, an instance of ``MongoClient`` sends queries to |
| 31 | +the primary member of the replica set. To use secondary members for queries instead, change |
| 32 | +the read preference as shown in the following example: |
11 | 33 |
|
12 | 34 | .. code-block:: python
|
13 | 35 |
|
14 |
| - >>> client = MongoClient( |
15 |
| - ... 'localhost:27017', |
16 |
| - ... replicaSet='foo', |
17 |
| - ... readPreference='secondaryPreferred') |
18 |
| - >>> client.read_preference |
19 |
| - SecondaryPreferred(tag_sets=None) |
| 36 | + >>> client = MongoClient( |
| 37 | + ... 'localhost:27017', |
| 38 | + ... replicaSet='foo', |
| 39 | + ... readPreference='secondaryPreferred') |
| 40 | + >>> client.read_preference |
| 41 | + SecondaryPreferred(tag_sets=None) |
20 | 42 |
|
21 |
| -Now all queries will be sent to the secondary members of the set. If there are |
22 |
| -no secondary members the primary will be used as a fallback. If you have |
23 |
| -queries you would prefer to never send to the primary you can specify that |
| 43 | +Now the ``MongoClient`` sends all queries to the secondary members of the replica set. If there are |
| 44 | +no secondary members, the client uses the primary member as a fallback. If you have |
| 45 | +queries you would prefer to never send to the primary, you can specify that |
24 | 46 | using the ``secondary`` read preference.
|
25 | 47 |
|
26 |
| --------- |
27 |
| - |
28 | 48 | .. _health-monitoring:
|
29 | 49 |
|
30 | 50 | Health Monitoring
|
31 |
| -''''''''''''''''' |
| 51 | +----------------- |
32 | 52 |
|
33 |
| -When MongoClient is initialized it launches background threads to |
34 |
| -monitor the replica set for changes in: |
| 53 | +When you initialize a ``MongoClient``, it launches background threads to |
| 54 | +monitor the replica set for the following changes: |
35 | 55 |
|
36 |
| -* Health: detect when a member goes down or comes up, or if a different member |
37 |
| - becomes primary |
38 |
| -* Configuration: detect when members are added or removed, and detect changes |
39 |
| - in members' tags |
40 |
| -* Latency: track a moving average of each member's ping time |
| 56 | +- Health: Detect when a member goes down or comes up, or if a different member |
| 57 | + becomes primary. |
| 58 | +- Configuration: Detect when members are added or removed, and detect changes |
| 59 | + in members' tags. |
| 60 | +- Latency: Track a moving average of each member's ping time. |
41 | 61 |
|
42 |
| -Replica-set monitoring ensures queries are continually routed to the proper |
| 62 | +Replica-set monitoring ensures that queries are continually routed to the proper |
43 | 63 | members as the state of the replica set changes.
|
44 | 64 |
|
45 | 65 | .. _mongos-load-balancing:
|
46 | 66 |
|
47 |
| -mongos Load Balancing |
48 |
| ---------------------- |
| 67 | +``mongos`` Load Balancing |
| 68 | +------------------------- |
49 | 69 |
|
50 |
| -An instance of ``~pymongo.mongo_client.MongoClient`` can be configured |
51 |
| -with a list of addresses of mongos servers: |
| 70 | +You can configure an instance of ``~pymongo.mongo_client.MongoClient`` |
| 71 | +with a list of ``mongos`` server addresses: |
52 | 72 |
|
53 | 73 | .. code-block:: python
|
54 | 74 |
|
55 | 75 | >> client = MongoClient('mongodb://host1,host2,host3')
|
56 | 76 |
|
57 |
| -Each member of the list must be a single mongos server. Multihomed and round |
| 77 | +Each member of the list must be a single ``mongos`` server. Multi-homed and round |
58 | 78 | robin DNS addresses are **not** supported. The client continuously
|
59 |
| -monitors all the mongoses' availability, and its network latency to each. |
| 79 | +monitors the availability of all ``mongos`` servers. It also monitors its |
| 80 | +network latency to each server. |
60 | 81 |
|
61 |
| -PyMongo distributes operations evenly among the set of mongoses within its |
| 82 | +PyMongo distributes operations evenly among the set of ``mongos`` servers within its |
62 | 83 | ``localThresholdMS`` (similar to how it distributes reads to secondaries
|
63 |
| -in a replica set). By default the threshold is 15 ms. |
| 84 | +in a replica set). By default, the threshold is 15 ms. |
64 | 85 |
|
65 |
| -The lowest-latency server, and all servers with latencies no more than |
66 |
| -``localThresholdMS`` beyond the lowest-latency server's, receive |
67 |
| -operations equally. For example, if we have three mongoses: |
| 86 | +The server with the lowest latency, and all servers with latencies no more than |
| 87 | +``localThresholdMS`` beyond the server with the lowest latency, receive |
| 88 | +operations equally. For example, consider the following three ``mongos`` servers: |
68 | 89 |
|
69 | 90 | - host1: 20 ms
|
70 | 91 | - host2: 35 ms
|
71 | 92 | - host3: 40 ms
|
72 | 93 |
|
73 |
| -By default the ``localThresholdMS`` is 15 ms, so PyMongo uses host1 and host2 |
74 |
| -evenly. It uses host1 because its network latency to the driver is shortest. It |
75 |
| -uses host2 because its latency is within 15 ms of the lowest-latency server's. |
76 |
| -But it excuses host3: host3 is 20ms beyond the lowest-latency server. |
| 94 | +By default, the ``localThresholdMS`` is 15 ms, so PyMongo uses "host1" and "host2" |
| 95 | +evenly. It uses "host1" because its network latency to the driver is shortest. It |
| 96 | +uses "host2" because its latency is within 15 ms of the server with the lowest latency. |
| 97 | +PyMongo doesn't use "host3" because its latency is 20 ms beyond the server with the |
| 98 | +lowest latency. |
77 | 99 |
|
78 |
| -If we set ``localThresholdMS`` to 30 ms all servers are within the threshold: |
| 100 | +To ensure that all servers are within the threshold, set ``localThresholdMS`` to 30 |
| 101 | +ms as shown in the following example: |
79 | 102 |
|
80 | 103 | .. code-block:: python
|
81 | 104 |
|
82 | 105 | >> client = MongoClient('mongodb://host1,host2,host3/?localThresholdMS=30')
|
83 | 106 |
|
84 |
| -.. warning:: Do **not** connect PyMongo to a pool of mongos instances through a |
85 |
| - load balancer. A single socket connection must always be routed to the same |
86 |
| - mongos instance for proper cursor support. |
| 107 | +.. warning:: |
| 108 | + |
| 109 | + Do **not** connect PyMongo to a pool of ``mongos`` instances through a |
| 110 | + load balancer. A single socket connection must always route to the same |
| 111 | + ``mongos`` instance for proper cursor support. |
0 commit comments