Se stai ospitando il tuo cluster MongoDB nella regione Amazon AWS Stati Uniti orientali, l'ultimo mese è stato piuttosto interessante:due interruzioni in quattro settimane hanno testato la prontezza operativa del tuo cloud schieramenti. Mentre scrivo questo post sul blog, anche la regione di San Paolo sta riscontrando problemi di connettività. Un numero sorprendente di database di produzione non è sopravvissuto all'interruzione di AWS. Abbiamo avuto l'opportunità di parlare con diversi clienti di MongoDB su AWS per capire in che modo l'interruzione ha influito sulle loro distribuzioni. Ho svolto un rapido sondaggio sulle persone colpite ed ecco i quattro motivi principali per cui i team hanno subito tempi di inattività:
-
Esecuzione di un'istanza autonoma rispetto a un set di repliche
Se stai eseguendo un server MongoDB di produzione, non ci sono davvero scuse per eseguire un'istanza autonoma rispetto a un set di repliche. Crea un set di repliche in modo da poter disporre di un set secondario per il failover in caso di errore primario.
-
Mancata distribuzione delle repliche tra le zone di disponibilità
Assicurati di distribuire le tue repliche in diverse zone di disponibilità in una regione. In questo modo, se una singola AZ si interrompe, come è successo due volte questo mese, i tuoi server rimanenti prenderanno il controllo e avrai un cluster funzionante. Se la tua regione ha solo due AZ, posiziona il tuo arbitro in una regione diversa. Questo tuttavia non ti aiuterà se l'intera regione va giù. Se vuoi sopravvivere all'errore dell'intera regione AWS, dovrai distribuire il tuo set di repliche in diverse regioni.
-
Mancata distribuzione dei front-end o dei server delle app tra le zone di disponibilità
Assicurati di distribuire i tuoi front-end in diverse zone di disponibilità. Non ha senso avere il database attivo e funzionante se il front-end è inattivo. Se hai problemi di costi, puoi mantenere un front-end aggiornato "fermato" in ciascuna AZ che puoi attivare in caso di necessità. Un'altra opzione è quella di avere front-end di dimensioni inferiori.
-
Connettiti al set di repliche rispetto a un singolo server nella stringa di connessione
Assicurati di connetterti al set di repliche anziché a un singolo server. La sintassi è diversa per i diversi driver, ma controlla la documentazione del driver per assicurarti di utilizzare la sintassi corretta per connetterti al set di repliche anziché a un singolo server. In questo modo, se si verifica un failover, il driver MongoDB farà la cosa giusta e si connetterà al nuovo primario.
In ScaleGrid, automatizziamo tutti gli aspetti operativi della tua distribuzione in modo che tu possa concentrarti sulla tua app e non preoccuparti delle operazioni. Quando crei un set di repliche MongoDB con ScaleGrid, le repliche vengono distribuite automaticamente tra le zone di disponibilità. Grazie a questa distribuzione, tutti i nostri clienti sono stati in grado di affrontare in sicurezza il problema dei tempi di inattività di AWS. Se sei interessato a una lettura più dettagliata degli aspetti operativi di MongoDB, puoi leggere il mio precedente post dettagliato sul blog:10 domande a cui porre e rispondere quando si ospita MongoDB su AWS
