moveChunk nie udało się zaimportować odłamu TO w transferze danych: nie może przyjąć nowych porcji, ponieważ

Question

Mam klastra produkcyjne MongoDb z wersją 2.6.5, którą niedawno zmigrowałem z dwóch do trzech odłamków. Biegałem jak dwa odłamki przez około rok. Każdy fragment to 3-serwerowy zestaw replik i mam jedną kolekcję zerwaną.
Sharded kolekcja ma około 240G, a przy nowym odłamie mam teraz równomiernie rozłożone kawałki 2922 na każdym odłamku. Wydaje się, że moje środowisko produkcyjne działa dobrze. Nie ma problemu z dostępem do danych.

[Uwaga:. 1461 powinna być liczba fragmentów przeniesione z rs0 i shard1 do 2922 na shard2]

Moim zamiarem było shard trzy kolejne zbiory, więc zacząłem z jednym i spodziewałem się, że rozłożone odłamki. Ale nie - skończyło się z tego powtarzającego się błędu:

2014-10-29T20: 26: 35,374 + 0000 wynik [Balancer] moveChunk: {przyczyna: {ok: 0,0, Komunikat o błędzie: „nie może przyjmować nowych fragmentów od ponieważ wciąż jest 1461 usunięć z poprzedniej migracji "},

ok: 0.0, errmsg:" moveChunk nie udało się zaimportować do pliku docelowego w transferze danych: nie może zaakceptować nowych porcji, ponieważ nadal istnieje 1461 usunięć z poprzedniej migracji "}

2014-10-29T20: 26: 35,375 + 0000 [Balancer] ruch balancera nie powiódł się: {przyczyna: {ok: 0.0, errmsg:" nie można zaakceptować nowych porcji, ponieważ nadal jest 1461 usunięć z poprzednich migracja "},

porządku: 0,0, Komunikat o błędzie „moveChunk nie sprzęgają się w celu, fragmencie w przekazywaniu danych nie może przyjąć nowe fragmenty, ponieważ nadal istnieją 1461 usuwa z poprzedniej migracji”} z: rs0 do: shard1 fragment: min: {account_id: MinKey} max: {account_id: -9218254227106808901}

Z niewielkimi badaniami doszedłem do wniosku, że powinienem poświęcić mu trochę czasu, ponieważ oczywiste jest, że trzeba oczyścić rzeczy po przeprowadzce. Uruchomiłem sh.disableBalancing ("nazwa-kolekcji"), aby powstrzymać błędy przed próbą odszyfrowania nowej kolekcji. sh.getBalancerState pokazuje true, podobnie jak sh.isBalancerRunning. Jednak dałem to 24 godziny i komunikat o błędzie jest taki sam. Sądzę, że wyczyścił/usunął co najmniej 1 z 1461, które musi usunąć.

1. Czy to powszechne zachowanie w świecie 2.6? Czy za każdym razem, gdy będę uprawiał środowisko przy pomocy innego odłamka, będę musiał zmylić wszystkie moje zniszczone kolekcje?
2. Każdy pomysł, jak wykonać to porządki? czy powinienem po prostu odłożyć podstawowy odłam1, co wydaje się być problemem?
3. Jeśli zrezygnuję z podstawowej wersji, czy nadal będę miał pliki do "usunięcia/oczyszczenia" z drugiej strony? A może to zajmie się sprawami, abym mógł zacząć odsłaniać nowe kolekcje?

Z góry dziękuję za wszelkie spostrzeżenia.

Answer 1

Nieczęsty jest taki rodzaj problemu, ale widziałem go sporadycznie.

Najlepszym działaniem zaradczym, które można tu zastosować, jest zejście z pierwotnego fragmentu, do którego odnosi się DO, co spowoduje usunięcie usunięć w tle. Usunięte wątki istnieją tylko w bieżącym podstawowym (będą one replikowane z tego podstawowego przez oplog podczas ich przetwarzania). Po zmniejszeniu staje się wtórnym, wątki nie mogą już pisać i otrzymujesz nowy podstawowy bez oczekujących usunięć.Możesz chcieć zrestartować dawną maszynę podstawową po usunięciu starych kursorów, ale zwykle nie jest to pilne.

Gdy to zrobisz, pozostanie Ci wiele osieroconych dokumentów, które mogą być adresami z cleanUpOrphaned command, które polecam uruchamiać przy niskim natężeniu ruchu (jeśli masz takie czasy).

Dla odniesienia, jeśli jest to powtarzający się problem, prawdopodobnie najprawdopodobniej borykają się one z niewielkim obciążeniem, a uniknięcie kolejkowania usunięć może ustawić wartość true dla balancera (false dla wartości false). domyślne) w następujący sposób:

use config 
db.settings.update(
    { "_id" : "balancer" }, 
    { $set : { "_waitForDelete" : true } }, 
    { upsert : true } 
) 

to będzie oznaczać, że każda migracja jest wolniejsze (może istotnie tak), ale nie spowoduje usunięcie tła gromadzić.