Przewodnik programisty po zestawach replik MongoDB

MongoDB często wiąże się z pracą z dużym zestawem danych, w tym z wbudowanymi tablicami i obiektami tablic. Dlatego zawsze ważne jest, aby szybkość przetwarzania bazy danych była jak najszybsza, aby usprawnić operacje odczytu i zapisu. Poza tym, aby uniknąć anomalii danych, które mogą powstać z powodu niespójności danych, musisz zapewnić większą dostępność danych na wypadek, gdyby chciałbyś odzyskać dane po awarii sprzętu lub niektórych przerwach w działaniu usług. MongoDB udostępnia w tym celu 2 koncepcje — zestawy replik i sharding.

Replikacja w MongoDB

Replikacja typu master-slave

Jest to jedna z najstarszych technik stosowanych w celu zapewnienia, że ​​dane są zawsze dostępne dla użytkowników, nawet w przypadku awarii jednego systemu. Jednak replikacja Master-Slave jest przestarzała w najnowszych wersjach MongoDB od wersji 3.2 i dlatego została zastąpiona zestawami Replica.

Aby dokonać takiej konfiguracji, należy uruchomić 2 instancje mongod, uważając, że jedna jest w trybie master, a druga w trybie slave.

Aby uruchomić instancję w trybie głównym, uruchom:

mongod --master --port portNumber

Opcja --master nakazuje mongodowi utworzenie kolekcji local.oplog.$main, z której lista operacji jest umieszczana w kolejce dla urządzeń podrzędnych do zastosowania w replikacji danych.

Aby uruchomić instancję mongod w trybie slave, po prostu uruchom:

mongod --slave --source <masterhostname><:<port>>

Tutaj musisz określić nazwę hosta i port instancji głównej w argumencie --source. To jest skrócone omówienie korzystania z replikacji Master-Slave, a ponieważ jest ona przestarzała, nasze zainteresowanie skupią się na zestawach Replica.

Zestawy replik

Jest to grupa procesów MongoDB znanych jako instancje mongod, które zasadniczo obsługują ten sam zestaw danych. Posiada jeden węzeł główny i kilka węzłów drugorzędnych do przenoszenia danych. Węzeł podstawowy odbiera wszystkie operacje zapisu i rejestruje wszystkie inne zmiany w swoim zestawie danych w swoim dzienniku operacji. Z drugiej strony węzły drugorzędne replikują dziennik operacji podstawowego i stosują operacje na swoim zestawie danych, tak aby ich zestawy danych odzwierciedlały zestaw danych podstawowego. W prostych słowach możemy powiedzieć, że mamy maszynę A jako węzeł główny, a maszyny B i C jako węzły drugorzędne. Maszyna A otrzymuje operację zapisu i wprowadza zmiany w swoich danych, a następnie tworzy listę dokonanych zmian. Maszyny B i C skopiują następnie operacje z dostarczonej listy, w tym przypadku oplog, i wykonają je tak, aby wynikowe dane były takie same jak na komputerze A.

Jak wspomniano wcześniej, zawsze ważne jest zapewnienie wysokiej dostępności danych, szczególnie w środowisku produkcyjnym. Replikacja przychodzi z pomocą, zapewniając nadmiarowość danych w różnych instancjach Mongod. W przypadku utraty danych, ponieważ kopie tych samych danych są przechowywane w różnych bazach danych w wielu lokalizacjach, łatwo je odzyskać w istniejącej.

W przypadku wielu uruchomionych instancji operacje odczytu i zapisu z klientów są wysyłane do różnych serwerów, co powoduje wzrost szybkości przetwarzania. Podstawowa struktura procesu replikacji jest pokazana poniżej.

Czasami podstawowa może być niedostępna, na przykład z powodu rozłączenia z Internetem lub przerwy w świadczeniu usług. W takim przypadku zestaw replik wyznaczy węzeł pomocniczy jako węzeł podstawowy. O ile żądania odczytu są zasadniczo kierowane do podstawowego, w niektórych przypadkach żądania odczytu mogą być wysyłane do drugorzędnych, ale należy zachować ostrożność, ponieważ zwrócone dane mogą nie odzwierciedlać tego, co jest w podstawowym, lub raczej dane mogą nie być aktualne.

