Lista kontrolna rozwoju i operacji dla MongoDB

Listy kontrolne działania i rozwoju MongoDB mają pomóc administratorom baz danych uniknąć problemów w środowisku produkcyjnym MongoDB. Lista kontrolna rozwoju powinna dotyczyć problemów, takich jak...

1. Projektowanie schematu
2. Trwałość danych
3. Replikacja
4. Dyski
5. Sharding

Lista kontrolna operacji, z drugiej strony, adresy...

1. Replikacja
2. System plików 
3. Sharding
4. Sprzęt
5. Dzienniki (WiredTiger Storage Engine) 
6. Konfiguracje systemu operacyjnego 
7. Wdrażanie na sprzęcie w chmurze 
8. Monitorowanie
9. Kopie zapasowe i równoważenie obciążenia

Przed rozpoczęciem projektu zaleca się pracę nad listą kontrolną działania i rozwoju, aby umożliwić płynne działanie MongoDB w produkcji. W tym artykule opisano listę kontrolną działania i rozwoju przed wdrożeniem MongoDB.

Lista kontrolna operacji MongoDB

Replikacja

Wszystkie zestawy członków replik, które nie są ukryte, powinny być obsługiwane identycznie pod względem dysku, pamięci RAM, konfiguracji sieci i procesora.

Rozmiar Oploga powinien być odpowiednio skonfigurowany w celu zaspokojenia potrzeb operacyjnych, tak aby:

• Aby uniknąć konieczności pełnej ponownej synchronizacji, okno repliki aplikacji oplog powinno obejmować regularne przestoje i okres konserwacji.
• Aby przywrócić element zestawu replikacji, okno repliki oplog powinno zawsze obejmować wymagany czas.

Zestaw produkcyjny jako minimum powinien zawierać trzy węzły przenoszące dane, które działają z włączonym kronikowaniem. Poza tym zapisy powinny być wydawane z w:„większość” problemów związanych z zapisem w celu zapewnienia dostępności i trwałości danych.

Wdrożenie powinno zawierać nieparzystą liczbę głosujących członków, aby ułatwić proces głosowania za każdym razem, gdy podstawowy węzeł w klastrze ulegnie awarii.

Zamiast używać adresów IP, które mogą wymagać zmiany konfiguracji z powodu zmiany adresu IP, zalecane jest użycie logicznych nazw hostów DNS.

Upewnij się, że instancje mongod mają 0 lub 1 głosów.

Wszystkie instancje Mongod powinny być w pełni i dwukierunkowo połączone, aby zapewnić łatwość komunikacji danych między zaangażowanymi węzłami.

Dzienniki

Jest to strategia zapisu z wyprzedzeniem rejestrowania plików dziennika na dysku stosowana w celu zapewnienia trwałości danych w przypadku awarii. Z tego powodu wszystkie instancje powinny mieć włączone księgowanie, zwłaszcza w przypadku obciążeń intensywnie korzystających z zapisu.

Należy jednak wziąć pod uwagę, że wpływa to na wzmocnienia w stylu migawek, ponieważ rekordy stanowiące stan bazy danych pozostaną na partycjach woluminów.

System plików

Nie używaj dysków News File System (NFS) dla dbPath. Dyski NFS mogą powodować destabilizację wydajności. Dyski wirtualne VMware są zalecane do użytku przez użytkowników VMware.

Upewnij się, że partycje dyskowe są wyrównane z konfiguracjami RAIDON.

Dla użytkowników Linuksa/Unixa zalecane jest użycie XFS. Wiadomo, że XFS działa lepiej z MongoDB.

Dla użytkowników systemu operacyjnego Windows zalecany jest system plików NTFS. Należy unikać używania jakiegokolwiek systemu plików FAT.

Wdrożenie na sprzęcie w chmurze

Windows Azure:zmień utrzymywanie aktywności TCP (tcp_keepalive_time) na 100-120. Przekroczenie limitu czasu TCP poza biegiem w module równoważenia stosu Azure jest również umiarkowane dla zachowania puli skojarzeń MongoDB

Użyj MongoDB 2.6.4 lub nowszych wersji na platformach z pamięcią masową o dużych opóźnieniach, takich jak Windows Azure, ponieważ te wersje zawierają ulepszenia wykonywania dla tych platform.

Sharding

Umieść swoje serwery konfiguracyjne na dedykowanym sprzęcie, aby uzyskać idealne działanie w rozległych klastrach.

Upewnij się, że sprzęt ma wystarczającą ilość pamięci RAM do przechowywania zapisów informacji w całości w pamięci i ma dedykowaną pamięć.

Wdróż routery Mongos zgodnie z wytycznymi Generation Setup.

Synchronizuj zegary wszystkich komponentów klastra podzielonego na fragmenty za pomocą NTP.

Zapewnij pełną dwukierunkową sieć między serwerami mongos, mongod i konfiguracyjnymi.

Użyj CNAME do rozpoznawania serwerów konfiguracyjnych w klastrze, dzięki czemu możesz zmieniać nazwy i numerację serwerów konfiguracyjnych bez przestojów.

Monitorowanie

