在副本集中，爲什麼主實例與mongodb中的輔助實例具有幾乎相同的連接數？

我有一個主副本，2個副本和1個仲裁實例的副本集，其中沒有與主副本的連接幾乎相同。爲什麼這個連接在主服務器上是高的，而它應該只有1個，就像我們沒有的應用服務器一樣，它們指向Primary來進行寫操作。請告訴我們。在副本集中，爲什麼主實例與mongodb中的輔助實例具有幾乎相同的連接數？

來源

2015-09-28 Mukesh Kumar

以及究竟是你的問題？這部分有點不清楚「爲什麼連接的主要高，而它應該只有1我們沒有應用程序服務器，這是指向主要寫操作。」 – Martin

@Martin，我們已設置讀取操作在副本集中的輔助實例，我們在代碼級別做了，但我想知道爲什麼沒有連接連續增加到Primary，而讀取操作只發生在輔助中（連接在輔助中也增加），而且很少有寫操作正在小學進行。 –

默認情況下，應用程序將其讀取操作指向副本集中的主要成員。由於寫入操作發佈到單個主節點，因此從主節點讀取返回文檔的最新版本。

但在某些情況下，副本集中的兩個節點可能暫時相信他們是主要的，但最多，其中一人將能夠完成與【W：多數}寫到寫的關注。可以完成{w：majority}寫入的節點是當前的主節點，而另一個節點是之前尚未識別其降級的主節點，通常是由於網絡分區。發生這種情況時，儘管請求了讀取首選項主節點，但連接到以前的主節點的客戶端可能會觀察到過時數據

對於不需要完整最新數據的應用程序，可以通過將部分或全部讀取分發給副本集的次要成員來提高讀取吞吐量或減少延遲。

因此，閱讀首選項描述了MongoDB客戶端如何將讀取操作路由到副本集的成員。

在mongoDB有5個閱讀偏好模式。

primary默認模式。從當前副本中讀取的所有操作設置爲主。
primaryPreferred在大多數情況下，操作從主小區讀取，但如果不可用，操作將從中讀取次要成員。
secondary所有操作都從讀取副本集的次要成員。
secondaryPreferred在大多數的情況下，操作是從次要成員讀取的，但如果沒有次要成員可用，則從主要操作讀取操作。
nearest無論成員的類型如何，操作都從具有網絡延遲的副本集的成員中讀取，而不考慮成員的類型。

如何使用 -

db.collection.find().readPref({ mode: 'nearest', tags: [ {'dc': 'east'} ] })

更多@MongoDB Docs

您也可以撥打一個蒙戈連接對象的setReadPref（）方法來控制如何路由客戶端將所有查詢副本集的成員。

EX- db.getMongo().setReadPref('primaryPreferred')

更多@MongoDB Docs

來源

2015-09-29 07:47:40

我知道，我們可以將讀取操作設置爲副本集中的次要操作，並且我們在代碼級別執行了操作，但是我想知道爲什麼沒有連接連續增加到Primary，而讀取操作只發生在Secondary中，很少寫操作正在進行中。 –

@MukeshKumar在你的連接中使用setReadPref（'primaryPreferred'）。如果你想在多個服務器之間隨機地運行查詢，那麼也可以使用haproxy。 mongodb的默認行爲是在我們所做的主要 –

上運行查詢，您建議使用readPref，但我擔心的是高連接數。爲什麼它在不斷增加，並且幾乎與中學時沒有連接相同。 –

在副本集中，爲什麼主實例與mongodb中的輔助實例具有幾乎相同的連接數？

回答

相關問題