Replication

啟用分片時，MongoDB 僅將塊分配給 Primary

  • April 4, 2016

我正在設置一個帶有 3 個分片的 MongoDB 實例。通過遵循文件並將我的配置與具有類似設置但具有更多碎片的朋友的配置進行比較，我已經正確設置了所有內容。

問題是，一旦我對集合進行分片， db.collection.findOne() 就會停止工作並返回

2016-02-26T10:54:45.865+0100 E QUERY    [thread1] Error: error: {
       "ok" : 0,
       "errmsg" : "None of the hosts for replica set rs0 could be contacted.",
       "code" : 71
} :
_getErrorWithCode@src/mongo/shell/utils.js:23:13
DBCommandCursor@src/mongo/shell/query.js:679:1
DBQuery.prototype._exec@src/mongo/shell/query.js:105:28
DBQuery.prototype.hasNext@src/mongo/shell/query.js:267:5
DBCollection.prototype.findOne@src/mongo/shell/collection.js:215:12
@(shell):1:1

這是我遵循的過程。

use testdatabase
sh.enableSharding("testdatabase")

這一步返回

{ "ok" : 1 }

然後我做

sh.shardCollection("testdatabase.testcollection", {"testId": "hashed"})

哪個返回

{ "collectionsharded" : "testdatabase.testcollection", "ok" : 1 }

在這一點上我做

sh.status()

在配置伺服器上，它正確列出了所有分片和活動 mongoses 的數量。這是它的輸出：

--- Sharding Status ---
 sharding version: {
       "_id" : 1,
       "minCompatibleVersion" : 5,
       "currentVersion" : 6,
       "clusterId" : ObjectId("56a242fbc6293301b0ad4dfd")
}
 shards:
       {  "_id" : "rs1",  "host" : "rs1/pln126.example.com:27017,pln127.example.com:27017" }
       {  "_id" : "rs2",  "host" : "rs2/pln128.example.com:27017,pln129.example.com:27017" }
       {  "_id" : "rs3",  "host" : "rs3/pln130.example.com:27017,pln131.example.com:27017" }
 active mongoses:
       "3.2.1" : 3
 balancer:
       Currently enabled:  yes
       Currently running:  no
       Failed balancer rounds in last 5 attempts:  5
       Last reported error:  Need to swap sharding catalog manager.  Config server reports that it is in replica set mode, but we are still using the legacy SCCC protocol for config server communication
       Time of Reported error:  Fri Feb 26 2016 15:58:07 GMT+0100 (CET)
       Migration Results for the last 24 hours:
               No recent migrations
 databases:
       {  "_id" : "testdatabase",  "primary" : "rs1",  "partitioned" : true }
               testdatabase.testcollection
                       shard key: { "testid" : "hashed" }
                       unique: false
                       balancing: true
                       chunks:
                               rs1     3
                       { "testid" : { "$minKey" : 1 } } -->> { "testid" : NumberLong("-3074457345618258602") } on : rs1 Timestamp(1, 0)
                       { "testid" : NumberLong("-3074457345618258602") } -->> { "testid" : NumberLong("3074457345618258602") } on : rs1 Timestamp(1, 1)
                       { "testid" : NumberLong("3074457345618258602") } -->> { "testid" : { "$maxKey" : 1 } } on : rs1 Timestamp(1, 2)

請注意“需要交換分片目錄管理器”。如果我更改 mongos 配置文件的格式，錯誤就會消失。目前，它採用以下格式 - https://docs.mongodb.org/manual/reference/configuration-options/ 但是如果我將其更改為其他格式（無法線上找到），該錯誤就會消失，但是更改會是這樣的

security:
 clusterAuthMode: keyFile
 keyFile: /etc/mongod.key

會變成

keyFile=/etc/mongod.key

即使其他伺服器的 mongod 配置仍採用 mongodb 文件中描述的第一種格式，我也不會再收到該錯誤。

但是當換了別的。例如從所以基本上它把所有的塊放在主要的，不會讓我對集合做任何查詢。但是，如果我嘗試在其中一個配置伺服器或其中一個分片上登錄 mongo，我會成功連接。

有任何想法嗎？或者您需要更多資訊或其他什麼？

謝謝。

編輯：

根據要求，這是結果rs.status()

