Mongos định tuyến với ReadPreference = NEAREST

Question

Tôi đang gặp sự cố khi chẩn đoán sự cố trong đó yêu cầu ứng dụng Java của tôi tới MongoDB không được định tuyến đến bản sao Gần nhất và tôi hy vọng ai đó có thể trợ giúp. Hãy để tôi bắt đầu bằng cách giải thích cấu hình của tôi.

Configuration:

Tôi đang chạy một ví dụ MongoDB trong sản xuất đó là một Sharded ReplicaSet. Hiện tại nó chỉ là một mảnh duy nhất (nó chưa đủ lớn để yêu cầu phân chia). Mảnh duy nhất này được hỗ trợ bởi một tập bản sao 3 nút. 2 nút của bản sao được đặt trực tiếp trong trung tâm dữ liệu chính của chúng tôi. Nút thứ 3 tồn tại trong trung tâm dữ liệu phụ của chúng tôi và bị cấm trở thành nút chính.

Chúng tôi chạy ứng dụng sản xuất đồng thời ở cả hai trung tâm dữ liệu, tuy nhiên thể hiện trong trung tâm dữ liệu thứ cấp của chúng tôi hoạt động ở chế độ "chỉ đọc" và không bao giờ ghi dữ liệu vào MongoDB. Nó chỉ phục vụ các yêu cầu của khách hàng cho việc đọc dữ liệu hiện có. Mục tiêu của cấu hình này là để đảm bảo rằng nếu trung tâm dữ liệu chính của chúng tôi ngừng hoạt động, chúng tôi vẫn có thể phục vụ lưu lượng truy cập đọc của khách hàng.

Chúng tôi không muốn lãng phí tất cả phần cứng này trong trung tâm dữ liệu phụ của chúng tôi, vì vậy ngay cả trong thời gian vui vẻ, chúng tôi chủ động cân bằng tải một phần lưu lượng truy cập chỉ đọc của chúng tôi cho ứng dụng của chúng tôi đang chạy trong trung tâm dữ liệu phụ. Ví dụ ứng dụng này được cấu hình với readPreference = NEAREST và được trỏ tới một cá thể mongos chạy trên localhost (phiên bản 2.6.7). Cá thể mongos được cấu hình rõ ràng để trỏ vào tập bản sao 3 nút của chúng ta.

Từ một mongos:

mongos> sh.status() 
--- Sharding Status --- 
sharding version: { 
"_id" : 1, 
"version" : 4, 
"minCompatibleVersion" : 4, 
"currentVersion" : 5, 
"clusterId" : ObjectId("52a8932af72e9bf3caad17b5") 
} 
shards: 
{ "_id" : "shard1", "host" : "shard1/failover1.com:27028,primary1.com:27028,primary2.com:27028" } 
databases: 
{ "_id" : "admin", "partitioned" : false, "primary" : "config" } 
{ "_id" : "test", "partitioned" : false, "primary" : "shard1" } 
{ "_id" : "MyApplicationData", "partitioned" : false, "primary" : "shard1" } 

Từ failover nút của replicaset:

shard1:SECONDARY> rs.status() 
{ 
"set" : "shard1", 
"date" : ISODate("2015-09-03T13:26:18Z"), 
"myState" : 2, 
"syncingTo" : "primary1.com:27028", 
"members" : [ 
{ 
    "_id" : 3, 
    "name" : "primary1.com:27028", 
    "health" : 1, 
    "state" : 1, 
    "stateStr" : "PRIMARY", 
    "uptime" : 674841, 
    "optime" : Timestamp(1441286776, 2), 
    "optimeDate" : ISODate("2015-09-03T13:26:16Z"), 
    "lastHeartbeat" : ISODate("2015-09-03T13:26:16Z"), 
    "lastHeartbeatRecv" : ISODate("2015-09-03T13:26:18Z"), 
    "pingMs" : 49, 
    "electionTime" : Timestamp(1433952764, 1), 
    "electionDate" : ISODate("2015-06-10T16:12:44Z") 
}, 
{ 
    "_id" : 4, 
    "name" : "primary2.com:27028", 
    "health" : 1, 
    "state" : 2, 
    "stateStr" : "SECONDARY", 
    "uptime" : 674846, 
    "optime" : Timestamp(1441286777, 4), 
    "optimeDate" : ISODate("2015-09-03T13:26:17Z"), 
    "lastHeartbeat" : ISODate("2015-09-03T13:26:18Z"), 
    "lastHeartbeatRecv" : ISODate("2015-09-03T13:26:18Z"), 
    "pingMs" : 53, 
    "syncingTo" : "primary1.com:27028" 
}, 
{ 
    "_id" : 5, 
    "name" : "failover1.com:27028", 
    "health" : 1, 
    "state" : 2, 
    "stateStr" : "SECONDARY", 
    "uptime" : 8629159, 
    "optime" : Timestamp(1441286778, 1), 
    "optimeDate" : ISODate("2015-09-03T13:26:18Z"), 
    "self" : true 
} 
], 
"ok" : 1 
} 