Arbitrzy

W przypadku wyboru prawyborów będziesz potrzebować dodatkowej instancji mongod do zestawu replik, aby dodać głos w procesie wyborczym. Ta instancja jest określana jako arbiter, a jej najważniejsze cechy to:

1. Nie ma kopii zestawu danych, dlatego nie wymaga tak potężnego sprzętu, jak węzły przenoszące dane.
2. Nie można awansować na główny.
3. Zawsze mają 1 głos wyborczy, aby zestaw replik miał nieparzystą liczbę głosujących członków bez narzutu dodatkowego członka, który replikuje dane. Jego kluczową rolą jest zatem wybranie głównego węzła, gdy nie jest on dostępny.
4. Pozostaje bez zmian.

W przeciwieństwie do arbitra, inne zestawy replik można przekształcić w pierwotne z drugorzędnych i odwrotnie.

Replikacja asynchroniczna

Proces replikacji odbywa się w dwóch formach synchronizacji danych. Po pierwsze, członkowie w zestawie są wypełniani pełnymi danymi w początkowej synchronizacji. Późniejsza replikacja ma miejsce w celu zastosowania zaawansowanych zmian do całego zestawu danych.

Podczas początkowej synchronizacji dane są kopiowane z jednego elementu zestawu replik do drugiego. Po zakończeniu procesu element przechodzi do węzła drugorzędnego.

Automatyczne przełączanie awaryjne MongoDB

Może wystąpić przerwa w świadczeniu usług, taka jak odłączenie sieci, co skutkuje zakończeniem komunikacji między głównym i wtórnym. Jeśli rozłączenie trwa dłużej niż 10 sekund lub całkowicie się nie powiedzie, pozostały zestaw replik zagłosuje na członka, aby stał się nowym podstawowym. Drugi węzeł, który otrzyma większość głosów, staje się nowym głównym.

W wersji 3.0 MongoDB zestaw replik może mieć do 50 członków z 7 członkami głosującymi.

Członkowie zestawu replik o priorytecie zerowym

Są to drugorzędni członkowie, którzy nie mogą przejść do węzłów głównych ani wywołać wyborów. Kluczowe role w zbiorze danych to:utrzymanie kopii zbioru danych, wybór węzła podstawowego i wykonywanie operacji odczytu. Działają jak kopia zapasowa, w której nowy członek może nie dodać natychmiast. W ten sposób będzie przechowywać zaktualizowane dane i może natychmiast zastąpić niedostępnego członka.

Członkowie zestawu ukrytych replik MongoDB

Są to członkowie bez połączenia z aplikacjami klienckimi. Są używane w przypadku obciążeń o innych wymaganiach dotyczących użycia niż inne elementy pomocnicze. Otrzymują tylko podstawowy ruch związany z replikacją, który występuje podczas początkowej synchronizacji.

Członkowie zestawu opóźnionych replik MongoDB

Kopiują one dane z pliku oplog węzła podstawowego w określonym czasie. Zawsze odzwierciedlają opóźniony stan lub poprzednią formę zestawu. Dlatego są ważne w wykrywaniu błędów i dają wskazówkę, jak można naprawić te błędy, na przykład, jeśli istnieje baza danych, która została upuszczona. Wybierając wielkość opóźnienia, należy wziąć to pod uwagę:

1. Czas trwania powinien być krótszy niż pojemność dziennika operacji, która w przypadku silników pamięci masowej WiredTiger, MMAPv1 i In-Memory wynosi 50 GB. W przeciwnym razie opóźniony członek nie może pomyślnie zreplikować operacji.
2. Czas opóźnienia powinien być równy lub nieco dłuższy niż oczekiwany czas trwania okna konserwacji.

Konfiguracja

