Om du är värd för ditt MongoDB-kluster i Amazon AWS USA-östra regionen, har den senaste månaden varit ganska intressant – två avbrott på fyra veckor har testat hur beredskapen är för ditt moln utplaceringar. När jag skriver det här blogginlägget upplever Sao Paulo-regionen också anslutningsproblem. Ett överraskande antal produktionsdatabaser överlevde inte AWS-avbrottet. Vi hade möjlighet att prata med ett antal MongoDB på AWS-kunder för att förstå hur avbrottet påverkade deras implementeringar. Jag tog en snabb undersökning av drabbade individer, och här är de fyra huvudsakliga anledningarna till att team upplevde driftstopp:
-
Köra en fristående instans kontra en replikuppsättning
Om du kör en MongoDB-produktionsserver finns det egentligen ingen ursäkt för att köra en fristående instans kontra en replikuppsättning. Skapa en replikuppsättning så att du kan ha en sekundär till failover i händelse av primärt fel.
-
Distribuerar inte repliker över tillgänglighetszoner
Se till att du distribuerar dina repliker över olika tillgänglighetszoner i en region. På så sätt, om en enstaka A-Ö går ner, som det hände två gånger denna månad, kommer dina återstående servrar att ta över och du kommer att ha ett fungerande kluster. Om din region bara har två A-Ö, placera din domare i en annan region. Detta kommer dock inte att hjälpa dig om hela regionen går under. Om du vill överleva hela AWS-regionfel måste du distribuera din replikuppsättning över olika regioner.
-
Distribuerar inte dina gränssnitt eller appservrar över tillgänglighetszoner
Se till att du distribuerar dina gränssnitt över olika tillgänglighetszoner. Det är ingen idé att ha din databas igång om din front-end är nere. Om du har kostnadsproblem kan du hålla ett uppdaterat gränssnitt "stoppat" i varje A-Ö som du kan aktivera vid behov. Ett annat alternativ är att ha mindre front-ends.
-
Anslut till replikuppsättningen kontra en enda server i din anslutningssträng
Se till att du ansluter till replikuppsättningen istället för en enda server. Syntaxen är olika för olika drivrutiner, men kontrollera din drivrutinsdokumentation för att säkerställa att du använder rätt syntax för att ansluta till replikuppsättningen istället för en enda server. På detta sätt, om det finns en failover, kommer MongoDB-drivrutinen att göra rätt sak och ansluta till den nya primära.
På ScaleGrid automatiserar vi alla operativa aspekter av din implementering så att du kan fokusera på din app och inte oroa dig för driften. När du skapar en MongoDB-replikuppsättning med ScaleGrid distribuerar vi automatiskt replikerna över tillgänglighetszoner. På grund av denna distribution har alla våra kunder kunnat navigera säkert i AWS-avbrottsproblemet. Om du är intresserad av en mer detaljerad läsning om de operativa aspekterna av MongoDB kan du läsa mitt tidigare detaljerade blogginlägg – 10 frågor att ställa och svara när du är värd för MongoDB på AWS