Jaki jest zalecany sposób tworzenia kopii zapasowych dużych zestawów danych w MongoDB? Powiedzmy, że mamy rozmiar danych rzędu 10 TB - jak byś to zrobił?
Rozważamy ukryty, prawdopodobnie opóźniony węzeł zestawu replik. Opóźnienie uchroniłoby nas przed przypadkowymi upuszczeniami całej bazy danych. Czy to realne rozwiązanie i jakie inne opcje poleciłbyś zbadać?
Dzięki!
Odpowiedzi:
Z koniecznością utworzenia kopii zapasowej 10 TB staje się to nieco skomplikowane.
Chociaż członkowie opóźnionego zestawu replik mogą zapewnić stosunkowo łatwy sposób pomocy w przypadkowych operacjach, nie ma możliwości zastąpienia prawidłowych kopii zapasowych, podobnie jak RAID nie zastępuje kopii zapasowych opartych na systemie plików.
To w dużej mierze zależy od tego, jak wygląda twoja konfiguracja.
W przypadku 10 TB zakładam, że masz podłączoną sieć SAN. Najprostszym sposobem wykonania kopii zapasowej MongoDB w tych środowiskach jest upewnienie się, że masz włączone księgowanie zarówno w systemie plików, jak i MongoDB, i po prostu zrób migawkę woluminu SAN jednego z pomocniczych, prawdopodobnie ukrytego, aby upewnić się, że twoje operacje nie nie przeszkadzają. Zwykle zajmuje to kilka sekund, ale proszę _ upewnić się, że okno oplogowania replikacji jest wystarczające. W przeciwnym razie może być konieczne ponowne zsynchronizowanie pomocniczej.
Muszę się nie zgodzić z RolandoMySQLDBA na temat korzystania z mongodump. Przede wszystkim nakłada blokady na serwer. Chociaż są one podnoszone stosunkowo szybko, sama liczba blokad może sumować się i zakłócać twoje operacje, chyba że uruchomiona na ukrytym węźle lub gdy nie ma preferencji odczytu uderzającej w pomocnicze. Co więcej, nie jest to dokładnie szybkie. Spodziewałbym się, że będzie działać co najmniej przez wiele godzin, najprawdopodobniej dłużej niż okno zapasowe. Uwaga dodatkowa: Zawsze uruchamiaj mongodump z --oplogopcją. Należy również pamiętać, że mongodump nie tworzy kopii zapasowych indeksów, ale operacje tworzenia indeksów. Wskaźniki te należy odtworzyć podczas przywracania, co może znacznie wydłużyć czas potrzebny na jego przywrócenie. Z mojego doświadczenia wynika, że jeśli musisz przywrócić bazę danych, chcesz mieć ją tak szybko, jak to możliwe. Kolejna kwestia, dlaczego mongodump nie nadaje się do tworzenia kopii zapasowych 10 TB.
Możesz wykonać migawkę LVM na działającej instancji mongod, pod warunkiem, że masz włączone rejestrowanie w mongod (i z mojego doświadczenia, nie ma nic złego w włączeniu go również na poziomie FS). Jednak migawki LVM mają pewne implikacje. Po pierwsze, oczywiście musisz mieć wystarczającą ilość miejsca na dysku, aby dokonać zmian podczas operacji tworzenia kopii zapasowej. Pozwól mi to wyjaśnić.
Załóżmy, że masz godzinną szybkość zmiany 500 GB. I że chcesz, aby twoja kopia zapasowa została skopiowana przed przesłaniem jej do pamięci. Nawet przy użyciu równoległego bzip2 kompresja 10 TB może zająć kilka godzin, po prostu dlatego, że najprawdopodobniej przepustowość pamięci masowej stanie się czynnikiem ograniczającym. Załóżmy, że skompresowanie danych do 2 TB zajęłoby 2 godziny. Do tego czasu potrzebowalibyśmy około 2 TB + 2 * 500 GB wolnego miejsca na dysku, 1 TB potrzebny na migawkę LVM. Powoduje to konieczność nadmiarowego udostępniania systemu plików przynajmniej30% Jeśli chcesz mieć odpowiedni margines bezpieczeństwa, może to łatwo wzrosnąć do 60-70% (20% dla współczynnika wykorzystania wynoszącego 0,8 dla oryginalnego systemu plików, to samo dla rozmiaru migawki plus miejsca potrzebnego na samą kopię zapasową. ). W większości środowisk produkcyjnych byłoby to niedopuszczalne, ponieważ nadmierne udostępnianie byłoby statyczne (nie chciałbyś, aby skrypt zapasowy dynamicznie współgrał z LVM?).
Chociaż tworzenie kopii zapasowych MMS ma kilka niesamowitych funkcji (ciągłe tworzenie kopii zapasowych, łatwe odzyskiwanie w odpowiednim momencie), ma jednak pewną poważną wadę: jego cena za duże wdrożenia może być z łatwością w tysiącach. Przy założonej godzinnej szybkości zmiany 500 GB na tych 10 TB, byłaby to średnia sześciocyfrowa suma dla kopii zapasowych w chmurze . Miesięczny.
Sugeruję, aby wziął abonament korporacyjny na twoje serwery za uprawnienie do posiadania lokalnego wystąpienia MMS, w tym kopii zapasowej.
Oto opcje, które wybrałbym w malejącej kolejności preferencji.
Istnieją dwie opcje
Jeśli nie masz nic przeciwko przestojom, najłatwiej jest to zrobić
service mongod stopWykonaj migawkę LVM lub brutalną siłę cpfolderu danych Mongo na innym dysku
service mongod startOczywiście nie potrzebujesz przestojów, jeśli 10 TB danych znajduje się na samodzielnej maszynie.
Jeśli masz zestaw repliki z trzema węzłami, użyj jednego z węzłów do tworzenia kopii zapasowych
{
"_id" : "myreplica",
"version" : 1,
"members" : [
{
"_id" : 1,
"host" : "10.20.30.40:27017",
"priority" : 2
},
{
"_id" : 2,
"host" : "10.20.30.41:27017"
},
{
"_id" : 3,
"host" : "10.20.30.42:27017",
"priority" : 0,
"slaveDelay" : 3600
}
]
}Użyj węzła do "_id' : 3wszystkich fizycznych kopii zapasowych. Dlatego nie ma przestojów. Aby uzyskać migawkę o północy, możesz uruchomić tworzenie kopii zapasowej o 1:00, ponieważ ukryty węzeł jest o 1 godzinę za nim.
Oczywiście wadą jest posiadanie dwóch kolejnych serwerów z 10 TB każdy i zagrożenie zdrowia psychicznego sysadmin.
Możesz użyć mongodumpa na autonomicznej maszynie, ale musisz spodziewać się spadku wydajności, ponieważ mongodump jest programem klienckim używającym połączenia jak każde inne połączenie.
Jeśli chcesz wykonać kopię zapasową w czasie, powinieneś jej użyć
mongodump --oplog Logiczna kopia zapasowa BSON będzie mniejsza (zwłaszcza gzip lub bzip) niż fizyczna kopia zapasowa.
Korzystanie mongodump --oplogbyłoby najlepiej zrobić przed ukrytego węzła. W ten sposób Mistrz nie ma żadnego spadku wydajności.
Jestem stosunkowo nowy w MongoDB (przypadkowe / przypadkowe MongoDBA). Mam nadzieję, że moja odpowiedź pomoże.