Монго удаляет осколок, застрявший на сливе, и другой осколок, недоступный

#mongodb #sharding

Вопрос:

У меня есть кластер из 3 осколков, состоящий из следующих осколков:

  • bp-rs0
  • bp-rs1
  • bp-rs3

Я хочу удалить 1 осколок; bp-rs3.

Я выполнил db.adminCommand( { removeShard: "bp-rs3" } ) и получил в ответ то, что и ожидал, типичное подтверждение.

В нем говорилось, что мне нужно удалить или переместить одну базу данных, которая мне больше не нужна, поэтому я ее удалил. Я не уверен, что это вызвало мою проблему, которая заключается в:

Вот уже несколько часов в сообщении об истощении, возвращенном при запуске db.adminCommand( { removeShard: "bp-rs3" } ) , говорится ровно следующее:

 {
    "msg" : "draining ongoing",
    "state" : "ongoing",
    "remaining" : {
        "chunks" : 334,
        "dbs" : 0
    },
    "note" : "you need to drop or movePrimary these databases",
    "dbsToMove" : [ ],
    "ok" : 1,
    "operationTime" : Timestamp(1629235413, 2),
    "$clusterTime" : {
        "clusterTime" : Timestamp(1629235413, 2),
        "signature" : {
            "hash" : BinData(0,"IkfHFSkxh7gQheeWlXsI/tTjU1U="),
            "keyId" : 6978594490403520515
        }
    }
}
 

Обратите внимание на 334 оставшихся фрагмента. Он давно не менялся.

Это не было бы слишком большой проблемой, но моя наиболее часто используемая коллекция теперь недоступна для запросов, а это означает, что приложение, которое она обслуживает, непригодно для использования.

Я получаю следующую ошибку при попытке запросить мою единственную секционированную коллекцию:

 {
    "message" : "Encountered non-retryable error during query :: caused by :: Could not find host matching read preference { mode: 'primary' } for set bp-rs1",
    "ok" : 0,
    "code" : 133,
    "codeName" : "FailedToSatisfyReadPreference",
    "operationTime" : "Timestamp(1629232940, 1)",
    "$clusterTime" : {
        "clusterTime" : "Timestamp(1629232944, 2)",
        "signature" : {
            "hash" : "IlYQ/HU EWYsm8CL2xtCziX6xtY=",
            "keyId" : "6978594490403520515"
        }
    },
    "name" : "MongoError"
}
 

Я не знаю, почему это вообще повлияет на bp-rs1. bp-rs0 является основным.

sh.status возвращает следующее:

 --- Sharding Status --- 
  sharding version: {
    "_id" : NumberInt(1),
    "minCompatibleVersion" : NumberInt(5),
    "currentVersion" : NumberInt(6),
    "clusterId" : ObjectId("602d2def7771e35f1961e454")
  }
  shards:
        {  "_id" : "bp-rs0",  "host" : "bp-rs0/xxx:27020,xxx:27020",  "state" : NumberInt(1) }
        {  "_id" : "bp-rs1",  "host" : "bp-rs1/xxx:27020",  "state" : NumberInt(1) }
        {  "_id" : "bp-rs3",  "host" : "bp-rs3/xxx:27020",  "state" : NumberInt(1),  "draining" : true }
  active mongoses:
        "4.0.3" : 1
  autosplit:
        Currently enabled: yes
  balancer:
        Currently enabled:  yes
        Currently running:  yes
        Failed balancer rounds in last 5 attempts:  5
        Last reported error:  Could not find host matching read preference { mode: "primary" } for set bp-rs1
        Time of Reported error:  Tue Aug 17 2021 23:09:45 GMT 0100 (British Summer Time)
        Migration Results for the last 24 hours: 
                241 : Success
                1 : Failed with error 'aborted', from bp-rs3 to bp-rs1
  databases:
        {  "_id" : "xxx",  "primary" : "bp-rs0",  "partitioned" : true,  "version" : {  "uuid" : UUID("c6301dba-1f34-4043-be6f-1e99dc9a8fb9"),  "lastMod" : NumberInt(1) } }
                xxx.listings
                        shard key: { "meta.canonical" : 1 }
                        unique: false
                        balancing: true
                        chunks:
                                bp-rs0  696
                                bp-rs1  695
                                bp-rs3  334
                        too many chunks to print, use verbose if you want to force print
        {  "_id" : "config",  "primary" : "config",  "partitioned" : true }
                config.system.sessions
                        shard key: { "_id" : NumberInt(1) }
                        unique: false
                        balancing: true
                        chunks:
                                bp-rs0  1
                        { "_id" : MinKey } -->> { "_id" : MaxKey } on : bp-rs0 Timestamp(1, 0) 

 

Могу ли я что-нибудь сделать? Либо откатиться и начать все сначала, либо просто заставить все работать так, как должно?

Заранее спасибо

Ответ №1:

Я подключился к bp-rs2, чтобы увидеть, что служба по какой-то причине вышла из строя. Я снова запустил его, и миграция завершилась, как я и ожидал.

Я точно не знаю причину, но это могло быть из-за того, что я уронил эту базу данных, когда происходила утечка.