Jest to członek o priorytecie zero, jest ukryty, a więc niewidoczny dla aplikacji i wreszcie może uczestniczyć w procesie wyborczym. Dlatego, aby skonfigurować priorytet, załóżmy, że masz 10 członków w swoim zestawie replik, możesz wybrać członka na pozycji n jako członek[n] i ustawić jego właściwości jako:

{
    “_id”: <num>, 
    “Host”: <hostname: port>,
    “Priority”: 0,
    “slaveDelay”: <seconds>,
    “Hidden”: true
} 

Lub używając powłoki mongo podłączonej do podstawowej, możesz uruchomić te polecenia, aby ustawić pierwszy element zestawu replik jako opóźniony:

cfg = rs.conf()
cfg.members[0].priority = 0
cfg.members[0].hidden = true
cfg.members[0].slaveDelay = 3600
rs.reconfig(cfg)

Po ustawieniu tych konfiguracji opóźnione pomocnicze nie mogą stać się podstawowymi, a zatem ukryte przed aplikacjami. Członek będzie opóźniony o 1 godzinę (3600 sekund) od operacji oplog.

Jak uruchomić zestaw replik

W tym przewodniku zobaczymy krok po kroku, jak możemy skonfigurować replikę ustawioną w MongoDB.

1. Załóżmy, że masz 3 mongodb, które chcesz zreplikować i są one skonfigurowane w następujący sposób:
   1. Mongod1.conf uruchomiony na porcie 27017
   2. Mongod2.conf uruchomiony na porcie 27018
   3. Mongod3.conf uruchomiony na porcie 27019

   Upewnij się, że dodano nazwę zestawu replik, która nie zmieni się w każdym pliku. Możesz to zrobić, dodając lub zmieniając wartość opcji replSet na wybraną nazwę.

2. Pierwszą instancję możemy uruchomić, uruchamiając

   sudo mongod --config /etc/mongo/mongod1.conf

   Dzieje się tak, jeśli nie masz działającej instancji mongod. Następnie zrób to samo dla innych instancji. Aby sprawdzić, czy na Twoim komputerze są uruchomione instancje

   ps -ax | grep mongo

   Otrzymasz taką listę:

   4328 ttys000    0:06.15 mongod
   4950 ttys001    0:00.00 grep mongo

   Oznacza to, że pierwsza instancja w MongoDB domyślnie działa na porcie 27017, stąd mamy ją jako pierwszą na liście. Jeśli uruchomiłeś inne, zostaną one również przedstawione na liście wraz z odpowiadającymi im adresami URL ścieżki. Aby połączyć się z instancją w powłoce mongo, uruchom to polecenie:

   mongo  --port port_number i.e mongo  --port 27017.

   Jednak w naszym przypadku musimy połączyć się z nazwą zestawu replik, więc musimy dodać tę nazwę do polecenia:

   mongod --replSet replicaSetName --dbpath /usr/local/var/mongo/mongod --port 27017

   W tym przypadku nasza replikaSetName =„testrep”

3. Sprawdźmy, czy jest jakiś zestaw replik włączony, uruchamiając rs.status()

   Jeśli otrzymasz wynik taki jak:

   {
       "ok" : 0,
       "errmsg" : "not running with --replSet",
       "code" : 76,
       "codeName" : "NoReplicationEnabled"
   }

   Oznacza to, że nie jest włączony żaden zestaw replik. W przeciwnym razie, jeśli otrzymasz wynik jako

   {
       "operationTime" : Timestamp(0, 0),
       "ok" : 0,
       "errmsg" : "no replset config has been received",
       "code" : 94,
       "codeName" : "NotYetInitialized",
       "$clusterTime" : {
           "clusterTime" : Timestamp(0, 0),
           "signature" : {
               "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
               "keyId" : NumberLong(0)
           }
       }
   }

   oznacza to, że replika nie została jeszcze zainicjowana.

4. Metoda rs.initiate() pomoże nam uruchomić nowy zestaw replik, a instancja, w której została zainicjowana, stanie się naszym głównym węzłem. Możemy więc zainicjować jeden w naszej instancji, uruchamiając metodę initial. rs.initiate().

