MongoDB używa dziennika na dysku, aby zagwarantować operacje zapisu i zapewnić odporność na awarie. MongoDB tworzy również dziennik dla każdego zapisu, który zawiera dokładną lokalizację dysku i bajty, które uległy zmianie podczas zapisu. Tak więc, jeśli wystąpi awaria serwera, dziennik może zostać użyty do odtworzenia wszelkich zapisów, które nie zostały jeszcze zapisane w plikach danych.
MongoDB używa plików mapowanych w pamięci do zapisywania danych na dysku. Domyślnie pliki danych MongoDB są opróżniane na dysk co 60 sekund. Używają również plików mapowanych w pamięci dla dziennika i domyślnie dziennik jest opróżniany na dysk co 100 ms. Ponieważ końcowe pliki danych są opróżniane na dysk co 60 sekund, dziennik nie musi śledzić zapisów dłużej niż przez minutę. Więcej informacji na temat mechaniki tworzenia dzienników znajdziesz w oficjalnej dokumentacji. Aby bardziej szczegółowo zrozumieć, jak działa mapowanie widoków, możesz zajrzeć na blog Kristiny.
Problem związany z zapisem w dzienniku
>db.data.insert({"name":"testentry"});
>db.runCommand({"getLastError":1, "j":true});
Po włączeniu księgowania MongoDB masz również możliwość określenia problemu zapisu w MongoDB jako „Journaled” dla swoich operacji MongoDB. Oznacza to, że MongoDB potwierdza operację zapisu dopiero po zatwierdzeniu w dzienniku. Ma to jednak wadę – jeśli określisz „j”:true z getLastError, MongoDB będzie czekać na około 1/3 wewnętrznego zatwierdzenia dziennika przed zatwierdzeniem danych dziennika. Domyślny interwał zatwierdzenia dziennika to 100 ms – więc MongoDB poczeka 30 ms i zatwierdzi dane. Zasadniczo oznacza to, że w jednym wątku można uzyskać tylko około 33,3 zapisów na sekundę, a zalecaną najlepszą praktyką jest grupowanie zapisów. Na przykład, jeśli masz 50 zapisów, użyj ustawienia „j”:true tylko przy ostatnim zapisie – to potwierdzi, że wszystkie poprzednie 50 zapisów zostało wykonanych.
Podsumowanie
Każda produkcyjna instancja MongoDB powinna działać z włączonym kronikowaniem. Jeśli nie masz włączonej funkcji księgowania, a serwer lub proces MongoDB ulega awarii, MongoDB nie będzie w stanie zapewnić integralności danych. Będziesz musiał przeprowadzić operację „naprawy” w bazie danych, która w zależności od ilości danych może potrwać kilka godzin. Wyłącz to tylko wtedy, gdy naprawdę wiesz, co robisz. W ScaleGrid wszystkie nasze instancje są zgodne z konfiguracją najlepszych praktyk MongoDB i mają domyślnie włączone księgowanie.