shard1:SECONDARY> rs.conf() 
{ 
    "_id" : "shard1", 
    "version" : 15, 
    "members" : [ 
    { 
     "_id" : 3, 
     "host" : "primary1.com:27028", 
     "tags" : { 
      "dc" : "primary" 
     } 
    }, 
    { 
     "_id" : 4, 
     "host" : "primary2.com:27028", 
     "tags" : { 
      "dc" : "primary" 
     } 
    }, 
    { 
     "_id" : 5, 
     "host" : "failover1.com:27028", 
     "priority" : 0, 
     "tags" : { 
      "dc" : "failover" 
     } 
    } 
    ], 
    "settings" : { 
     "getLastErrorModes" : {"ACKNOWLEDGED" : {}} 
    } 
} 

Vấn đề:

Vấn đề là yêu cầu trong đó nhấn mongos này của chúng tôi trung tâm dữ liệu thứ cấp dường như được định tuyến đến một bản sao đang chạy trong trung tâm dữ liệu chính của chúng tôi, chứ không phải nút gần nhất, đang chạy trong trung tâm dữ liệu phụ. Điều này gây ra một số lượng đáng kể thời gian chờ của mạng và dẫn đến hiệu suất đọc kém.

Sự hiểu biết của tôi là mongos quyết định nút nào trong bản sao được đặt để định tuyến yêu cầu đến, và nó được coi là tôn trọng ReadPreference từ yêu cầu của trình điều khiển java của tôi. Có một lệnh tôi có thể chạy trong vỏ mongos để xem tình trạng của bộ bản sao, bao gồm cả thời gian ping đến các nút? Hoặc một số cách để xem ghi nhật ký các yêu cầu đến chỉ ra nút trong bản sao đã được chọn và tại sao? Bất kỳ lời khuyên nào cả về cách chẩn đoán nguyên nhân gốc rễ của vấn đề của tôi?

Answer 1

Nếu tôi bắt đầu mongos với cờ -vvvv (4x verbose) sau đó tôi đã trình bày với yêu cầu thông tin định tuyến trong các tập tin nhật ký, trong đó có thông tin về sở thích đọc sử dụng và máy chủ mà các yêu cầu được định tuyến. ví dụ:

2015-09-10T17:17:28.020+0000 [conn3] dbclient_rs say 
using secondary or tagged node selection in shard1, 
read pref is { pref: "nearest", tags: [ {} ] } 
    (primary : primary1.com:27028, 
    lastTagged : failover1.com:27028) 

Answer 2

Trong khi định cấu hình tùy chọn đọc, khi ReadPreference = NEAREST hệ thống không tìm độ trễ mạng tối thiểu vì nó có thể quyết định chính là gần nhất, nếu kết nối mạng là phù hợp. Tuy nhiên, chế độ đọc gần nhất, khi được kết hợp với một bộ thẻ, chọn thành viên phù hợp với độ trễ mạng thấp nhất. Thậm chí gần nhất có thể là bất kỳ tiểu học hoặc trung học. Hành vi của mongos khi tùy chọn được cấu hình, và về độ trễ của mạng không được giải thích rõ ràng trong các tài liệu chính thức.

http://docs.mongodb.org/manual/core/read-preference/#replica-set-read-preference-tag-sets

hy vọng điều này giúp