Możesz wykorzystać narzędzia takie jak MongoDB Cloud Manager, ClusterControl lub inną platformę monitorowania, aby monitorować kluczowe metryki bazy danych i konfigurować alarmy. Uwzględnij alerty dotyczące danych:

• Kolejki
• Okno oplog replikacji
• Twierdzenia
• Błędy stron
• Opóźnienie replikacji

Monitoruj metryki sprzętowe dla swoich serwerów. Zwróć szczególną uwagę na dostępne miejsce na dysku, wykorzystanie dysku, procesor

Sprzęt

Wykorzystaj dyski RAID10 i SSD, aby uzyskać idealną wydajność.

SAN i wirtualizacja:

Upewnij się, że każda instancja mongod obsługuje IOPS dla swojej dbPath lub ma swój dysk fizyczny lub jednostkę LUN z żądaniem.

Unikaj dynamicznych wyróżnień pamięci, takich jak powiększanie się pamięci podczas pracy w środowiskach wirtualnych.

Unikaj ustawiania wszystkich osób z zestawu kopii na tej samej sieci SAN, ponieważ sieć SAN może być pojedynczym punktem rozczarowania.

Równoważenie obciążenia

Zaprojektuj systemy równoważenia obciążenia, aby włączyć „przyklejone sesje” lub „powinowactwo klienta” z odpowiednim limitem czasu dla istniejących połączeń.

Unikaj umieszczania systemów równoważenia obciążenia między klastrem MongoDB lub komponentami zestawu replik.

Kopie zapasowe

Zaplanuj sporadyczne testy procesu tworzenia kopii zapasowych i przywracania, aby mieć pod ręką wskaźniki czasu i potwierdzić ich przydatność.

Konfiguracja systemu operacyjnego

Windows

Rozważ dezaktywację aktualizacji NTFS „czas ostatniego dostępu”.

Sformatuj dyski NTFS, korzystając z domyślnego rozmiaru jednostki przydziału wynoszącego 4096 bajtów.

Linuks

Wyłącz ogromne przezroczyste strony.

Dokonaj zmian w ustawieniach głowicy odczytu kostek, w których przechowywane są pliki bazy danych. Odczyt silnika pamięci masowej WiredTiger powinien wynosić od 8 do 32.

Jeśli korzystasz z tuningu w RHEL / CentOS, musisz dostosować dostosowany profil. Wiele dostrojonych profili dostarczanych z RHEL / CentOS może niekorzystnie wpłynąć na wykonanie przy ich domyślnych ustawieniach. Dostosuj wybrany dostrojony profil, aby:

Wyłącz proste ogromne strony.

Ustaw odczyt między 8 a 32 w każdym przypadku sortowania nośników pojemności.

Wykorzystaj harmonogramy dysków noop lub terminowe dla dysków SSD.

Użyj harmonogramu dysków noop dla zwirtualizowanych dysków w maszynach wirtualnych gościa.

Wyłącz NUMA lub ustaw vm.zone_reclaim_mode na 0 i uruchamiaj wystąpienia mongod z przeplataniem węzłów.

Dostosuj wartości ulimit na swoim sprzęcie, aby pasowały do ​​przypadku użycia. W przypadku, gdy różne wystąpienia mongod lub mongos działają pod tym samym klientem, skaluj wartości ulimit w podobny sposób.

Zaprojektuj odpowiednie uchwyty rekordów (fs.file-max), ograniczenie części pid (kernel.pid_max), maksymalną liczbę wątków na proces (kernel.threads-max) i maksymalną liczbę obszarów zarysów pamięci na proces (vm.max_map_count) do wysłania. W przypadku rozbudowanych frameworków, następujące wartości stanowią doskonały punkt wyjścia:

fs.file-max value of 98000,

kernel.pid_max value of 64000,

kernel.threads-max value of 64000, and vm.max_map_count value of 128000

Upewnij się, że twoja platforma ma skonfigurowaną przestrzeń wymiany.

Nawiązuj do dokumentacji swojego systemu operacyjnego, aby uzyskać ciekawe miejsca o prawidłowym rozmiarze.

 Upewnij się, że domyślny system utrzymywania aktywności TCP jest prawidłowo ustawiony. Wartość 300 często zapewnia doskonałą wydajność w przypadku zestawów replik i klastrów podzielonych na fragmenty.

Lista kontrolna rozwoju MongoDB

Replikacja

Wykorzystaj nieparzystą liczbę głosujących osób, aby zagwarantować, że wybory będą trwać skutecznie. Będziesz mieć do 7 głosujących osób. W przypadku, gdy masz parzystą liczbę głosujących osób i ograniczenia, takie jak koszt, nie pozwalają na włączenie innego drugorzędnego jako członka głosującego, będziesz mógł włączyć arbitra, aby zagwarantować nieparzystą liczbę głosów.

Gwarantuj, że Twoje pliki pomocnicze będą aktualne, korzystając z narzędzi monitorujących i wskazując odpowiednie problemy związane z zapisem.

Nie używaj odczytów pomocniczych do skalowania ogólnej przepustowości odczytu.

Projektowanie schematu

