Problemet (mest sandsynligt)
Den sidste operation på den primære er fra "2015-05-15T02:10:56Z", mens den sidste operation af den, der bliver sekundær, er fra "2015-05-14T11:23:51Z", hvilket er en forskel på ca. 15 timer. Dette vindue kan meget vel overstige dit replikeringsoplog-vindue (forskellen mellem tidspunktet for den første og den sidste operationsindtastning i din oplog). Kort sagt er der for mange operationer på den primære til, at den sekundære kan indhente det.
Lidt mere uddybet (dog forenklet):under en indledende synkronisering er de data, som den sekundære synkroniseres fra, dataene for et givet tidspunkt. Når dataene for det pågældende tidspunkt er synkroniseret over, forbinder den sekundære til oploggen og anvender de ændringer, der blev foretaget mellem nævnte tidspunkt og nu i henhold til oplog-indtastningerne. Dette fungerer godt, så længe oploggen holder alle operationer mellem det nævnte tidspunkt. Men oploggen har en begrænset størrelse (det er en såkaldt begrænset samling
). Så hvis der sker flere operationer på den primære, end oploggen kan holde under den indledende synkronisering, "fader de ældste operationer ud". Den sekundære genkender, at ikke alle operationer er nødvendige for at "konstruere" de samme data som den primære, og nægter at fuldføre synkroniseringen og forbliver i RECOVERY tilstand.
Løsningen/løsningerne
Problemet er kendt og ikke en fejl, men et resultat af MongoDB's indre funktion og adskillige fejlsikre antagelser lavet af udviklingsteamet. Derfor er der flere måder at håndtere situationen på. Desværre, da du kun har to databærende noder, involverer alle nedetid.
Mulighed 1:Forøg oplogstørrelsen
Dette er min foretrukne metode, da den behandler problemet én gang for alle. Det er dog lidt mere kompliceret end andre løsninger. Fra et perspektiv på højt niveau er det disse trin, du tager.
- Luk den primære
- Opret en sikkerhedskopi af oploggen ved hjælp af direkte adgang til datafilerne
- Genstart
mongodi selvstændig tilstand - Kopiér den aktuelle oplog til en midlertidig samling
- Slet den aktuelle oplog
- Genopret oploggen med den ønskede størrelse
- Kopiér oplog-posterne tilbage fra den midlertidige samling til den skinnende nye oplog
- Genstart
mongodsom en del af replikasættet
Glem ikke at øge oplogen for den sekundære, før du udfører den indledende synkronisering, da den kan blive primær på et tidspunkt i fremtiden!
For detaljer, læs venligst "Skift størrelsen på oploggen" i selvstudierne vedrørende vedligeholdelse af replikasæt .
Mulighed 2:Luk appen ned under synkronisering
Hvis mulighed 1 ikke er levedygtig, er den eneste rigtige anden løsning at lukke applikationen ned, der forårsager belastning på replikasættet, genstarte synkroniseringen og vente på, at den er for fuldført. Afhængig af mængden af data, der skal overføres, beregnes med flere timer.
En personlig bemærkning
Problemet med oplog-vinduet er velkendt. Mens replikasæt og sharded clusters er nemme at konfigurere med MongoDB, skal der en del viden og en smule erfaring til for at vedligeholde dem korrekt. Kør ikke noget så vigtigt som en database med en kompleks opsætning uden at kende det grundlæggende - i tilfælde af at Something Bad (tm) sker, kan det meget vel føre til en situation FUBAR.