Het probleem (waarschijnlijk)
De laatste bewerking op de primaire is van "2015-05-15T02:10:56Z", terwijl de laatste bewerking van de secundaire is van "2015-05-14T11:23:51Z", wat een verschil is van ongeveer 15 uur. Dat venster kan uw replicatie-oplog-venster (het verschil tussen de tijd van de eerste en de laatste bewerkingsinvoer in uw oplog) ruimschoots overschrijden. Simpel gezegd, er zijn te veel bewerkingen op de primaire voor de secundaire om in te halen.
Iets uitgebreider (hoewel vereenvoudigd):tijdens een eerste synchronisatie zijn de gegevens van de secundaire synchronisatie de gegevens van een bepaald tijdstip. Wanneer de gegevens van dat tijdstip worden gesynchroniseerd, maakt de secundaire verbinding met de oplog en past de wijzigingen toe die zijn aangebracht tussen dat tijdstip en nu volgens de oplog-vermeldingen. Dit werkt goed zolang de oplog alle bewerkingen tussen het genoemde tijdstip vasthoudt. Maar de oplog heeft een beperkte omvang (het is een zogenaamde capped collection
). Dus als er meer bewerkingen plaatsvinden op de primaire dan de oplog kan bevatten tijdens de eerste synchronisatie, verdwijnen de oudste bewerkingen. De secundaire herkent dat niet alle bewerkingen beschikbaar zijn die nodig zijn om dezelfde gegevens te "construeren" als de primaire en weigert de synchronisatie te voltooien en blijft in RECOVERY modus.
De oplossing(en)
Het probleem is bekend en geen bug, maar een resultaat van de interne werking van MongoDB en verschillende faalveilige aannames van het ontwikkelingsteam. Er zijn dus verschillende manieren om met de situatie om te gaan. Helaas, aangezien je maar twee data-dragende nodes hebt, brengen ze allemaal downtime met zich mee.
Optie 1:Vergroot de oplog-grootte
Dit is mijn voorkeursmethode, omdat het het probleem voor eens en (soort van) voor altijd aanpakt. Het is echter een beetje ingewikkelder dan andere oplossingen. Vanuit een hoogstaand perspectief zijn dit de stappen die u neemt.
- Sluit de primaire af
- Maak een back-up van de oplog met directe toegang tot de gegevensbestanden
- Herstart de
mongodin zelfstandige modus - Kopieer de huidige oplog naar een tijdelijke verzameling
- De huidige oplog verwijderen
- Maak de oplog opnieuw met de gewenste maat
- Kopieer de oplog-items van de tijdelijke collectie terug naar de glanzende nieuwe oplog
- Herstart
mongodals onderdeel van de replicaset
Vergeet niet om de oplog van de secundaire te verhogen voordat u de eerste synchronisatie uitvoert, aangezien deze op een bepaald moment in de toekomst primair kan worden!
Lees voor details "Verander de grootte van de oplog" in de tutorials over onderhoud van replicasets .
Optie 2:sluit de app af tijdens synchronisatie
Als optie 1 niet haalbaar is, is de enige echte andere oplossing om de toepassing af te sluiten die de replicaset belast, de synchronisatie opnieuw te starten en te wachten tot deze te voltooid is. Reken, afhankelijk van de hoeveelheid gegevens die moet worden overgedragen, met enkele uren.
Een persoonlijke noot
Het oplog-vensterprobleem is een bekend probleem. Hoewel replicasets en sharded-clusters eenvoudig zijn in te stellen met MongoDB, is er behoorlijk wat kennis en een beetje ervaring nodig om ze goed te onderhouden. Voer niet zoiets belangrijks uit als een database met een complexe setup zonder de basis te kennen - als er iets ergs (tm) gebeurt, kan dit leiden tot een situatie FUBAR.