mongodb - 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 成员。只有在所有成员中获得多数票的情况下才能选举出主要成员。 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 成员并以只读/只读模式使用 MongoDB。但是，如果连接的成员出现故障，您将没有任何故障转移/重新连接功能。

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

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

How to Design a Set

To plan out your set, there are certain replica set concepts that you must be familiarwith. The next chapter goes into more detail about these, but the most important is thatreplica 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 safewhen it’s been replicated to a majority. This majority is defined to be “more than half ofall members in the set,” as shown in Table 9-1.

<表类=“s-表”><标题>集合中的成员数量集合中的大多数 <正文>11223243536474

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

For example, suppose that we have a five-member set and three members go down, asshown in Figure 9-1. There are still two members up. These two members cannot reacha majority of the set (at least three members), so they cannot elect a primary. If one ofthem 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 thatit 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 (threemembers out of five).

In the case of a network partition, we do not want both sides of the partition to elect aprimary: otherwise the set would have two primaries. Then both primaries would bewriting to the data and the data sets would diverge. Requiring a majority to elect or stayprimary 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 oneprimary. For example, in the five-member set described above, if members 1, 2, and 3are in one data center and members 4 and 5 are in another, there should almost alwaysbe a majority available in the first data center (it’s more likely to have a network breakbetween data centers than within them).