{
       "set" : "rs0",
       "date" : ISODate("2016-02-26T14:51:59.977Z"),
       "myState" : 1,
       "term" : NumberLong(7),
       "configsvr" : true,
       "heartbeatIntervalMillis" : NumberLong(2000),
       "members" : [
               {
                       "_id" : 0,
                       "name" : "pln135.example.com:27017",
                       "health" : 1,
                       "state" : 1,
                       "stateStr" : "PRIMARY",
                       "uptime" : 20162,
                       "optime" : {
                               "ts" : Timestamp(1456498319, 9),
                               "t" : NumberLong(7)
                       },
                       "optimeDate" : ISODate("2016-02-26T14:51:59Z"),
                       "electionTime" : Timestamp(1456478170, 1),
                       "electionDate" : ISODate("2016-02-26T09:16:10Z"),
                       "configVersion" : 1,
                       "self" : true
               },
               {
                       "_id" : 1,
                       "name" : "pln136.example.com:27017",
                       "health" : 1,
                       "state" : 2,
                       "stateStr" : "SECONDARY",
                       "uptime" : 20147,
                       "optime" : {
                               "ts" : Timestamp(1456498312, 1),
                               "t" : NumberLong(7)
                       },
                       "optimeDate" : ISODate("2016-02-26T14:51:52Z"),
                       "lastHeartbeat" : ISODate("2016-02-26T14:51:58.352Z"),
                       "lastHeartbeatRecv" : ISODate("2016-02-26T14:51:58.351Z"),
                       "pingMs" : NumberLong(1),
                       "syncingTo" : "pln137.example.com:27017",
                       "configVersion" : 1
               },
               {
                       "_id" : 2,
                       "name" : "pln137.example.com:27017",
                       "health" : 1,
                       "state" : 2,
                       "stateStr" : "SECONDARY",
                       "uptime" : 20160,
                       "optime" : {
                               "ts" : Timestamp(1456498312, 1),
                               "t" : NumberLong(7)
                       },
                       "optimeDate" : ISODate("2016-02-26T14:51:52Z"),
                       "lastHeartbeat" : ISODate("2016-02-26T14:51:58.683Z"),
                       "lastHeartbeatRecv" : ISODate("2016-02-26T14:51:58.682Z"),
                       "pingMs" : NumberLong(0),
                       "syncingTo" : "pln135.example.com:27017",
                       "configVersion" : 1
               }
       ],
       "ok" : 1
}

請記住，我已將埠配置為那個埠，這不是錯誤。出於隱私考慮，我還用“範例”替換了我的域。

目前mongos.conf在應用伺服器上。

sharding:
 configDB: "pln135.example.com:27017,pln136.example.com:27017,pln137.example.com:27017"
security:
 clusterAuthMode: keyFile
 keyFile: /etc/mongod.key

mongos.conf我嘗試過的替代方案不會給出“需要交換分片目錄管理器”。

configdb=rs0/pln135.example.com:27017,pln136.example.com:27017,pln137.example.com:27017
keyFile=/etc/mongod.key

這是mongod.conf來自配置伺服器的

# mongod.conf

# for documentation of all options, see:
#   http://docs.mongodb.org/manual/reference/configuration-options/

# Where and how to store data.
storage:
 dbPath: /var/lib/mongodb
 journal:
   enabled: true
#  engine:
#  mmapv1:
#  wiredTiger:

# where to write logging data.
systemLog:
 destination: file
 logAppend: true
 path: /var/log/mongodb/mongod.log

# network interfaces
net:
 port: 27017
 bindIp: 0.0.0.0

#processManagement:

security:
 authorization: enabled
 keyFile: /etc/mongod.key
 clusterAuthMode: keyFile

#operationProfiling:

replication:
 replSetName: rs0

sharding:
 clusterRole: configsvr

## Enterprise-Only Options:

#auditLog:

#snmp:

這是mongod.conf一個碎片。

# mongod.conf

# for documentation of all options, see:
#   http://docs.mongodb.org/manual/reference/configuration-options/

# Where and how to store data.
storage:
 dbPath: /var/lib/mongodb
 journal:
   enabled: true
#  engine:
#  mmapv1:
#  wiredTiger:

# where to write logging data.
systemLog:
 destination: file
 logAppend: true
 path: /var/log/mongodb/mongod.log

# network interfaces
net:
 port: 27017
 bindIp: 0.0.0.0

#processManagement:

security:
 authorization: enabled
 keyFile: /etc/mongod.key

#operationProfiling:

replication:
 replSetName: rs1

sharding:
 clusterRole: shardsvr

## Enterprise-Only Options:

#auditLog:

#snmp:

解決了。我將 MongoDB 從 3.2.1 升級到 3.2.3，它神奇地開始工作。我什至不需要重新創建/重新配置任何東西。它剛剛開始正確拆分塊並且工作正常。

引用自：https://dba.stackexchange.com/questions/130551

相關問答

Mongodb

mongodb conf節點無法啟動 - 兼容性錯誤

  • April 6, 2022
檢視問答
Replication

Secondary 和 Arbiter 卡在 Startup 中

  • September 16, 2021
檢視問答
Mongodb

MongoDB — 全域初始化失敗：無法打開“/var/log/mongodb/mongod-config.log”

  • July 10, 2021
檢視問答
Mongodb

無法連接到mongos

  • December 23, 2019
檢視問答
Replication

mongodb 找不到匹配讀取首選項 { mode: ‘primary’ } 設置的主機？

  • September 21, 2019
檢視問答
Replication

Mongodb rs.add() 新成員處於 STARTUP 狀態

  • June 20, 2018
檢視問答