5. Sprawdź ponownie stan zestawu replik, uruchamiając rs.status().members. Powinieneś teraz zobaczyć coś takiego

   "members" : [
           {
               "_id" : 0,
               "name" : "localhost:27018",
               "health" : 1,
               "state" : 1,
               "stateStr" : "PRIMARY",
               "uptime" : 577,
               "optime" : {
                   "ts" : Timestamp(1535301271, 1),
                   "t" : NumberLong(1)
               },
               "optimeDate" : ISODate("2018-08-26T16:34:31Z"),
               "syncingTo" : "",
               "syncSourceHost" : "",
               "syncSourceId" : -1,
               "infoMessage" : "could not find member to sync from",
               "electionTime" : Timestamp(1535301265, 1),
               "electionDate" : ISODate("2018-08-26T16:34:25Z"),
               "configVersion" : 1,
               "self" : true,
               "lastHeartbeatMessage" : ""
           }
       ]

   Cóż, dobrze iść. Nas interesuje opcja członków, ponieważ widzimy, że jest to tablica n z 1 członkiem. Zaznaczenie opcji stateStr pierwszego członka w tym przypadku jest ustawione na Podstawowy, co oznacza, że ​​będzie on działał jako nasz węzeł podstawowy.

6. Dodaj nowego członka do zestawu replik, używając jego nazwy hosta. Aby sprawdzić nazwę hosta podłączonej instancji, którą chcesz dodać, uruchom

   db.serverStatus().host

   Dostaniesz coś takiego

   ervername.local:27019

   Więc z PRIMARY możesz dodać kolejnego członka, uruchamiając to polecenie w powłoce mongo:

   rs.add("servername.local:27019");

7. Uruchom polecenie stanu

   rs.status().members

   Aby sprawdzić, czy zmiany zostały wprowadzone.

   Powinieneś mieć teraz coś takiego:

   [
       {
           "_id" : 0,
           "name" : "localhost:27018",
           "health" : 1,
           "state" : 1,
           "stateStr" : "PRIMARY",
           "uptime" : 11479,
           "optime" : {
               "ts" : Timestamp(1535312183, 1),
               "t" : NumberLong(1)
           },
           "optimeDate" : ISODate("2018-08-26T19:36:23Z"),
           "syncingTo" : "",
           "syncSourceHost" : "",
           "syncSourceId" : -1,
           "infoMessage" : "",
           "electionTime" : Timestamp(1535301265, 1),
           "electionDate" : ISODate("2018-08-26T16:34:25Z"),
           "configVersion" : 2,
           "self" : true,
           "lastHeartbeatMessage" : ""
       },
       {
           "_id" : 1,
           "name" : "127.0.0.1:27019",
           "health" : 1,
           "state" : 2,
           "stateStr" : "SECONDARY",
           "uptime" : 15,
           "optime" : {
               "ts" : Timestamp(1535312183, 1),
               "t" : NumberLong(1)
           },
           "optimeDurable" : {
               "ts" : Timestamp(1535312183, 1),
               "t" : NumberLong(1)
           },
           "optimeDate" : ISODate("2018-08-26T19:36:23Z"),
           "optimeDurableDate" : ISODate("2018-08-26T19:36:23Z"),
           "lastHeartbeat" : ISODate("2018-08-26T19:36:26.302Z"),
           "lastHeartbeatRecv" : ISODate("2018-08-26T19:36:27.936Z"),
           "pingMs" : NumberLong(0),
           "lastHeartbeatMessage" : "",
           "syncingTo" : "localhost:27018",
           "syncSourceHost" : "localhost:27018",
           "syncSourceId" : 0,
           "infoMessage" : "",
           "configVersion" : 2
       }
   ]

   Mamy teraz 2 członków, jeden jest węzłem PODSTAWOWYM, a drugi węzłem WTÓRNYM. Możesz dodać więcej członków, ale nie więcej niż 50. Teraz stwórzmy bazę danych w instancji na porcie 27018 jako podstawową.

   

   Jeśli odłączymy podstawową, nastąpi przełączenie awaryjne, a ponieważ mamy tylko 1 podstawową, zostanie ona automatycznie przeniesiona na drugorzędną. Teraz, jeśli połączymy się z tym na porcie 27019, powinieneś otrzymać te same bazy danych i kolekcje z ich dokumentami.

   

   Teraz, jeśli odłączony węzeł główny zostanie ponownie podłączony, zostanie dodany jako drugorzędny, ponieważ kopiuje operacje z oploga istniejącego węzła głównego.

