Uwagi dotyczące administrowania MongoDB

Poniżej znajduje się fragment naszego raportu „MongoDB Management and Automation with ClusterControl”, który można pobrać bezpłatnie.

Rozważania dotyczące administrowania MongoDB

Wbudowana nadmiarowość

Kluczową cechą MongoDB jest wbudowana nadmiarowość w postaci replikacji. Jeśli masz co najmniej dwa węzły danych, można je skonfigurować jako zestaw replik, w którym wszystkie dane zapisane w węźle głównym są replikowane w czasie zbliżonym do rzeczywistego do węzłów drugorzędnych,

zapewnienie wielu kopii danych. W przypadku przełączania awaryjnego podstawowego pozostałe węzły w zestawie replik przeprowadzają wybory i awansują zwycięzcę na podstawowy, co zwykle trwa 2-3 sekundy, a zapisy w zestawie replik można wznowić. MongoDB korzysta również z dziennika do szybszego i bezpieczniejszego zapisu na serwerze lub zestawie replik, a także wykorzystuje metodę „troski o zapis”, dzięki której konfiguruje się
poziom redundancji zapisu.

Aby ręcznie wdrożyć zestaw replik, ogólne kroki są następujące:

1. Przydziel jednego fizycznego lub wirtualnego hosta dla każdego węzła bazy danych i zainstaluj klienta wiersza poleceń MongoDB na swoim komputerze. W przypadku konfiguracji zestawu replik nadmiarowych wymagane są co najmniej trzy węzły, z których co najmniej dwa będą węzłami danych. Jeden węzeł w zestawie replik może być skonfigurowany jako arbiter:jest to proces mongod skonfigurowany tylko do tworzenia kworum poprzez oddanie głosu w wyborach Organizacji Podstawowej, gdy jest to wymagane. Dane nie są replikowane do procesów arbitrów.
2. Zainstaluj MongoDB na każdym węźle. Niektóre dystrybucje Linuksa zawierają MongoDB Community Edition, ale należy pamiętać, że mogą one nie zawierać najnowszych wersji. MongoDB Enterprise jest dostępny tylko do pobrania ze strony MongoDB. Podobna funkcjonalność do MongoDB Enterprise jest również dostępna za pośrednictwem Percona Server dla MongoDB, zamiennika dla MongoDB Enterprise lub Community Edition.
3. Skonfiguruj poszczególne pliki konfiguracyjne mongod.conf dla zestawu replik, używając „parametru replikacji”. Jeśli będziesz używać pliku klucza do celów bezpieczeństwa, skonfiguruj go teraz również. Należy pamiętać, że korzystanie z zabezpieczeń plików kluczy umożliwia również uwierzytelnianie oparte na rolach, więc aby korzystać z serwerów, trzeba również dodać użytkowników i role. Zrestartuj proces mongod na każdym serwerze.
4. Zapewnij łączność między węzłami. Musisz upewnić się, że węzły zestawu replik MongoDB mogą komunikować się ze sobą na porcie 27017, a także, że Twoi klienci mogą łączyć się z każdym z węzłów zestawu replik na tym samym porcie.
5. Używając klienta wiersza poleceń MongoDB, połącz się z jednym z serwerów i uruchom rs.initiate(), aby zainicjować zestaw replik, a następnie rs.add() dla każdego dodatkowego węzła. rs.conf() może być używany do przeglądania konfiguracji.

Chociaż te kroki nie są tak złożone, jak wdrażanie i konfigurowanie klastra podzielonego na fragmenty MongoDB lub fragmentacja relacyjnej bazy danych, mogą być uciążliwe i podatne na błędy, szczególnie w większych środowiskach.

Skalowalność

MongoDB jest często określany jako oprogramowanie bazodanowe „w skali internetowej”, ze względu na jego zdolność do skalowania w poziomie. Podobnie jak w przypadku relacyjnych baz danych, MongoDB można skalować w pionie, po prostu przez uaktualnienie hosta fizycznego, na którym się znajduje, o większą liczbę rdzeni procesora, więcej pamięci RAM, szybsze dyski, a nawet zwiększoną prędkość magistrali. Skalowanie wertykalne ma jednak swoje ograniczenia, zarówno pod względem stosunku kosztów do korzyści i malejących zysków, jak i ograniczeń technicznych. Aby rozwiązać ten problem, MongoDB ma funkcję „auto-shardingu”, która umożliwia dzielenie baz danych na wiele hostów (lub zestawów replik w celu zapewnienia nadmiarowości). Chociaż sharding jest również możliwy na platformach relacyjnych, o ile nie jest przeznaczony do tworzenia bazy danych, wymaga to poważnego przeprojektowania schematu i aplikacji, a także przeprojektowania aplikacji klienckiej, co czyni ten proces żmudnym, czasochłonnym i podatnym na błędy.

Sharding MongoDB działa poprzez wprowadzenie procesu routera, za pośrednictwem którego klienci łączą się z klastrem podzielonym na fragmenty, oraz serwerów konfiguracyjnych, które przechowują metadane klastra, lokalizację w klastrze każdego dokumentu. Gdy klient wysyła zapytanie do procesu routera, najpierw odwołuje się do serwerów konfiguracyjnych, aby uzyskać lokalizacje dokumentów, a następnie uzyskuje wyniki zapytania bezpośrednio z poszczególnych serwerów lub
zestawów replik (odłamków). Podział na fragmenty odbywa się na podstawie kolekcji.