Dane w MongoDB zawierają dynamiczny wzorzec. Kolekcje nie zachowują struktury raportu. Zachęca to do iteracyjnego doskonalenia i polimorfizmu. W każdym razie kolekcje często zawierają zapisy o wyjątkowo jednorodnej strukturze.

Zdecyduj, jakie zbiory będą potrzebne, a także indeksy wymagane do obsługi zapytań. W szczególnym przypadku indeksu _id, wszystkie indeksy należy utworzyć w sposób wyraźny:MongoDB nie tworzy żadnych indeksów innych niż _id.

Gwarancja, że ​​plan schematu obsługuje sortowanie wdrożeń:jeśli planujesz używać klastrów podzielonych na fragmenty do skalowania poziomego, zaplanuj schemat tak, aby zawierał silny klucz fragmentu. Klucz fragmentu wpływa na wykonywanie odczytu i zapisu, decydując o tym, jak MongoDB segmentuje dane. Nie możesz zmienić klucza fragmentu po jego ustawieniu.

Upewnij się, że plan schematu nie zależy od zindeksowanych klastrów, których długość rośnie bez ograniczeń. Zwykle najlepsze wykonanie można osiągnąć, gdy takie zindeksowane klastry mają mniej niż 1000 komponentów.

Podczas projektowania schematu weź pod uwagę limity oszacowania dokumentu. Ograniczenie BSON Document Estimate wynosi 16 MB na dokument. Jeśli potrzebujesz większych raportów, użyj GridFS.

Kierowcy

Skorzystaj z puli skojarzeń. Większość sterowników MongoDB obsługuje łączenie skojarzeń. Zmień rozmiar puli asocjacji, aby dopasować go do swojego przypadku użycia, zaczynając od 110-115% normalnej liczby jednoczesnych żądań bazy danych.

Upewnij się, że aplikacje obsługują tymczasowe błędy zapisu i odczytu w wyborach zestawu replik.

Zagwarantuj, że Twoje aplikacje obsłużą nieudane żądania i spróbuj je ponownie w razie potrzeby. Kierowcy nie

naturalnie ponawiaj nieudane żądania.

Wykorzystaj wykładnicze uzasadnienie wycofywania dla ponownych prób żądań bazy danych.

Użyj cursor.maxTimeMS() do odczytów i czasu oczekiwania na zapisy w przypadku, gdy chcesz ograniczyć czas wykonywania operacji na bazie danych.

Trwałość danych

Upewnij się, że twój zestaw replik zawiera co najmniej trzy piasty przenoszące dane z problemem w:większości komponowania. Aby zapewnić solidność danych w szerokim zestawie replik, wymagane są trzy koncentratory danych.

Gwarantujemy, że wszystkie instancje wykorzystują księgowanie.

Sharding

Gwarancja, że ​​klucz odłamka przenosi równomiernie obciążenie na odłamki.

Wykorzystaj ukierunkowane operacje dla obciążeń, które trzeba było skalować wraz z liczbą fragmentów.

W przypadku MongoDB 3.6 i późniejszych, wtórne nie zwracają już osieroconych danych, chyba że wykorzystuje się problem odczytu „dostępny” (co jest domyślnym problemem odczytu dla odczytów z drugorzędnych, gdy nie są one związane z sesjami niezawodnymi przyczynowo).

Począwszy od MongoDB 3.6, wszyscy członkowie zestawu replik fragmentu zachowują metadane porcji, co pozwala im odfiltrować sieroty, gdy nie wykorzystują „dostępne”. W związku z tym nieukierunkowane lub nadawane zapytania, które nie wykorzystują „dostępnych”, mogą być bezpiecznie uruchamiane na dowolnym członku i nie będą zwracać osieroconych informacji.

Zagadnienie odczytu „dostępnego” może zwrócić osierocone dokumenty od członków pomocniczych, ponieważ nie sprawdza przerobionych metadanych porcji. W każdym razie, w przypadku, gdy zwrot osieroconych dokumentów jest nieistotny dla aplikacji, problem dotyczący odczytu „dostępny” daje najmniejszą możliwą liczbę odczytów bezczynności spośród różnych problemów związanych z odczytem.

Wstępnie dziel i ręcznie dopasowuj porcje podczas osadzania rozległych zestawów danych w nowym zbiorze, który nie jest zaszyfrowany. Wstępne dzielenie i fizyczna regulacja umożliwia rozproszenie stosu osadzania między odłamkami, rozszerzając wykonanie dla obciążenia początkowego.

Wnioski 

Zarządzanie listą kontrolną operacji i rozwoju to kluczowy krok, który programiści muszą uwzględnić podczas korzystania z MongoDB w środowisku produkcyjnym. Są to kluczowe kwestie, ponieważ poprawiają przepływ zadań dla projektu w produkcji. Środowisko produkcyjne MongoDB wymaga stabilnych i niezawodnych funkcji bazy danych, ponieważ baza danych w środowisku produkcyjnym przechowuje rzeczywiste dane robocze. Integralność danych zależy od stabilności bazy danych, która jest możliwa dzięki zapewnieniu, że wszystkie elementy na liście kontrolnej działania i rozwoju są opracowywane przed produkcją.