Problem związany z zapisem zestawu replik MongoDB

Jeśli MongoDB zwróci pomyślny problem dotyczący zapisu w dzienniku, dane zostaną zapisane na dysku, a tym samym staną się dostępne po ponownym uruchomieniu mongod. Jednak w przypadku operacji zapisu dane są trwałe dopiero po ich zreplikowaniu i zapisaniu do dziennika na korzyść większości członków z prawem głosu w zestawie replik.

Niektóre dane mogą być zbyt duże do zaktualizowania lub wstawienia, dlatego replikacja danych na innych elementach członkowskich może potrwać dłużej niż oczekiwano. Z tego powodu zaleca się edycję konfiguracji writeConcern, aby uwzględnić czas, w którym operacja ma być wykonana. Domyślne konfiguracje writeConcern narzucają, że zestaw replik wymaga potwierdzenia tylko od podstawowego elementu członkowskiego. Domyślny problem dotyczący zapisu potwierdza operacje zapisu tylko dla elementu podstawowego, ale można go zastąpić, aby sprawdzić operacje zapisu na niektórych elementach zestawu replik, określając problem dotyczący zapisu dla określonej operacji zapisu. Na przykład:

db.books.insert({name: “James”,place: “Beijing”},{writeConcern: {w: 3, wtimeout: 3600}})

Opcja zapisu w tym przypadku dyktuje, że operacja powinna zwrócić odpowiedź dopiero po rozprzestrzenieniu się na główną i co najmniej 2 wtórne lub po przekroczeniu limitu czasu po 3,6 sekundy.

Konfigurowanie problemu zapisu dla MongoDB

Opcja MongoDB getLastErrorDefaults daje nam parametry do zmiany domyślnych ustawień dotyczących zapisu w konfiguracji zestawu replik. Oznacza to, że operacja musi zostać zakończona u większości głosujących członków przed zwróceniem wyniku.

cfg = rs.conf()
cfg.settings = {},
cfg.settings.getLastErrorDefaults = {w: “majority”, wtimeout: 3600}
rs.reconfig(cfg)

Wartość limitu czasu zapobiegnie blokowaniu operacji zapisu, co oznacza, że ​​jeśli powinno być 5 członków, aby potwierdzić problem z zapisem, ale niestety w zestawie replik jest 4 lub mniej członków, operacja zostanie zablokowana, dopóki wszystkie elementy nie będą dostępne. Dodając próg limitu czasu, blokowanie operacji zostanie odrzucone po upływie tego czasu.

Blokowanie replikacji

Zablokowanie operacji, zwłaszcza gdy wszystkie elementy członkowskie zostały zreplikowane, zapewnia, że ​​nie będzie więcej marnowania czasu na oczekiwanie na kolejny element zestawu replik, który będzie dostępny w celu zwrócenia odpowiedzi. Opcja polecenia MongoDB getLastError określa sposób przeprowadzania aktualizacji replikacji za pomocą opcjonalnego atrybutu „w”.

Na przykład to zapytanie

db.runCommand({getLastError: 1, w: N, “wtimeout”: 5000});

wymaga, aby blokowanie występowało do momentu, gdy liczba N członków zreplikowała ostatnią operację zapisu. Jeśli N jest dostępne lub jest mniejsze niż 2, zapytanie zostanie zwrócone. W przeciwnym razie, jeśli wartość dla N jest równa 2, główny odpowiednik głównego, odpowie dopiero po zreplikowaniu 1 z jego podrzędnych do ostatniej operacji.