Parametrem o krytycznym znaczeniu, ze względu na wydajność, jest tutaj „klucz fragmentu”, pole indeksowane lub pole złożone, które istnieje w każdym dokumencie w kolekcji. To właśnie definiuje rozkład zapisu między fragmentami kolekcji. W związku z tym źle dobrany klucz fragmentu może mieć bardzo szkodliwy wpływ na wydajność. Na przykład klucz fragmentu oparty wyłącznie na szeregach czasowych może spowodować, że wszystkie zapisy będą kierowane do jednego węzła przez dłuższy czas. Jednak zaszyfrowany klucz fragmentu, chociaż równomiernie rozprowadza zapisy we fragmentach, może wpływać na wydajność odczytu, ponieważ zestaw wyników jest pobierany z wielu węzłów.

Arbitrzy

Arbiter MongoDB to proces mongod, który został skonfigurowany nie tak, aby działał jako węzeł danych, ale aby zapewniał tylko funkcję głosowania, gdy ma zostać wybrany podstawowy zestaw replik, w celu zerwania więzi i ochrony przed głosowaniem podzielonym. Arbiter nie może zostać Główny, ponieważ nie posiada kopii danych ani nie akceptuje zapisów. Chociaż możliwe jest posiadanie więcej niż jednego arbitra w zestawie replik, generalnie nie jest to zalecane.

Opóźnione elementy zestawu replik

Elementy zestawu replik opóźnionych dodają dodatkowy poziom nadmiarowości, utrzymując stan, który jest o stałą liczbę sekund opóźnienia w stosunku do podstawowego. Ponieważ opóźnieni członkowie są „kroczącą kopią zapasową” lub działającą „historyczną” migawką zestawu danych, mogą pomóc w naprawie po różnego rodzaju błędach ludzkich.

Opóźnione elementy członkowskie to „ukryte” elementy zestawu replik, niewidoczne dla aplikacji klienckich i dlatego nie można ich bezpośrednio odpytywać. Mogą również nie stać się podstawowymi podczas normalnych operacji i muszą zostać ponownie skonfigurowane ręcznie w przypadku, gdy mają być używane do naprawy po błędzie.

Kopie zapasowe

Tworzenie kopii zapasowej zestawu replik lub klastra podzielonego na fragmenty odbywa się za pomocą narzędzia wiersza poleceń „mongodump”. W przypadku użycia z parametrem --oplog tworzy zrzut bazy danych zawierający oplog, aby utworzyć migawkę stanu instancji mongod z określonego momentu. Używając mongorestore z parametrem --replayOplog, możesz następnie w pełni przywrócić stan danych w momencie zakończenia tworzenia kopii zapasowej, unikając niespójności.

W przypadku bardziej zaawansowanych wymagań dotyczących tworzenia kopii zapasowych dostępne jest narzędzie innej firmy o nazwie „mongodbconsistent-backup” – również oparte na wierszu poleceń – które zapewnia w pełni spójne kopie zapasowe klastrów podzielonych na fragmenty, co jest złożoną procedurą, biorąc pod uwagę, że bazy danych podzielone na fragmenty są rozproszone na wielu hostach.

Monitorowanie

Na rynku dostępnych jest wiele komercyjnych narzędzi, zarówno oficjalnych, jak i nieoficjalnych, służących do monitorowania MongoDB. Ogólnie rzecz biorąc, narzędzia te są narzędziami do zarządzania pojedynczymi produktami, skupiającymi się wyłącznie na MongoDB. Wiele z nich koncentruje się tylko na określonych aspektach, takich jak zarządzanie kolekcjami w istniejącej architekturze MongoDB, tworzenie kopii zapasowych lub wdrażanie. Bez odpowiedniego planowania może to doprowadzić do sytuacji, w której w Twoim środowisku trzeba będzie wdrożyć i zarządzać mnogością dodatkowych narzędzi.

Narzędzia wiersza poleceń dostarczane z MongoDB, „mongotop” i „mongostat” mogą zapewnić szczegółowy widok wydajności środowiska i mogą być używane do diagnozowania problemów. Ponadto klient wiersza poleceń MongoDB „mongo” może również uruchomić „rs.status()” — lub w podzielonym na fragmenty klastrze „sh.status() — w celu wyświetlenia stanu zestawów replik lub klastrów oraz ich hostów członkowskich. Polecenie „db.stats()” zwraca dokument, który dotyczy wykorzystania pamięci i objętości danych, a ich odpowiedniki są odpowiednikami dla kolekcji, a także innymi wywołaniami dostępu do wielu wewnętrznych metryk.

Streszczenie

To było krótkie streszczenie rozważań dotyczących administrowania MongoDB. Jednak nawet na tak wysokim poziomie powinno być od razu oczywiste, że chociaż możliwe jest administrowanie zestawem replik lub klastrem sharded z poziomu wiersza poleceń przy użyciu dostępnych narzędzi, nie skaluje się to w środowisku z wieloma zestawami replik lub przy dużej produkcji podzielony klaster. W średnich i dużych środowiskach składających się z wielu hostów
i baz danych zarządzanie wszystkim za pomocą narzędzi wiersza poleceń i skryptów szybko staje się niewykonalne. Chociaż wewnętrzne narzędzia i skrypty można opracować w celu wdrożenia i utrzymania środowiska, zwiększa to obciążenie związane z zarządzaniem nowymi programami, systemami kontroli wersji i procesami. Prosta aktualizacja serwera bazy danych może stać się złożonym procesem, jeśli wymagane są zmiany narzędzi do obsługi nowych
wersji serwera bazy danych.

Ale bez wewnętrznych narzędzi i skryptów, jak możemy zautomatyzować i zarządzać klastrami MongoDB? Pobierz oficjalny dokument, aby dowiedzieć się, jak to zrobić!