Безкрайно състояние на възстановяване на вторичното

Проблемът (най-вероятно)

Последната операция на основния е от "2015-05-15T02:10:56Z", докато последната операция на вторичния е от "2015-05-14T11:23:51Z", което е разлика от приблизително 15 часа. Този прозорец може доста да надвишава вашия прозорец на оплог за репликация (разликата между времето на първия и последния запис на операция във вашия оплог). Казано по-просто, има твърде много операции на първичната, за да може вторичната да навакса.

Малко по-подробно (макар и опростено):по време на първоначално синхронизиране данните, от които се синхронизира вторичното, са данните от даден момент от време. Когато данните от този момент във времето се синхронизират, вторичният се свързва с oplog и прилага промените, които са направени между споменатия момент във времето и сега според записите в oplog. Това работи добре, докато oplog поддържа всички операции между споменатия момент във времето. Но oplog има ограничен размер (това е така наречената ограничена колекция ). Така че, ако има повече операции, които се случват на основния, отколкото oplog може да издържи по време на първоначалното синхронизиране, най-старите операции „изчезват“. Вторичната разпознава, че не всички операции са налични, необходими за „конструиране“ на същите данни като основната и отказва да завърши синхронизирането, оставайки в RECOVERY режим.

Решението(ата)

Проблемът е известен и не е грешка, а резултат от вътрешната работа на MongoDB и няколко предположения за безопасност, направени от екипа за разработка. Следователно има няколко начина за справяне със ситуацията. За съжаление, тъй като имате само два възела, носещи данни, всички включват прекъсване.

Опция 1:Увеличете размера на oplog

Това е предпочитаният от мен метод, тъй като се справя с проблема веднъж и (донякъде) завинаги. Това обаче е малко по-сложно от други решения. От гледна точка на високо ниво, това са стъпките, които предприемате.

1. Изключете основния
2. Създайте резервно копие на oplog, като използвате директен достъп до файловете с данни
3. Рестартирайте mongod в самостоятелен режим
4. Копирайте текущия oplog във временна колекция
5. Изтриване на текущия oplog
6. Пресъздайте oplog с желания размер
7. Копирайте обратно записите в oplog от временната колекция в лъскавия нов oplog
8. Рестартирайте mongod като част от комплекта реплики

Не забравяйте да увеличите oplog на вторичния, преди да извършите първоначалното синхронизиране, тъй като той може да стане основен по някое време в бъдеще!

За подробности, моля, прочетете "Промяна на размера на oplog" в уроците относно поддръжката на комплект реплики .

Опция 2:Изключете приложението по време на синхронизиране

Ако опция 1 не е жизнеспособна, единственото реално друго решение е да изключите приложението, причиняващо натоварване на комплекта реплики, да рестартирате синхронизирането и да изчакате да завърши. В зависимост от количеството на данните, които трябва да се прехвърлят, изчислете с няколко часа.

Лична бележка

Проблемът с прозореца на oplog е добре известен. Въпреки че наборите реплики и шардираните клъстери са лесни за настройка с MongoDB, са необходими доста познания и малко опит, за да се поддържат правилно. Не стартирайте нещо толкова важно като база данни със сложна настройка, без да знаете основите - в случай че се случи нещо лошо (tm), това може да доведе до ситуация FUBAR.