przekroczenie limitu czasu parametr służy zasadniczo do ustawienia czasu w milisekundach, po którym polecenie getLastError przekroczy limit czasu i zwróci błąd, zanim ostatnia opcja zostanie zreplikowana.

O ile blokowanie jest w jakiś sposób korzystne, czasami ma swoje ograniczenia. To znacznie spowalnia operacje odczytu, zwłaszcza jeśli ustawisz wartość „w” na zbyt dużą. Zalecam ustawienie wartości „w” na 2 lub 3 w celu zwiększenia bezpieczeństwa i wydajności.

Preferencje odczytu w MongoDB

Jest to w zasadzie sąsiednia trasa, za pomocą której klient wykonuje operacje odczytu do zestawu replik. Domyślna konfiguracja MongoDB konfiguruje operacje odczytu na podstawową, ponieważ jest to ta z najnowszą wersją pobieranego dokumentu. Jak wspomniano wcześniej, nadrzędną zaletą wykorzystania zestawu replik jest poprawa wydajności naszego systemu bazodanowego. Dlatego zaleca się dystrybucję operacji odczytu do wielu drugorzędnych elementów członkowskich, aby zmniejszyć opóźnienia dla aplikacji, które niekoniecznie wymagają aktualnych danych. Istnieją jednak ważniejsze powody, dla których powinieneś również używać podstawowej jako swojej podstawowej preferencji:

1. Utrzymywanie dostępności danych podczas przełączania awaryjnego.
2. W przypadku aplikacji rozproszonych geograficznie podstawowa zapewni odczyty lokalne klientom w tym samym centrum danych.
3. Nie wpływa na aplikacje front-endowe, zwłaszcza te, które uruchamiają operacje systemowe.

Mongo.setReadPref() Metoda

Ta metoda polega zasadniczo na zdefiniowaniu sposobu, w jaki klient będzie kierować wszystkie zapytania do członków zestawu replik. Zajmuje 2 argumenty, tryb i zestaw tagów.

Argument mode określa preferencję odczytu, która może być podstawowa, podstawowaPreferowana, wtórna, wtórnaPreferowana lub najbliższa.

Tryb tagSet określa niestandardową preferencję odczytu. Możesz także określić je jako tablicę obiektów. Przykładem konfiguracji będzie:

db.getMongo().setReadPref('primaryPreferred',
                          [ { "dc": "east", "use": "production" },
                            { "dc": "east", "use": "reporting" },
                            { "dc": "east" },
                            {}
                          ] )

Dzieje się tak, że jeśli klient spróbuje uzyskać dostęp do pierwszego tagu, a żądanie nie przejdzie, zostanie wybrany drugi preferencję odczytu.

Tryby preferencji odczytu

• Podstawowy:określa, że ​​wszystkie operacje odczytu odczytywane z danego zestawu replik są podstawowe i jest domyślnym preferowanym trybem odczytu.
• PrimaryPreferred:Jeśli tylko podstawowy nie jest dostępny, operacje odczytu można wykonać z drugorzędnych.
• Dodatkowe:wszystkie operacje odczytu są wykonywane z drugorzędnych elementów zestawu replik.
• SecondaryPreferred:jeśli tylko nie jest dostępny drugorzędny, operacje odczytu można wykonać z podstawowego.
• Najbliższy:członek z najmniejszym opóźnieniem sieci jest wybierany do operacji odczytu, niezależnie od jego typu.

Zestawy tagów i ich konfiguracja

Są to opcje, które umożliwiają modelowanie sposobu, w jaki mają wyglądać Twoje preferencje dotyczące pisania i czytania. Są one przechowywane w obiekcie konfiguracyjnym zestawu replik. Jeśli uruchomisz rs.conf().members, zwrócisz ten obiekt:

