Replikacja w MongoDB obejmuje zestawy replik złożone przez członków o architekturze podstawowego i dodatkowego członka, ale czasami z elementem nieprzenoszącym danych, zwanym arbitrem. Proces replikacji polega na tym, że za każdym razem, gdy dane zostały zapisane w węźle podstawowym, zmiany są rejestrowane w pliku oplog, z którego te same zmiany są wprowadzane przez elementy drugorzędne. Operacje odczytu można wykonać z dowolnego elementu niosącego dane, tworząc w ten sposób scenariusz powszechnie znany jako wysoka dostępność.
Jednak w niektórych przypadkach elementy drugorzędne mogą nie nadążać za głównymi w dokonywaniu zmian, a jeśli węzeł podstawowy ulegnie awarii przed zastosowaniem tych zmian, zostaniemy zmuszeni do ponownej synchronizacji całego klastra aby mogły znajdować się w tym samym stanie danych.
Co to jest wycofanie?
Jest to funkcja automatycznego przełączania awaryjnego w MongoDB, w której węzeł podstawowy w zestawie replik może ulec awarii podczas wprowadzania zmian, które niestety nie są odzwierciedlane na czas w elementach pomocniczych z oploga, dlatego należy przywrócić stan podstawowy na jeden przed wprowadzeniem zmian.
Wycofywanie zmian jest zatem konieczne tylko wtedy, gdy podstawowy zaakceptował zapisanie operacji, które nie zostały zreplikowane do drugorzędnych elementów członkowskich przed podstawowymi krokami w dół z jakiegoś powodu, takiego jak partycja sieciowa. Jeśli w przypadku, gdy uda się zreplikować operacje zapisu w jednym z elementów członkowskich, który jest dostępny i dostępny dla większości zestawu replik, wycofanie nie nastąpi.
Głównym powodem wycofywania zmian w MongoDB jest zachowanie spójności danych dla wszystkich członków, a zatem, gdy podstawowy ponownie dołącza do zestawu replik, jeśli jego zmiany nie zostały zastosowane do drugorzędnych elementów członkowskich, zostanie to cofnięte do stanu sprzed awarii.
Jednak wycofania powinny być rzadkie lub raczej unikane w MongoDB, ponieważ mogą spowodować utratę dużej ilości danych iw konsekwencji wpłynąć na działanie aplikacji podłączonych do bazy danych.
Proces przywracania MongoDB
Rozważmy trzyelementową replikę z A jako podstawowym, B i C jako dodatkowymi elementami. Będziemy wypełniać dane do A i jednocześnie uruchamiać partycjonowanie sieci do B i C. W tym teście użyjemy MongoDB w wersji 4.2 i Atlasa.
Najpierw uzyskamy status ustawionej repliki, uruchamiając polecenie rs.status() w powłoce mongo
MongoDB Enterprise Cluster0-shard-0:PRIMARY> rs.status()Patrząc na atrybut członków, możesz zobaczyć coś takiego
"members" : [
{
"_id" : 0,
"name" : "cluster0-shard-00-00-sc27x.mongodb.net:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 1891079,
"optime" : {
"ts" : Timestamp(1594826711, 1),
"t" : NumberLong(27)
},
"optimeDurable" : {
"ts" : Timestamp(1594826711, 1),
"t" : NumberLong(27)
},
"optimeDate" : ISODate("2020-07-15T15:25:11Z"),
"optimeDurableDate" : ISODate("2020-07-15T15:25:11Z"),
"lastHeartbeat" : ISODate("2020-07-15T15:25:19.509Z"),
"lastHeartbeatRecv" : ISODate("2020-07-15T15:25:18.532Z"),
"pingMs" : NumberLong(0),
"lastHeartbeatMessage" : "",
"syncingTo" : "cluster0-shard-00-02-sc27x.mongodb.net:27017",
"syncSourceHost" : "cluster0-shard-00-02-sc27x.mongodb.net:27017",
"syncSourceId" : 2,
"infoMessage" : "",
"configVersion" : 4
},
{
"_id" : 1,
"name" : "cluster0-shard-00-01-sc27x.mongodb.net:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 1891055,
"optime" : {
"ts" : Timestamp(1594826711, 1),
"t" : NumberLong(27)
},
"optimeDurable" : {
"ts" : Timestamp(1594826711, 1),
"t" : NumberLong(27)
},
"optimeDate" : ISODate("2020-07-15T15:25:11Z"),
"optimeDurableDate" : ISODate("2020-07-15T15:25:11Z"),
"lastHeartbeat" : ISODate("2020-07-15T15:25:17.914Z"),
"lastHeartbeatRecv" : ISODate("2020-07-15T15:25:19.403Z"),
"pingMs" : NumberLong(0),
"lastHeartbeatMessage" : "",
"syncingTo" : "cluster0-shard-00-02-sc27x.mongodb.net:27017",
"syncSourceHost" : "cluster0-shard-00-02-sc27x.mongodb.net:27017",
"syncSourceId" : 2,
"infoMessage" : "",
"configVersion" : 4
},
{
"_id" : 2,
"name" : "cluster0-shard-00-02-sc27x.mongodb.net:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 1891089,
"optime" : {
"ts" : Timestamp(1594826711, 1),
"t" : NumberLong(27)
},
"optimeDate" : ISODate("2020-07-15T15:25:11Z"),
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"infoMessage" : "",
"electionTime" : Timestamp(1592935644, 1),
"electionDate" : ISODate("2020-06-23T18:07:24Z"),
"configVersion" : 4,
"self" : true,
"lastHeartbeatMessage" : ""
}
],To pokaże status każdego członka zestawu replik. Teraz otworzyliśmy nowy terminal dla węzła A i wypełniliśmy go 20 000 rekordów:
MongoDB Enterprise Cluster0-shard-0:PRIMARY> for (var y = 20000; y >= 0; y--) {
db.mytest.insert( { record : y } )
}
WriteResult({ "nInserted" : 1 })
MongoDB Enterprise Cluster0-shard-0:PRIMARY> db.mytest 2020-07-15T21:28:40.436+2128 I NETWORK [thread1] trying reconnect to 127.0.0.1:3001 (127.0.0.1) failed
2020-07-15T21:28:41.436+2128 I
NETWORK [thread1] reconnect 127.0.0.1:3001 (127.0.0.1) ok
MongoDB Enterprise Cluster0-shard-0:SECONDARY> rs.slaveOk()
MongoDB Enterprise Cluster0-shard-0:SECONDARY> db.mytest.count()
20000Podczas partycjonowania sieci, A będzie wyłączony, przez co będzie niedostępny dla B i C, a zatem B zostanie wybrany jako główny w naszym przypadku. Gdy A ponownie dołączy, zostanie dodany jako drugorzędny i możesz to sprawdzić za pomocą polecenia rs.status(). Jednak niektóre rekordy udało się zreplikować do elementu B przed partycjonowaniem sieci, jak pokazano poniżej:(Pamiętaj, że w tym przypadku B jest teraz podstawowym)
MongoDB Enterprise Cluster0-shard-0:PRIMARY> db.mytest.find({}).count()
12480 Liczba to liczba dokumentów, które można było zreplikować do B, zanim A spadło.
Jeśli zapiszemy pewne dane do B i pozwolimy A na dołączenie do sieci, możemy zauważyć pewne zmiany w A
connecting to: 127.0.0.1:3001/admin
MongoDB Enterprise Cluster0-shard-0:ROLLBACK>
MongoDB Enterprise Cluster0-shard-0:RECOVERING>
MongoDB Enterprise Cluster0-shard-0:SECONDARY>
MongoDB Enterprise Cluster0-shard-0:SECONDARY>
MongoDB Enterprise Cluster0-shard-0:PRIMARY>Za pomocą elementów pomocniczych oplogFetcher synchronizuj wpisy oplog z ich syncSource. OplogFetcher wyzwala metodę find do źródłowego oploga, po której następuje seria serii kursorów getMores. Gdy A ponownie dołącza jako drugorzędny, stosuje się to samo podejście i zwracany jest dokument większy niż sygnatura czasowa predykatu. Jeśli pierwszy dokument w B nie pasuje do ostatniego wpisu oploga A, A zostanie zmuszony do wycofania.
Odzyskiwanie danych cofania w MongoDB
Wycofywanie zmian nie jest złą rzeczą w MongDB, ale należy starać się jak najwięcej, aby upewnić się, że nie zdarzają się one dość często. Jest to automatyczny środek bezpieczeństwa zapewniający spójność danych między elementami zestawu replik. W przypadku wycofania, oto kilka kroków, aby rozwiązać tę sytuację:
Zbieranie danych cofania
Musisz zebrać dane członków dotyczące wycofywania zmian. Odbywa się to poprzez upewnienie się, że pliki wycofywania są tworzone (dostępne tylko w MongoDB w wersji 4.0) poprzez włączenie funkcji createRollbackDataFiles. Domyślnie ta opcja jest ustawiona na true, więc pliki cofania będą zawsze tworzone.
Pliki rollback umieszczone są w ścieżce
Ładowanie danych plików przywracania do oddzielnej bazy danych lub serwera
Mongorestore jest ważnym aspektem MongoDB, który może pomóc w umożliwieniu przywracania plików danych do przywrócenia. Pierwszą rzeczą jest skopiowanie wycofanych plików na nowy serwer, a następnie za pomocą mongorestore załadowanie plików na serwer. Polecenie mongorestore jest pokazane poniżej.
mongorestore -u <> -p <> -h 127.0.0.1 -d <rollbackrestoretestdb> -c <rollbackrestoretestc> <path to the .bson file> --authenticationDatabase=<database of user>Czyszczenie danych, które nie są potrzebne i przeglądanie danych
Ten krok wymaga dyskrecji wyboru między danymi, które mają być zachowane z plików przywracania, a danymi, które mają zostać wyrzucone. Wskazane jest zaimportowanie wszystkich danych z plików przywracania, ten punkt decyzyjny sprawia, że ten krok jest najtrudniejszym krokiem w odzyskiwaniu danych.
Korzystanie z podstawowego jako klastra do importowania danych
Rozpocznij ostatni krok, pobierając oczyszczone dane za pomocą mongorestore i mongodump, a następnie ponownie zaimportuj dane do oryginalnego klastra produkcyjnego.
Zapobieganie cofaniu MongoDB
Aby zapobiec cofaniu się danych podczas korzystania z MongoDB, można wykonać następujące czynności.
Prowadzenie „WIĘKSZOŚCI” wszystkich głosujących członków
Można to zrobić za pomocą polecenia w:większości write, które ma możliwość opcji potwierdzenia żądania, która umożliwi operację zapisu do określonych tagów instancji Mongod. Można to osiągnąć za pomocą opcji w, po której następuje znacznik
Operacje użytkownika
Zaktualizowana wersja MongoDB, czyli wersja 4.2, ma możliwość zamknięcia wszystkich trwających operacji w przypadku wycofania.
Budowanie indeksu
Wersja 4.2 wersji kompatybilności funkcji MongoDB (fcv) "4.2" może czekać na wszystkie indeksy w toku, które są budowane i kończone, zanim nastąpi wycofanie miejsce. Jednak wersja 4.0 czeka na dalszy postęp i kompiluje indeks w tle, więc możliwość wycofania jest wysoka.
Rozmiar i ograniczenia
Wersja 4.0 MongoDB nie ma wymienionych limitów danych, które można cofnąć, gdy trwa budowanie indeksu w tle.
Wnioski
Wycofanie MongoDB jest powszechnym zjawiskiem wśród osób korzystających z MongoDB bez wiedzy, jak temu zapobiec. Cofnięciom można zapobiec, jeśli ktoś uważnie śledzi niektóre bezpieczne praktyki i sposoby unikania cofnięć w MongoDB. Podsumowując, zawsze zaleca się uaktualnienie do najnowszej wersji MongoDB, aby uniknąć pewnych problemów, którym można by było zapobiec.
