MongoDB：副本集和循環查詢分布？

Question

我們有一個具有以下結構的 MongoDB 副本集：

• 2 次初選
• 3個只讀輔助

我們有一個應用程序使用只讀輔助節點執行非常繁重的查詢。

問題是系統正在超載其中一個實例，而另外兩個大多是惰性的，它們仍然接收查詢，但很明顯系統有一個首選實例，因此結構無法正確擴展。

這是我們的連接配置：

mongo:
  collection: "panelUsers"
  urls:
    - "mongo-001.my.network:27017"
    - "mongo-002.my.network:27017"
    - "mongo-readonly-001.my.network:27017"
    - "mongo-readonly-002.my.network:27017"
    - "mongo-readonly-003.my.network:27017"
  connection_opts:
    user: "user"
    password: "password"
    database: "mydb"
    replica_set: "mongo-replica"
    read:
      mode: "secondary"
      tag_sets:
        - nodeType: "readonly"

我可以在監視器中看到其中一個實例是如何接管大部分負載的：

當該過程開始時，這 3 個實例看起來它們正在占用相當一部分的查詢，但隨着時間的推移，其中一個實例開始占用大部分查詢。 當 3 個實例正常協作時，我可以看到系統性能（每分鍾查詢數）要好得多，當其中一個實例承擔大部分負載時，整個系統開始變慢。

出於測試目的，我關閉了承擔大部分負載的實例，我看到其他 2 個開始承擔相當多的負載，然后系統比 3 個實例正在運行但只有一個實例承擔大部分負載時更快。 一段時間后，1 個實例（從左邊的 2 個實例開始）開始承擔所有負載，並且進程開始減慢。

我已閱讀有關服務器選擇算法的信息，並且我了解 Mongo 正在選擇實例來解決基於 ping 延遲的查詢。 看起來不像一個非常進化的系統：/

我認為在我的情況下，循環機制會更好。

我可以在我們的 MongoDB 只讀副本中激活循環服務器選擇算法嗎？

PS：我已經讀過分片對我的情況來說是一個更好的解決方案，但它看起來不像是我可以輕松做到的事情，在我為此做 go 之前，我想知道是否有更簡單的解決方案適合我的情況。

Answer 1

首先，MongoDB 一次只有 1 個初級。 它作為一個單一的主人工作。

所有讀/寫都來自主節點，除非您從輔助節點指定讀取首選項。

您的“只讀”輔助文件。 您是否將它們配置為隱藏？ 因為如果發生故障轉移，它們也可能成為主節點。

我的建議是執行以下操作：

1. 保留 3 個節點的副本集（用於操作負載），而不是 5 個。 為您的“常規”讀寫提供標准索引
2. 有 2 個專用輔助節點（隱藏節點）用於專業負載，您可以在其中創建索引以支持您的查詢
3. 確保您沒有進行集合掃描或 memory 排序。 請參閱https://docs.mongodb.com/manual/reference/method/cursor.explain/
4. 在副本集中擁有額外的節點並不能幫助您獲得更高的讀/寫吞吐量，因為在主節點上寫入的任何內容也會在輔助節點上寫入。 所以它也和初級會一樣忙。 但是您可以創建專家隱藏節點來支持報告負載，如 2 中所述。
5. 分片是提高讀/寫吞吐量的正確方法