Als u uw MongoDB-cluster host in de regio Amazon AWS VS-Oost, was de afgelopen maand redelijk interessant:twee storingen in vier weken hebben de operationele gereedheid van uw cloud op de proef gesteld implementaties. Terwijl ik deze blogpost typ, ondervindt de regio van Sao Paulo ook verbindingsproblemen. Een verrassend aantal productiedatabases heeft de AWS-storing niet overleefd. We hadden de gelegenheid om met een aantal MongoDB op AWS-klanten te praten om te begrijpen hoe de storing hun implementaties beïnvloedde. Ik heb een snelle enquête gehouden onder getroffen personen en hier zijn de vier belangrijkste redenen waarom teams downtime ondervonden:
-
Een zelfstandige instantie uitvoeren versus een replicaset
Als u een MongoDB-productieserver gebruikt, is er geen excuus om een zelfstandige instantie in plaats van een replicaset uit te voeren. Maak een replicaset zodat u een secundaire naar een failover kunt hebben in het geval van een primaire storing.
-
Geen replica's distribueren over beschikbaarheidszones
Zorg ervoor dat u uw replica's distribueert over verschillende beschikbaarheidszones in een regio. Op deze manier, als een enkele AZ uitvalt, zoals deze maand twee keer is gebeurd, nemen je resterende servers het over en heb je een functionerend cluster. Als uw regio slechts twee AZ's heeft, plaatst u uw arbiter in een andere regio. Dit zal je echter niet helpen als de hele regio ten onder gaat. Als u een volledige storing in de AWS-regio wilt overleven, moet u uw replicaset over verschillende regio's distribueren.
-
Uw front-ends of app-servers niet verdelen over beschikbaarheidszones
Zorg ervoor dat u uw front-ends verdeelt over verschillende beschikbaarheidszones. Het heeft geen zin om uw database up-and-running te hebben als uw front-end niet werkt. Als u kostenproblemen heeft, kunt u in elke AZ een up-to-date front-end 'stoppen' houden die u kunt inschakelen als dat nodig is. Een andere optie is om kleinere front-ends te hebben.
-
Maak verbinding met de replicaset versus een enkele server in uw verbindingsreeks
Zorg ervoor dat u verbinding maakt met de replicaset in plaats van met een enkele server. De syntaxis is verschillend voor verschillende stuurprogramma's, maar controleer uw stuurprogrammadocumentatie om er zeker van te zijn dat u de juiste syntaxis gebruikt om verbinding te maken met de replicaset in plaats van met een enkele server. Op deze manier, als er een failover is, zal het MongoDB-stuurprogramma het juiste doen en verbinding maken met de nieuwe primaire.
Bij ScaleGrid automatiseren we alle operationele aspecten van uw implementatie, zodat u zich kunt concentreren op uw app en u zich geen zorgen hoeft te maken over de bewerkingen. Wanneer u een MongoDB-replicaset maakt met ScaleGrid, distribueren we de replica's automatisch over beschikbaarheidszones. Dankzij deze distributie hebben al onze klanten het probleem met de downtime van AWS veilig kunnen oplossen. Als je meer wilt weten over de operationele aspecten van MongoDB, kun je mijn eerdere gedetailleerde blogpost lezen - 10 vragen die je moet stellen en beantwoorden bij het hosten van MongoDB op AWS