MongoClient 连接到多个主机来处理故障转移？

Question

我有一个连接到两个主机的非常简单的 PyMongo 配置：

from pymongo import MongoClient

host = os.getenv('MONGODB_HOST', '127.0.0.1')
port = int(os.getenv('MONGODB_PORT', 27017))
hosts = []
for h in host.split(','):
    hosts.append('{}:{}'.format(h, port))
cls.client = MongoClient(host=hosts, replicaset='replicatOne')

MONGODB_HOST是由两个ip组成的列表，如“primary_mongo,secondary_mongo”

它们被配置为复制集。

我注意到的问题是，在当前配置中，如果 secondary_mongo 出现故障，我的整个代码将停止工作。

我认为向 MongoClient 提供主机列表会告诉它“使用有效的主机，从第一个开始”，但它似乎不正确。

出了什么问题，如何确保 MongoClient 首先正确连接到 primary_mongo，如果失败，则转到 secondary_mongo？

感谢您的帮助。

Answer 1

为了拥有完整的运行 MongoDB ReplicaSet，您必须有一个 PRIMARY 成员。 PRIMARY 只有在所有成员中的大多数可用时才能被选出。 2 个中有 1 个不是多数，因此如果一个节点出现故障，您的 MongoDB ReplicaSet 将关闭。

当您连接到 MongoDB 时，您可以连接到 ReplicaSet，例如

mongo "mongodb://localhost:27037,localhost:27137,localhost:27237/?replicaSet=repSet"

或者您直接连接，例如

mongo "mongodb://localhost:27037,localhost:27137"

当您连接到 ReplicaSet 并且 PRIMARY 关闭（或者当它出于任何原因退回到 SECONDARY 时）并且另一个成员成为 PRIMARY 时，通常客户端会自动重新连接到新的 PRIMARY。但是，连接到 ReplicaSet 需要一个 PRIMARY 成员，即大多数成员必须可用。

当您直接连接时，您还可以连接到 SECONDARY 成员并在 read/only 模式下使用 MongoDB。但是，如果连接的成员出现故障，您将没有任何 failover/reconnect 功能。

您可以在您的其中一个节点上创建一个 ARBITER 成员。然后，如果另一个节点出现故障，应用程序仍然完全可用。请记住，通过此设置，您只能丢失“第二个”主机，但不会丢失其中任何一个。在最好的情况下，您可以在独立的第三个位置配置 ARBITER。

来自 MongoDB: The Definitive Guide by Shannon Bradshaw, Eoin Brazil, Kristina Chodorow：第三部分 - 复制，第 9 章 - 设置副本集：

How to Design a Set

To plan out your set, there are certain replica set concepts that you must be familiar with. The next chapter goes into more detail about these, but the most important is that replica sets are all about majorities: you need a majority of members to elect a primary, a primary can only stay primary so long as it can reach a majority, and a write is safe when it’s been replicated to a majority. This majority is defined to be “more than half of all members in the set,” as shown in Table 9-1.

Number of members in the set	Majority of the set
1	1
2	2
3	2
4	3
5	3
6	4
7	4

Note that it doesn’t matter how many members are down or unavailable, as majority is based on the set’s configuration.

For example, suppose that we have a five-member set and three members go down, as shown in Figure 9-1. There are still two members up. These two members cannot reach a majority of the set (at least three members), so they cannot elect a primary. If one of them were primary, it would step down as soon as it noticed that it could not reach a majority. After a few seconds, your set would consist of two secondaries and three unreachable members.

Many users find this frustrating: why can’t the two remaining members elect a primary? The problem is that it’s possible that the other three members didn’t go down, and that it was the network that went down, as shown in Figure 9-2. In this case, the three members on the left will elect a primary, since they can reach a majority of the set (three members out of five).

In the case of a network partition, we do not want both sides of the partition to elect a primary: otherwise the set would have two primaries. Then both primaries would be writing to the data and the data sets would diverge. Requiring a majority to elect or stay primary is a neat way of avoiding ending up with more than one primary.

It is important to configure your set in such a way that you’ll usually be able to have one primary. For example, in the five-member set described above, if members 1, 2, and 3 are in one data center and members 4 and 5 are in another, there should almost always be a majority available in the first data center (it’s more likely to have a network break between data centers than within them).

MongoClient 连接到多个主机来处理故障转移？

MongoClient to connect to multiple hosts to handle failover?

mongodb

pymongo