Hvis du hoster din MongoDB-klynge i Amazon AWS USA-Øst-regionen, har den sidste måned været ret interessant – to udfald på fire uger har testet din skys operationelle parathed indsættelser. Mens jeg skriver dette blogindlæg, oplever Sao Paulo-regionen også forbindelsesproblemer. Et overraskende antal produktionsdatabaser overlevede ikke AWS-afbrydelsen. Vi havde mulighed for at tale med en række MongoDB på AWS-kunder for at forstå, hvordan udfaldet påvirkede deres implementeringer. Jeg tog en hurtig undersøgelse af berørte personer, og her er de fire hovedårsager til, at teams oplevede nedetid:
-
Kørsel af en selvstændig instans vs. et replikasæt
Hvis du kører en MongoDB-produktionsserver, er der virkelig ingen undskyldning for at køre en selvstændig instans i forhold til et replikasæt. Opret et replikasæt, så du kan have en sekundær til failover i tilfælde af primær fejl.
-
Distribuerer ikke replikaer på tværs af tilgængelighedszoner
Sørg for, at du distribuerer dine replikaer på tværs af forskellige tilgængelighedszoner i en region. På denne måde, hvis en enkelt AZ går ned, som det skete to gange i denne måned, vil dine resterende servere tage over, og du vil have en fungerende klynge. Hvis din region kun har to AZ'er, skal du placere din dommer i en anden region. Dette vil dog ikke hjælpe dig, hvis hele regionen går ned. Hvis du vil overleve hele AWS-regionsfejl, bliver du nødt til at distribuere dit replikasæt på tværs af forskellige regioner.
-
Distribuerer ikke dine frontends eller appservere på tværs af tilgængelighedszoner
Sørg for at distribuere dine frontends på tværs af forskellige tilgængelighedszoner. Det nytter ikke at have din database oppe og køre, hvis din frontend er nede. Hvis du har omkostningsproblemer, kan du holde en opdateret front-end 'stoppet' i hver AZ, som du kan slå til i tilfælde af et behov. En anden mulighed er at have front-ends i mindre størrelse.
-
Opret forbindelse til replikasættet vs. en enkelt server i din forbindelsesstreng
Sørg for at oprette forbindelse til replikasættet i stedet for en enkelt server. Syntaksen er forskellig for forskellige drivere, men tjek din driverdokumentation for at sikre, at du bruger den rigtige syntaks til at oprette forbindelse til replikasættet i stedet for en enkelt server. På denne måde, hvis der er en failover, vil MongoDB-driveren gøre det rigtige og oprette forbindelse til den nye primære.
Hos ScaleGrid automatiserer vi alle de operationelle aspekter af din implementering, så du kan fokusere på din app og ikke bekymre dig om driften. Når du opretter et MongoDB replikasæt med ScaleGrid, distribuerer vi automatisk replikaerne på tværs af tilgængelighedszoner. På grund af denne distribution har alle vores kunder været i stand til sikkert at navigere i AWS-nedetidsproblemet. Hvis du er interesseret i en mere detaljeret læsning om de operationelle aspekter af MongoDB, kan du læse mit tidligere detaljerede blogindlæg - 10 spørgsmål at stille og besvare, når du hoster MongoDB på AWS