Nekonečný zotavující se stav sekundární

Problém (s největší pravděpodobností)

Poslední operace na primární je z "2015-05-15T02:10:56Z", zatímco poslední operace bude sekundární je z "2015-05-14T11:23:51Z", což je rozdíl zhruba 15 hodin. Toto okno může značně přesáhnout vaše okno replikačního oplogu (rozdíl mezi časem prvního a posledního záznamu operace ve vašem oplogu). Jednoduše řečeno, na primární části je příliš mnoho operací na to, aby je sekundární stihla.

Trochu propracovanější (i když zjednodušené):během počáteční synchronizace jsou data, ze kterých se sekundární synchronizuje, data daného okamžiku. Když jsou data tohoto časového okamžiku synchronizována, sekundární se připojí k oplogu a aplikuje změny, které byly provedeny mezi uvedeným časovým okamžikem a nyní podle záznamů oplogu. To funguje dobře, pokud oplog obsahuje všechny operace mezi zmíněným bodem v čase. Oplog má ale omezenou velikost (jedná se o takzvanou omezenou kolekci ). Pokud tedy na primárním zařízení probíhá více operací, než může oplog pojmout během počáteční synchronizace, nejstarší operace „vyblednou“. Sekundární rozpozná, že nejsou k dispozici všechny operace nutné k „konstruování“ stejných dat jako primární, a odmítne dokončit synchronizaci a zůstane v RECOVERY režimu.

Řešení

Problém je známý, nejedná se o chybu, ale je výsledkem vnitřního fungování MongoDB a několika předpokladů zabezpečení proti selhání vytvořených vývojovým týmem. Existuje tedy několik způsobů, jak situaci řešit. Bohužel, protože máte pouze dva datové uzly, všechny zahrnují prostoje.

Možnost 1:Zvětšete velikost oplog

Toto je moje preferovaná metoda, protože řeší problém jednou a (tak trochu) pro vždy. Je to však o něco složitější než jiná řešení. Z pohledu vysoké úrovně jsou to kroky, které podniknete.

1. Vypnout primární
2. Vytvořte zálohu oplogu pomocí přímého přístupu k datovým souborům
3. Restartujte mongod v samostatném režimu
4. Zkopírujte aktuální oplog do dočasné kolekce
5. Smazat aktuální oplog
6. Znovu vytvořte oplog s požadovanou velikostí
7. Zkopírujte zpět položky oplogu z dočasné kolekce do zbrusu nového oplogu
8. Restartujte mongod jako součást sady replik

Nezapomeňte zvýšit oplog sekundárního bloku před provedením počáteční synchronizace, protože se může někdy v budoucnu stát primárním!

Podrobnosti naleznete v části "Změnit velikost oplogu" ve výukových programech týkajících se údržby sady replik .

Možnost 2:Vypněte aplikaci během synchronizace

Pokud možnost 1 není životaschopná, jediným skutečným jiným řešením je vypnout aplikaci způsobující zatížení sady replik, restartovat synchronizaci a počkat, až bude příliš dokončena. V závislosti na množství přenášených dat počítejte s několika hodinami.

Osobní poznámka

Problém okna oplog je dobře známý. Zatímco sady replik a sharded clustery se s MongoDB nastavují snadno, k jejich správné údržbě jsou potřeba určité znalosti a trochu zkušeností. Nespouštějte něco tak důležitého, jako je databáze se složitým nastavením, aniž byste znali základy – v případě, že se stane Něco špatného (tm), může to vést k situaci FUBAR.