Problemet (mest troligt)
Den sista operationen på den primära är från "2015-05-15T02:10:56Z", medan den sista operationen för den som kommer att bli sekundär är från "2015-05-14T11:23:51Z", vilket är en skillnad på ungefär 15 timmar. Det fönstret kan mycket väl överskrida ditt replikeringsoplogfönster (skillnaden mellan tidpunkten för den första och den sista operationsposten i din oplog). Enkelt uttryckt är det för många operationer på primären för att sekundären ska hinna med.
Lite mer utarbetat (men förenklat):under en inledande synkronisering är data som sekundären synkroniserar från data för en given tidpunkt. När datan för den tidpunkten synkroniseras, ansluter sekundären till oploggen och tillämpar ändringarna som gjordes mellan nämnda tidpunkt och nu enligt oplogposterna. Detta fungerar bra så länge oploggen håller alla operationer mellan nämnda tidpunkt. Men oploggen har en begränsad storlek (det är en så kallad begränsad samling
). Så om det händer fler operationer på den primära än oploggen kan hålla under den initiala synkroniseringen, "fade" de äldsta operationerna ut. Den sekundära inser att inte alla operationer är tillgängliga för att "konstruera" samma data som den primära och vägrar att slutföra synkroniseringen och stannar i RECOVERY
läge.
Lösningen/lösningarna
Problemet är känt och inte en bugg, utan ett resultat av MongoDB:s inre funktioner och flera felsäkra antaganden från utvecklingsteamet. Därför finns det flera sätt att hantera situationen. Tyvärr, eftersom du bara har två databärande noder, innebär alla driftstopp.
Alternativ 1:Öka oplogstorleken
Detta är min föredragna metod, eftersom den hanterar problemet en gång och (typ) för alla. Det är dock lite mer komplicerat än andra lösningar. Ur ett perspektiv på hög nivå är det här stegen du tar.
- Stäng av den primära
- Skapa en säkerhetskopia av oploggen med direktåtkomst till datafilerna
- Starta om
mongod
i fristående läge - Kopiera den aktuella oploggen till en tillfällig samling
- Ta bort den aktuella oploggen
- Återskapa oploggen med önskad storlek
- Kopiera tillbaka oplogposterna från den tillfälliga samlingen till den skinande nya oploggen
- Starta om
mongod
som en del av replikuppsättningen
Glöm inte att öka oploggen för sekundären innan du gör den första synkroniseringen, eftersom den kan bli primär någon gång i framtiden!
För detaljer, läs "Ändra storleken på oploggen" i handledningarna om replikuppsättningsunderhåll .
Alternativ 2:Stäng av appen under synkronisering
Om alternativ 1 inte är genomförbart är den enda verkliga andra lösningen att stänga av applikationen som orsakar belastning på replikuppsättningen, starta om synkroniseringen och vänta på att den är för klar. Beräkna med flera timmar, beroende på mängden data som ska överföras.
En personlig kommentar
Problemet med oplog-fönster är välkänt. Även om replikuppsättningar och fragmenterade kluster är lätta att konfigurera med MongoDB, behövs en hel del kunskap och lite erfarenhet för att underhålla dem ordentligt. Kör inte något så viktigt som en databas med en komplicerad installation utan att känna till grunderna - om Something Bad (tm) inträffar kan det mycket väl leda till en situation FUBAR.