Jeśli hostujesz klaster MongoDB w regionie Amazon AWS US-East, ostatni miesiąc był dość interesujący – dwie awarie w ciągu czterech tygodni przetestowały gotowość operacyjną Twojej chmury wdrożenia. Kiedy piszę ten wpis na blogu, region Sao Paulo również ma problemy z łącznością. Zaskakująca liczba produkcyjnych baz danych nie przetrwała awarii AWS. Mieliśmy okazję porozmawiać z wieloma klientami MongoDB na AWS, aby zrozumieć, jak awaria wpłynęła na ich wdrożenia. Przeprowadziłem krótką ankietę wśród osób dotkniętych problemem i oto cztery główne powody, dla których zespoły doświadczyły przestojów:
-
Uruchamianie samodzielnej instancji w porównaniu z zestawem replik
Jeśli używasz produkcyjnego serwera MongoDB, naprawdę nie ma wymówki, aby uruchomić samodzielną instancję zamiast zestawu replik. Utwórz zestaw replik, aby w przypadku awarii podstawowej móc mieć zapasową do przełączania awaryjnego.
-
Brak dystrybucji replik w strefach dostępności
Zapewnij dystrybucję replik w różnych strefach dostępności w regionie. W ten sposób, jeśli jeden AZ ulegnie awarii, jak to się zdarzyło dwa razy w tym miesiącu, pozostałe serwery przejmą kontrolę i będziesz mieć działający klaster. Jeśli twój region ma tylko dwa AZ, umieść swojego arbitra w innym regionie. To jednak nie pomoże, jeśli cały region upadnie. Jeśli chcesz przetrwać awarię całego regionu AWS, musisz rozmieścić swój zestaw replik w różnych regionach.
-
Brak dystrybucji front-endów lub serwerów aplikacji w strefach dostępności
Upewnij się, że rozprowadzasz interfejsy w różnych strefach dostępności. Nie ma sensu mieć działającej bazy danych, jeśli Twój front-end nie działa. Jeśli masz problemy z kosztami, możesz zachować aktualny front-end „zatrzymany” w każdym AZ, który możesz włączyć w razie potrzeby. Inną opcją jest posiadanie nakładek o mniejszych rozmiarach.
-
Połącz się z zestawem replik a pojedynczym serwerem w ciągu połączenia
Upewnij się, że łączysz się z zestawem replik zamiast z pojedynczym serwerem. Składnia jest różna dla różnych sterowników, ale sprawdź dokumentację sterownika, aby upewnić się, że używasz właściwej składni do łączenia się z zestawem replik zamiast z pojedynczym serwerem. W ten sposób, jeśli nastąpi awaria, sterownik MongoDB zrobi właściwą rzecz i połączy się z nową bazą.
W ScaleGrid automatyzujemy wszystkie aspekty operacyjne wdrożenia, dzięki czemu możesz skupić się na swojej aplikacji i nie martwić się o operacje. Podczas tworzenia zestawu replik MongoDB za pomocą ScaleGrid automatycznie dystrybuujemy repliki w strefach dostępności. Dzięki tej dystrybucji wszyscy nasi klienci mogli bezpiecznie poruszać się po problemie z przestojami AWS. Jeśli interesuje Cię bardziej szczegółowa lektura na temat operacyjnych aspektów MongoDB, możesz przeczytać mój wcześniejszy szczegółowy post na blogu – 10 pytań, które należy zadać i odpowiedzieć podczas hostowania MongoDB na AWS