[
    {
        "_id" : 0,
        "host" : "localhost:27018",
        "arbiterOnly" : false,
        "buildIndexes" : true,
        "hidden" : false,
        "priority" : 1,
        "tags" : {
            
        },
        "slaveDelay" : NumberLong(0),
        "votes" : 1
    },
    {
        "_id" : 1,
        "host" : "127.0.0.1:27019",
        "arbiterOnly" : false,
        "buildIndexes" : true,
        "hidden" : false,
        "priority" : 1,
        "tags" : {
            
        },
        "slaveDelay" : NumberLong(0),
        "votes" : 1
    }
]

Jak widać, każdy członek ma atrybut tagów.

Główna różnica między preferencjami odczytu a problemem zapisu polega na tym, że ta pierwsza uwzględnia wartość znacznika podczas wybierania elementu do odczytu, podczas gdy ta druga nie.

Załóżmy, że znacznik ustawiony dla operacji odczytu jest ustawiony na:

{ "disk": "ssd", "use": "reporting" }

Członek zestawu replik musi wypełnić te znaczniki, aby mogła przejść operacja odczytu. Dlatego można powiedzieć, że konfiguracja taka jak ta

{ "disk": "ssd", "use": "reporting", "rack": "a" }

zaspokoi zapytanie, podczas gdy to

{ "disk": "ssd", "use": "production", "rack": "k" }

nie zaspokoi zapytania.

Dodawanie tagów do zestawu replik

Dla wybranego członka w zestawie replik możesz dodać zestawy tagów za pomocą metody rs.conf() w MongoDB.

Załóżmy, że wybrałeś członka na pozycji 1 tablicy zestawu replik, możesz dodać zestawy tagów w następujący sposób.

conf = rs.conf()
conf.members[0].tags = { "dc": "NYK", "use": "production"  }
conf.members[1].tags = { "dc": "LON", "use": "reporting"  }
conf.members[2].tags = { "use": "production"  }
rs.reconfig(conf)

Wzorce wdrażania zestawu replik MongoDB

1. Zestaw replik rozproszonych geograficznie — zwiększa nadmiarowość danych, oprócz ochrony danych przed awariami, takimi jak utrata zasilania. Uruchomione instancje znajdują się w wielu lokalizacjach.
2. Trzyczłonowy zestaw replik — podstawowa standardowa architektura zestawu replik.
3. Cztery lub więcej elementów zestawu replik — umożliwia szerszą nadmiarowość danych, a także obsługuje szerszą dystrybucję operacji odczytu w zestawie replik.

Techniki dostrajania zestawu replik MongoDB

Idealny zestaw replik będzie wymagał dobrze rozplanowanej architektury z co najmniej 3 elementami dla systemu produkcyjnego. Te strategie wdrażania pomogą Ci stworzyć świetny zestaw replik.

1. Używaj opóźnionych i ukrytych członków do obsługi dedykowanych funkcji, takich jak raportowanie i tworzenie kopii zapasowych.
2. Zawsze postaraj się, aby liczba wdrożonych członków była nieparzysta. Jak omówiliśmy powyżej, do wyboru prawyborów wymagana będzie nieparzysta liczba członków. Dlatego upewnij się, że masz nieparzystą liczbę, a jeśli nie, zawsze możesz dodać arbitra.
3. W przypadku wdrożeń z dużym obciążeniem odczytem konieczne będzie zrównoważenie obciążenia. W związku z tym konieczne będzie dystrybuowanie odczytów do drugorzędnego w celu poprawy wydajności odczytu. Poza tym, gdy dane rosną z czasem, możesz dodać więcej członków i rozpowszechniać je, ale pamiętaj, że musisz je skonfigurować w taki sposób, aby najważniejszym projektem było wybranie głównego.
4. Zawsze bierz pod uwagę odporność na awarie. Jest to zasadniczo określenie, ilu członków może być niedostępnych w danym czasie i ilu pozostanie, aby podtrzymać proces wyboru prawyborów. Jeśli nie masz podstawowego, niestety zestaw replik nie zaakceptuje żadnej operacji zapisu.
5. Dodaj nowych członków do istniejącego zestawu replik, zanim pojawi się zapotrzebowanie.
6. Użyj zestawów tagów zestawu replik, aby zapewnić replikację wszystkich operacji w określonych centrach danych. Możesz również użyć tych tagów w routingu dla operacji odczytu dla określonych maszyn wdrożeniowych.
7. Umieść większość członków w jednym miejscu, aby uniknąć niepowodzeń wynikających z partycjonowania sieci. Partycjonowanie sieci może być wynikiem braku komunikacji między centrami danych, co w konsekwencji utrudnia proces replikacji i proces wyboru podstawowego.
8. Ze względów bezpieczeństwa rozmieszczaj członków geograficznie poza ukrywaniem niektórych. Możesz ustawić priorytet co najmniej 2 lub 3 członków na zero, aby zapobiec uczynieniu ich głównymi.
9. Zastosuj kronikowanie, aby chronić utratę danych, która może spowodować coś takiego jak awaria zasilania. Zapewnia to zapis danych na dysku w przypadku nagłego wyłączenia.

