W MongoDB duże zbiory danych obejmują operacje o wysokiej przepustowości, co może przeciążyć pojemność pojedynczego serwera . Duże zestawy danych roboczych powodują większe obciążenie pojemności we/wy urządzeń dyskowych i mogą prowadzić do problemów, takich jak błędy strony.
Są głównie dwa sposoby rozwiązania tego...
- Skalowanie w pionie :zwiększenie pojemności pojedynczego serwera. Osiągnięto dzięki dodaniu większej ilości procesora, pamięci RAM i przestrzeni dyskowej, ale z ograniczeniem:dostępna technologia może ograniczać wydajność pojedynczego komputera w przypadku niektórych obciążeń. Praktycznie istnieje maksimum dla skalowania w pionie.
- Skalowanie poziome poprzez fragmentowanie :Wiąże się to z podzieleniem zestawu danych systemowych na wiele serwerów, a tym samym zmniejszeniem ogólnego obciążenia pojedynczego serwera. Rozszerzenie możliwości wdrożenia wymaga jedynie dodania większej liczby serwerów w celu obniżenia ogólnych kosztów niż sprzęt wysokiej klasy dla pojedynczej maszyny. Jednak wiąże się to z kompromisem polegającym na tym, że infrastruktura i konserwacja wdrożenia będą bardzo złożoności. Złożoność staje się bardziej wyrafinowana podczas rozwiązywania problemów z klastrem podzielonym na fragmenty w przypadku awarii. Na tym blogu przedstawiamy niektóre z możliwości rozwiązywania problemów, które mogą pomóc:
- Wybieranie kluczy fragmentów i dostępności klastra
- Instancja Mongos staje się niedostępna
- Członek jest nieobecny w zestawie replik fragmentów
- Wszyscy członkowie zestawu replik są nieobecni
- Nieaktualne dane konfiguracyjne prowadzą do awarii kursora
- Serwer konfiguracji staje się niedostępny
- Naprawianie błędu ciągu bazy danych
- Unikanie przestojów podczas przenoszenia serwerów konfiguracyjnych
Wybieranie kluczy fragmentów i dostępności klastra
Sharding polega na podzieleniu danych na małe grupy zwane fragmentami, aby zmniejszyć ogólne obciążenie pracą dla danej przepustowości operacja. Grupowanie to osiąga się poprzez wybór optymalnego klucza, który jest przede wszystkim najważniejszą częścią przed shardingiem. Optymalny klucz powinien zapewniać:
- Mongos może wyizolować większość zapytań do konkretnego mongoda. Jeśli na przykład więcej operacji zostanie poddanych jednemu fragmentowi, awaria tego fragmentu spowoduje, że dane powiązane z nim będą w tym czasie nieobecne. Wskazane jest, aby wybrać klucz fragmentu, który da więcej fragmentów, aby zmniejszyć ilość niedostępności danych w przypadku awarii fragmentu.
- MongoDB będzie w stanie podzielić dane równomiernie na porcje. Gwarantuje to, że operacje przepustowości będą również równomiernie rozłożone, zmniejszając ryzyko niepowodzenia z powodu większego obciążenia pracą.
- Skalowalność zapisu w klastrze w celu zapewnienia wysokiej dostępności. Każdy fragment powinien być zestawem replik, tak aby w przypadku awarii pewnej instancji mongod pozostali członkowie zestawu replik byli w stanie wybrać innego członka jako podstawowy, zapewniając w ten sposób ciągłość działania.
Jeśli w jakimkolwiek przypadku dany fragment ma tendencję do niepowodzenia, zacznij od sprawdzenia, ile operacji przepustowości czy podlega i rozważ wybór lepszego klucza shardingu, aby mieć więcej shardów.
Co jeśli? Instancja Mongos przestaje działać
Najpierw sprawdź, czy łączysz się z właściwym portem, ponieważ mogłeś dokonać nieświadomej zmiany. Na przykład w przypadku wdrożenia z platformą AWS istnieje prawdopodobieństwo wystąpienia tego problemu ze względu na grupy zabezpieczeń, które mogą nie zezwalać na połączenia na tym porcie. Aby przeprowadzić natychmiastowy test, spróbuj określić pełny host:port, aby upewnić się, że używasz interfejsu pętli zwrotnej. Dobrą rzeczą jest to, że jeśli każdy serwer aplikacji ma własną instancję mongos, serwery aplikacji mogą nadal uzyskiwać dostęp do bazy danych. Poza tym stany instancji mongos zmieniają się z czasem i mogą zostać ponownie uruchomione bez konieczności utraty danych. Gdy instancja zostanie ponownie podłączona, pobierze kopię bazy danych konfiguracji i rozpocznie zapytania routingu.
Upewnij się, że port, z którym próbujesz połączyć się ponownie, nie jest również zajęty przez inny proces.
Co jeśli? Członek zostaje nieobecny w zestawie replik Shard
Zacznij od sprawdzenia stanu fragmentu, uruchamiając polecenie sh.status(). Jeśli zwrócony wynik nie ma identyfikatora klastra, fragment jest rzeczywiście niedostępny. Zawsze sprawdzaj przerwy w dostępności i awarie, a jeśli nie możesz odzyskać go w jak najkrótszym czasie, utwórz nowego członka, aby go jak najszybciej zastąpić, aby uniknąć większej utraty danych.
Jeśli dodatkowy element członkowski stanie się niedostępny, ale z aktualnymi wpisami oplog, po ponownym połączeniu może nadrobić najnowszy stan zestawu poprzez odczytywanie bieżących danych z oploga jako normalny proces replikacji. Jeśli nie uda się zreplikować danych, musisz przeprowadzić początkową synchronizację, korzystając z jednej z tych dwóch opcji...
- Uruchom ponownie mongod z pustym katalogiem danych i pozwól normalnej funkcji początkowej synchronizacji MongoDB przywrócić dane. Jednak takie podejście zajmuje dużo czasu, aby skopiować dane, ale jest całkiem proste.
- Uruchom ponownie komputer hosta z kopią ostatniego katalogu danych z innego elementu w zestawie replik. Szybki proces, ale ze skomplikowanymi krokami
Początkowa synchronizacja umożliwi MongoDB...
- Klonuj wszystkie dostępne bazy danych z wyjątkiem lokalna baza danych. Upewnij się, że docelowy członek ma wystarczającą ilość miejsca na dysku w lokalnej bazie danych, aby tymczasowo przechowywać rekordy oplog na czas kopiowania danych.
- Zastosuj wszystkie zmiany do zbioru danych za pomocą oploga ze źródła. Proces zostanie zakończony tylko wtedy, gdy status repliki zmieni się z STARTUP2 na SECONDARY.
Co jeśli? Wszyscy członkowie zestawu replik są nieobecni
Dane przechowywane we fragmencie będą niedostępne, jeśli wszyscy członkowie fragmentu zestawu replik staną się nieobecni. Ponieważ inne fragmenty pozostają dostępne, operacje odczytu i zapisu są nadal możliwe, z wyjątkiem tego, że aplikacja będzie obsługiwana z częściowymi danymi. Musisz zbadać przyczynę przerw i jak najszybciej spróbować ponownie aktywować fragment. Sprawdź, który profiler zapytań lub metodę wyjaśnienia, co mogło doprowadzić do tego problemu.
Co jeśli? Nieaktualne dane konfiguracyjne prowadzą do awarii kursora
Czasami instancji Mongos może zająć dużo czasu, aby zaktualizować pamięć podręczną metadanych z bazy danych konfiguracji, co prowadzi do zwrócenia zapytania ostrzeżenie:
could not initialize cursor across all shards because : stale config detectedTen błąd będzie zawsze wyświetlany, dopóki instancje mongos nie odświeżą swoich pamięci podręcznych. Nie powinno to rozprzestrzeniać się z powrotem do aplikacji. Aby to naprawić, musisz wymusić odświeżenie instancji, uruchamiając fluRouterConfig.
Aby opróżnić pamięć podręczną dla określonego uruchomienia kolekcji
db.adminCommand({ flushRouterConfig: "<db.collection>" } )Opróżnianie pamięci podręcznej dla określonego uruchomienia bazy danych
db.adminCommand({ flushRouterConfig: "<db>" } )Aby opróżnić pamięć podręczną dla wszystkich baz danych i ich kolekcji uruchom:
db.adminCommand("flushRouterConfig")
db.adminCommand( { flushRouterConfig: 1 } )Co jeśli? Serwer konfiguracyjny staje się niedostępny
Serwer konfiguracji w tym przypadku można uznać za podstawowy element członkowski, z którego węzły dodatkowe replikują swoje dane. Jeśli go nie ma, dostępne węzły drugorzędne będą musiały wybrać jednego spośród swoich członków, aby stał się głównym. Aby uniknąć sytuacji, w której możesz nie mieć serwera konfiguracyjnego, rozważ rozmieszczenie elementów zestawu replik w dwóch centrach danych, ponieważ...
- Jeśli jedno centrum danych ulegnie awarii, dane będą nadal dostępne do odczytu, a nie żadnych operacji, jeśli korzystasz z jednego centrum danych .
- Jeśli centrum danych, które obejmuje członków mniejszościowych, ulegnie awarii, zestaw replik nadal może obsługiwać zarówno operacje zapisu, jak i odczytu.
Wskazane jest rozmieszczenie członków w co najmniej trzech centrach danych.
Inną możliwością dystrybucji jest równomierne rozmieszczenie elementów zawierających dane w dwóch centrach danych i pozostałych w chmura.
Naprawianie błędu ciągu bazy danych
Począwszy od MongoDB 3.4, serwery konfiguracji SCCC nie są obsługiwane w przypadku dublowanych instancji mongod. Jeśli chcesz uaktualnić swój klaster podzielonego na fragmenty do wersji 3.4, musisz przekonwertować serwery konfiguracyjne z SCCC na CSRS.
Unikanie przestojów podczas przenoszenia serwerów konfiguracji
Przestój może wystąpić w wyniku pewnych czynników, takich jak przerwa w dostawie prądu lub częstotliwość sieci, co powoduje awaria serwera konfiguracji w klastrze. Użyj CNAME, aby zidentyfikować serwer do zmiany nazwy lub numeracji podczas ponownego połączenia. Jeśli polecenie zatwierdzenia moveChunk nie powiedzie się podczas procesu migracji, MongoDB zgłosi błąd:
ERROR: moveChunk commit failed: version is at <n>|<nn> instead of
<N>|<NN>" and "ERROR: TERMINATING"Oznacza to, że shard nie został również połączony z bazą danych konfiguracji, dlatego podstawowa zakończy tego członka aby uniknąć niespójności danych. Niepowodzenie migracji porcji należy rozwiązać niezależnie, konsultując się z pomocą techniczną MongoDB. Upewnij się również, że zapewniono klastrom pewne stabilne zasoby, takie jak sieć i zasilanie.
Wniosek
Klaster z fragmentacją MongoDB zmniejsza obciążenie, któremu podlegałby pojedynczy serwer, co poprawia wydajność operacji przepustowości. Jednak niepoprawne skonfigurowanie niektórych parametrów, takich jak wybór optymalnego klucza fragmentu, może spowodować nierównowagę obciążenia, dlatego niektóre fragmenty kończą się niepowodzeniem.
Zakładając, że konfiguracja została wykonana poprawnie, mogą wystąpić pewne nieuniknione niepowodzenia, takie jak przerwy w dostawie prądu. Aby kontynuować obsługę aplikacji przy minimalnym przestoju, rozważ użycie co najmniej 3 centrów danych. Jeśli jeden się nie powiedzie, pozostałe będą dostępne do obsługi operacji odczytu, jeśli podstawowy znajduje się wśród członków, których dotyczy problem. Zaktualizuj również swój system do co najmniej wersji 3.4, ponieważ obsługuje więcej funkcji.