Dziennik operacji (Oplog)

Oplog przechowuje zapis operacji głównych, które mają być zastosowane do urządzeń podrzędnych. Jest przechowywany w bazie danych o nazwie local w kolekcji oplog.$main. Jest tworzony podczas pierwszego uruchomienia elementu zestawu replik. W górnej granicy rozmiar oploga jest ograniczony do 50 GB dla wszystkich silników pamięci masowej. Rozmiar oploga można zmienić z ustawienia domyślnego. Jeśli ten rozmiar zostanie osiągnięty na przykład w ciągu 24 godzin pracy, wtórne nie będą w stanie wygodnie kopiować z niego w tym czasie i mogą w ogóle nie kopiować. Możesz zmienić rozmiar oploga za pomocą opcji replSetResizeOplog, tj.

db.database({replSetResizeOplog:1, size: 16384})

Jeśli chcesz zmniejszyć rozmiar tego oploga, spowoduje to usunięcie niektórych danych. Główny wpływ tego w zestawie replik polega na tym, że elementy członkowskie zsynchronizowane z tym węzłem stają się przestarzałe. Dlatego konieczne będzie ponowne zsynchronizowanie tych członków.

Wzorce obciążenia, które wymagałyby dużego rozmiaru Oploga

1. Aktualizuj do wielu dokumentów jednocześnie. Wiele operacji aktualizacji musi zostać przetłumaczonych na pojedynczą operację, aby poprawić wyniki we wszystkich węzłach. Ta operacja wykorzysta ogromną przestrzeń przestrzeni oplog.
2. Znaczna liczba aktualizacji w miejscu. Zwykle dzieje się tak podczas aktualizacji danych dokumentów, niekoniecznie zwiększając rozmiar tego dokumentu. Baza danych zarejestruje dużą liczbę operacji w oplogu, zwiększając tym samym jego rozmiar.
3. Usunięcia są równe tej samej ilości danych co wstawienia. Dzieje się tak, gdy próbujesz usunąć ilość danych (prawie) równą ilości danych, które wstawiasz. Ta operacja będzie miała tendencję do zwiększania rozmiaru oploga.

Wniosek

Replikacja to jeden z ważnych aspektów baz danych, który programiści muszą zrozumieć. Zapewnia zwiększoną dostępność danych. Twój serwer MongoDB może ulec awarii, na przykład z powodu przerwy w dostawie prądu, ale nadal chcesz, aby Twoi klienci mieli dostęp do jego danych. Jeśli masz zreplikowane dane na innym serwerze, klienci będą mogli nadal uzyskiwać z niego dostęp do danych, jeśli serwer podstawowy ulegnie awarii. Poza tym istnieje zwiększone równoważenie obciążenia, dzięki czemu zamiast wszystkich użytkowników uzyskujących dostęp do jednego serwera, widzieliśmy kompromisy związane z obsługą ruchu z replik wtórnych.