Průvodce vývojáře k sadám replik MongoDB

MongoDB často zahrnuje práci s velkou sadou dat včetně vložených polí a objektů polí. Proto je vždy důležité zajistit, aby rychlost zpracování databáze byla co nejrychlejší, aby se zlepšily operace čtení a zápisu. Kromě toho, abyste se vyhnuli datovým anomáliím, které mohou nastat v důsledku nekonzistence dat, musíte zajistit, aby vaše data byla ve zvýšené dostupnosti pro případ, že byste chtěli získat obnovu v případě selhání hardwaru nebo některých přerušení služeb. MongoDB poskytuje pro tento účel dva koncepty – ReplicaSets a Sharding.

Replikace v MongoDB

Replikace Master-Slave

Jedná se o jednu z nejstarších technik používaných k zajištění toho, aby data byla uživatelům vždy dostupná, i když jeden systém selhal. Replikace Master-Slave je však v nejnovějších verzích MongoDB od 3.2 zastaralá, a proto byla nahrazena sadami Replica.

Chcete-li provést tuto konfiguraci, jedna spustí 2 instance mongodů, přičemž jedna je v režimu master a druhá v režimu slave.

Chcete-li spustit instanci v hlavním režimu, spusťte:

mongod --master --port portNumber

Volby --master instruují mongoda, aby vytvořil kolekci local.oplog.$main, se kterou je seznam operací zařazen do fronty, aby je podřízené jednotky mohly použít při replikaci dat.

Chcete-li spustit instanci mongoda v režimu slave, stačí spustit:

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

Zde musíte zadat název hostitele a port hlavní instance do argumentu --source. Toto je souhrnný přehled používání replikace Master slave, a protože je zastaralá, budeme se zajímat o sady Replica.

Sady replik

Jedná se o skupinu procesů MongoDB známých jako instance mongod, které v podstatě hostí stejnou sadu dat. Vyznačuje se jedním primárním uzlem a několika sekundárními uzly pro ložisková data. Primární uzel přijímá všechny operace zápisu a zaznamenává všechny ostatní změny své datové sady do svého provozního protokolu. Sekundární uzly na druhém konci replikují primární protokol operací a aplikují operace na svou datovou sadu tak, aby jejich datové sady odrážely primární datovou sadu. Jednoduše řečeno, můžeme říci, že máme stroj A jako primární uzel a stroj B a C jako sekundární uzly. Stroj A přijme operaci zápisu a provede změny ve svých datech a poté vytvoří seznam změn, které byly provedeny. Stroje B a C poté zkopírují operace z poskytnutého seznamu, v tomto případě oplog, a provedou je tak, aby výsledná data byla stejná jako v počítači A.

Jak již bylo zmíněno, vždy je důležité zajistit vysokou dostupnost dat, zejména v produkčním prostředí. Replikace přichází na pomoc tím, že poskytuje redundanci dat v různých instancích Mongod. V případě ztráty dat, protože kopie stejných dat jsou uloženy v různých databázích na více místech, je snadné je obnovit ve stávající.

S mnoha spuštěnými instancemi jsou operace čtení a zápisu z klientů odesílány na různé servery, a proto se zvyšuje rychlost zpracování. Základní struktura procesu replikace je uvedena níže.

Někdy primární nemusí být dostupné, například kvůli odpojení internetu nebo přerušení služby. V tomto případě sada replik určí sekundární uzel jako primární uzel. I když jsou požadavky na čtení v zásadě zasílány na primární server, v některých případech mohou být požadavky na čtení odeslány na sekundární servery, ale buďte opatrní, protože vrácená data nemusí odrážet to, co je v primární části, nebo spíše nemusí být aktuální.

Rozhodci

V případě volby primárního budete potřebovat další instanci mongoda do sady replik, abyste mohli přidat hlas ve volebním procesu. Tato instance je označována jako arbitr a její hlavní rysy jsou:

Nemá kopii datové sady, a proto nevyžaduje tak výkonný hardware jako uzly nesoucí data.
Nelze povýšit na primárního uživatele.
Vždy mají 1 volební hlas, aby replika mohla mít lichý počet hlasujících členů bez režie dalšího člena, který replikuje data. Jeho klíčovou úlohou je tedy vybrat primární uzel, když není dostupný.
Zůstává beze změny.

Na rozdíl od arbitra lze jiné sady replik převést na primární ze sekundárních a naopak.

Asynchronní replikace

Proces replikace probíhá ve dvou formách synchronizace dat. Nejprve jsou členové v sadě naplněni úplnými daty při počáteční synchronizaci. Následná replikace se provádí za účelem aplikování postupujících změn na celou sadu dat.

Při počáteční synchronizaci jsou data zkopírována z jednoho člena sady replik do jiného. Když je proces dokončen, člen přejde do sekundárního uzlu.

Automatické převzetí služeb při selhání MongoDB

Může dojít k přerušení služby, jako je odpojení sítě, které přichází s důsledkem ukončení komunikace mezi primární a sekundární. Pokud odpojení trvá déle než 10 sekund nebo se nezdaří úplně, zbývající sada replik bude hlasovat pro člena, který se stane novým primárním. Sekundární uzel, který získá většinu hlasů, se stane novým primárním.

Ve verzi 3.0 MongoDB může mít sada replik až 50 členů se 7 hlasujícími členy.

Členové sady replik s nulovou prioritou

Jedná se o sekundární členy, kteří nemohou být ani primárními uzly, ani nemohou vyvolat volby. Klíčové role v sadě dat jsou:udržovat kopie sady dat, zvolit primární uzel a provádět operace čtení. Fungují jako záloha, kam se nový člen nemusí okamžitě přidat. Uloží tak aktualizovaná data a může okamžitě nahradit nedostupného člena.

Členové sady skrytých replik MongoDB

Jedná se o členy bez připojení ke klientským aplikacím. Používají se pro zátěže s odlišnými požadavky na použití než ostatní sekundární členové. Přijímají pouze základní replikační provoz, který probíhá během počáteční synchronizace.

Členové sady zpožděných replik MongoDB

Tyto zkopírují data ze souboru oplog primárního uzlu během určité stanovené doby. Vždy odrážejí zpožděný stav nebo předchozí podobu sestavy. Jsou proto důležité při zjišťování chyb a poskytují nápovědu, jak se lze z těchto chyb zotavit, například pokud existuje databáze, která byla zrušena. Při výběru velikosti zpoždění je třeba vzít v úvahu:

Doba trvání by měla být kratší než kapacita provozního protokolu, který je pro úložiště WiredTiger, MMAPv1 a In-Memory 50 GB. V opačném případě nemůže zpožděný člen úspěšně replikovat operace.
Doba zpoždění by měla být stejná nebo o něco delší než očekávaná doba údržby.

Konfigurace

Jedná se o člena s nulovou prioritou, je skrytý, tudíž není viditelný pro přihlášky a jako poslední se může zúčastnit volebního procesu. Chcete-li tedy nakonfigurovat prioritu, řekněme, že máte ve své sadě replik 10 členů, můžete vybrat člena na pozici n jako člena[n] a nastavit jeho vlastnosti jako:

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

Nebo pomocí mongo shellu připojeného k primárnímu můžete spustit tyto příkazy pro nastavení prvního člena sady replik jako zpožděného:

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

Po nastavení těchto konfigurací se zpožděný sekundární nemůže stát primárním, a proto skrytý před aplikacemi. Člen bude zpožděn o 1 hodinu (3600 sekund) od operací oplog.

Somenines Staňte se MongoDB DBA – Uvedení MongoDB do produkce Zjistěte, co potřebujete vědět, abyste mohli nasadit, monitorovat, spravovat a škálovat MongoDBDdownload zdarma

Jak spustit sadu replik

V této příručce krok za krokem uvidíme, jak můžeme nakonfigurovat sadu replik v MongoDB.

Řekněme, že máte 3 mongodb, které chcete replikovat, a jsou nakonfigurovány takto:
1. Mongod1.conf běží na portu 27017
2. Mongod2.conf běží na portu 27018
3. Mongod3.conf běží na portu 27019
Ujistěte se, že jste přidali název sady replik, který se v každém souboru nezmění. Můžete tak učinit přidáním nebo změnou hodnoty replSet na vámi zvolený název.
První instanci můžeme spustit spuštěním
```
sudo mongod --config /etc/mongo/mongod1.conf
```
To je, pokud nemáte spuštěnou instanci mongoda. Poté udělejte totéž pro ostatní instance. Chcete-li zkontrolovat spuštěné instance ve vašem počítači, spusťte
```
ps -ax | grep mongo
```
Získáte takový seznam:
```
4328 ttys000    0:06.15 mongod
4950 ttys001    0:00.00 grep mongo
```
To znamená, že první instance v MongoDB standardně běží na portu 27017, proto ji máme jako první v seznamu. Pokud jste spustili ostatní, budou také uvedeny v seznamu s odpovídajícími adresami URL cesty. Chcete-li se připojit k instanci v prostředí mongo, spusťte tento příkaz:
```
mongo  --port port_number i.e mongo  --port 27017.
```
V našem případě se však potřebujeme spojit s názvem sady replik, takže musíme k příkazu přidat tento název:
```
mongod --replSet replicaSetName --dbpath /usr/local/var/mongo/mongod --port 27017
```
V tomto případě naše replicaSetName =“testep”

Pojďme zkontrolovat, zda je povolena nějaká sada replik spuštěním rs.status()

Pokud dostanete výsledek jako:

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

Pak to znamená, že není povolena žádná sada replik. Jinak, pokud dostanete výsledek 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)
        }
    }
}

pak to znamená, že replika ještě není spuštěna.

Metoda rs.initiate() nám pomůže spustit novou sadu replik a instance, ve které je iniciována, se stane naším primárním uzlem. Můžeme tedy iniciovat jeden v naší instanci spuštěním metody zahájení. rs.initiate().

Znovu zkontrolujte stav sady replik spuštěním rs.status().members. Nyní byste měli vidět něco jako

"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" : ""
        }
    ]

Dobře, dobře jít. Naším zájmem bude volba členů, jak vidíme, je to n pole s 1 členem. Zaškrtnutím možnosti stateStr prvního člena je v tomto případě nastavena na Primární, což znamená, že bude fungovat jako náš primární uzel.

Přidejte nového člena do sady replik pomocí názvu hostitele. Chcete-li zkontrolovat název hostitele připojené instance, kterou chcete přidat, spusťte
```
db.serverStatus().host
```
Dostanete něco jako
```
ervername.local:27019
```
Takže z PRIMARY můžete přidat dalšího člena spuštěním tohoto příkazu v mongo shell:
```
rs.add("servername.local:27019");
```

Spusťte příkaz status

rs.status().members

Chcete-li zkontrolovat, zda byly změny provedeny.

Nyní byste měli mít něco, co vypadá takto:

[
    {
        "_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
    }
]

Nyní máme 2 členy, jeden je PRIMÁRNÍ uzel a druhý SEKUNDÁRNÍ uzel. Můžete přidat další členy, ale nepřesahující 50. Nyní vytvoříme databázi v instanci na portu 27018 jako primární.

Pokud primární odpojíme, dojde k převzetí služeb při selhání a protože máme pouze 1 primární, automaticky se převede na sekundární. Nyní, když se připojíme k portu 27019, měli byste získat stejné databáze a sbírky s jejich dokumenty.

Nyní, pokud je odpojený primární uzel znovu připojen, bude přidán jako sekundární, protože kopíruje operace z oplog stávajícího primárního uzlu.

Obava zápisu sady replik MongoDB

Pokud MongoDB vrátí problém s úspěšným zápisem do žurnálu, data se uloží na disk, takže budou dostupná po restartu mongodu. Pro operace zápisu jsou však data trvalá pouze poté, co jsou replikována a předána do žurnálu ve prospěch většiny hlasujícího člena sady replik.

Některá data mohou být příliš velká na aktualizaci nebo vložení, a proto může replikace dat v jiných členech trvat déle, než se očekává. Z tohoto důvodu je vhodné upravit konfiguraci writeConcern tak, aby vyhovovala době, během níž má být operace provedena. Výchozí konfigurace writeConcern diktují, že sada replik vyžaduje potvrzení pouze od primárního člena. Výchozí problém zápisu potvrzuje operace zápisu pouze pro primární, ale lze ho přepsat, aby se zkontrolovaly operace zápisu u některých členů sady replik zadáním problému zápisu pro konkrétní operaci zápisu. Například:

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

Možnost zápisu v tomto případě určuje, že operace by měla vrátit odpověď pouze poté, co byla distribuována na primární a alespoň 2 sekundární, nebo pokud vyprší časový limit po 3,6 sekundách.

Konfigurace funkce Write Concern pro MongoDB

Možnost MongoDB getLastErrorDefaults nám poskytuje parametry pro změnu výchozího nastavení zápisu v konfiguraci sady replik. To znamená, že před vrácením výsledku musí být operace dokončena u většiny hlasujících členů.

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

Hodnota časového limitu zabrání blokování operací zápisu, to znamená, že pokud se předpokládá, že existuje 5 členů pro potvrzení problému se zápisem, ale bohužel jsou v sadě replik 4 nebo méně členů, operace se zablokuje, dokud nebudou k dispozici všichni členové. Přidáním prahové hodnoty časového limitu bude po uplynutí této doby blokování operace zrušeno.

Blokování replikace

Zablokování operace, zejména když byli replikováni všichni členové, zajišťuje, že již nebude ztrácet čas čekáním, až bude k dispozici další člen sady replik, aby bylo možné vrátit odpověď. Možnost příkazu MongoDB getLastError určuje, jak se provádí aktualizace replikace pomocí volitelného atributu „w“.

Například tento dotaz

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

vyžaduje, aby k blokování docházelo, dokud N počet členů nereplikuje poslední operaci zápisu. Pokud je N k dispozici nebo je menší než 2, bude dotaz vrácen. V opačném případě, pokud je hodnota pro N rovna 2, bude hlavní zařízení ekvivalentní primárnímu zařízení reagovat až poté, co byl 1 z jeho podřízených zařízení replikován do poslední operace.

wtimeout Parametr je v podstatě k nastavení času v milisekundách, po kterém příkaz getLastError vyprší a vrátí chybu, než bude replikována poslední možnost.

Jakkoli je blokování nějak výhodné, někdy má omezení. Výrazně to zpomalí operace čtení, zvláště pokud nastavíte hodnotu „w“ na příliš velkou. Doporučil bych vám nastavit hodnotu „w“ na 2 nebo 3 pro lepší bezpečnost a účinnost.

Předvolby čtení v MongoDB

Toto je v podstatě přilehlá trasa, se kterou jsou prováděny operace čtení klienta se sadou replik. Výchozí nastavení MongoDB konfiguruje operace čtení na primární, protože to je ta s nejnovější verzí dokumentu, který načítáte. Jak již bylo zmíněno dříve, nejvyšší výhodou pro využití sady replik je zlepšení výkonu našeho databázového systému. Proto je vhodné distribuovat operace čtení na mnoho sekundárních členů, aby se snížila latence u aplikací, které nutně nevyžadují aktuální data. Existují však důležitější důvody, proč byste také měli používat primární jako základní preference:

Zachování dostupnosti dat během převzetí služeb při selhání.
U geograficky distribuovaných aplikací bude primární poskytovat místní čtení pro klienty ve stejném datovém centru.
Neovlivňovat front-end aplikace, zejména ty, na kterých běží systémové operace.

Mongo.setReadPref() Metoda

Tato metoda má v podstatě definovat, jak bude klient směrovat všechny dotazy na členy sady replik. Vyžaduje 2 argumenty, režim a sadu tagů.

Argument mode určuje preferenci čtení, která může být primární, primární Preferovaná, sekundární, sekundární Preferovaná nebo nejbližší.

Režim tagSet určuje vlastní předvolbu čtení. Můžete je také zadat jako pole objektů. Příklad nastavení bude:

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

Zde se stane, že pokud se klient pokusí o přístup k první značce a požadavek neprojde, bude zvolena předvolba druhého čtení.

Přečtěte si preferenční režimy

Primární:toto definuje, že všechny operace čtení čtené z dané sady replik jsou primární a jedná se o výchozí preferovaný režim čtení.
PrimaryPreferred:Pokud není k dispozici pouze primární, lze operace čtení provádět ze sekundárních.
Sekundární:všechny operace čtení se provádějí ze sekundárních členů sady replik.
SecondaryPreferred:Pokud není k dispozici žádný sekundární, lze operace čtení provádět z primárního.
Nejbližší:pro operaci čtení je vybrán člen s nejmenší latencí sítě bez ohledu na jeho typ.

Sady značek a jejich konfigurace

Toto jsou možnosti, které vám umožňují modelovat, jak chcete, aby vaše preference psaní a čtení vypadaly. Jsou uloženy v objektu konfigurace sady replik. Pokud spustíte rs.conf().members, vrátí se vám tento objekt:

[
    {
        "_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 můžete vidět, každý člen má atribut tags.

Hlavní rozdíl mezi předvolbami čtení a zájmem o zápis je v tom, že prvně jmenovaný zohledňuje hodnotu tagu při výběru člena, ze kterého se má číst, zatímco druhý nikoli.

Řekněme, že sada značek pro operaci čtení je nastavena na:

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

Člen v sadě replik musí splnit tyto značky, aby operace čtení prošla. Proto řečeno, konfigurace jako je tato

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

uspokojí dotaz, zatímco tento

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

nevyhoví dotazu.

Přidání značek do repliky sady

Pro vybraného člena v sadě replik můžete přidat sady značek pomocí metody rs.conf() v MongoDB.

Řekněme, že jste vybrali člena na pozici 1 pole sady replik, sady značek můžete přidat následovně.

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)

Vzory nasazení pro sadu replik MongoDB

Geograficky distribuovaná sada replik – kromě ochrany dat před chybami, jako je ztráta napájení, zvyšuje redundanci dat. Spuštěné instance jsou umístěny na více místech.
Tříčlenná sada replik – základní standardní architektura sady replik.
Sada čtyř nebo více členů – umožňuje širší redundanci dat a také podporuje širší distribuci operací čtení v sadě replik.

Postupy ladění nasazení sady replik MongoDB

Ideální sada replik bude vyžadovat dobře navrženou architekturu s alespoň 3 členy pro produkční systém. Tyto strategie nasazení vám pomohou povolit skvělou sadu replik.

Používejte zpožděné a skryté členy k podpoře vyhrazených funkcí, jako je vytváření sestav a zálohování.
Vždy nastavte počet nasazených členů lichý. Jak jsme uvedli výše, při volbě primárek bude zapotřebí lichý počet členů. Ujistěte se proto, že máte liché číslo, a pokud ne, vždy můžete přidat arbitra.
U nasazení s velkým množstvím čtení budete muset vyvážit zátěž. Budete proto muset distribuovat čtení na sekundární, aby se zlepšil výkon čtení. Kromě toho, když data časem rostou, můžete přidat další členy a distribuovat je, ale mějte na paměti, že je musíte nakonfigurovat tak, aby prvořadým návrhem bylo zvolit primárního.
Vždy zvažte odolnost proti chybám. To v podstatě určuje, kolik členů může být v danou dobu nedostupných a kolik jich zůstane, aby udrželo volební proces primárek. Pokud primární nemáte, sada replik bohužel nepřijme žádnou operaci zápisu.
Přidejte nové členy do stávající sady replik, než vznikne poptávka.
Použijte sady značek sady replik, abyste zajistili, že všechny operace budou replikovány v konkrétních datových centrech. Tyto značky můžete také použít při směrování operací čtení pro konkrétní počítače s nasazením.
Rozmístěte většinu svých členů na jedno místo, abyste se vyhnuli neúspěchu, který vznikne dělením sítě. Rozdělení sítě může být výsledkem odpojené komunikace mezi datovými centry, což následně brání procesu replikace a procesu volby primárního.
Z bezpečnostních důvodů rozmístěte své členy geograficky, kromě toho, že některé skryjte. Prioritu alespoň 2 nebo 3 členů můžete nastavit na nulu, abyste zabránili tomu, aby byli primární.
Použijte žurnálování k ochraně před ztrátou dat, která může mít za následek něco jako výpadek napájení. Tím je zajištěno, že data budou zapsána na disk v případě náhlého vypnutí.

Protokol operací (Oplog)

Oplog udržuje záznam o hlavních operacích, které mají být aplikovány na podřízené jednotky. Je uložen v databázi nazvané local v kolekci oplog.$main. Vytvoří se, když poprvé spustíte člena sady replik. Na horní hranici je velikost oplogu omezena na 50 GB pro všechny moduly úložiště. Velikost oplogu lze změnit z výchozího nastavení. Pokud je této velikosti dosaženo například za 24 hodin provozu, sekundární stanice z ní během této doby nebudou moci pohodlně kopírovat a může se stát, že nebudou kopírovat vůbec. Velikost oplogu můžete změnit pomocí volby replSetResizeOplog tj.

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

Pokud chcete zmenšit velikost tohoto oplogu, bude to mít za následek odstranění některých dat. Hlavním dopadem tohoto v sadě replik je to, že členové synchronizovaní s tímto uzlem zastarají. Proto budete muset tyto členy znovu synchronizovat.

Vzory pracovní zátěže, které by vyžadovaly velkou velikost Oplog

Aktualizujte na více dokumentů najednou. Vícenásobné operace aktualizace musí být převedeny na samostatnou operaci, aby se zlepšily výsledky napříč uzly. Tato operace bude využívat velký prostor oplogového prostoru.
Značný počet aktualizací na místě. To se obvykle stává, když aktualizace dat dokumentů nemusí nutně zvětšit velikost tohoto dokumentu. Databáze zaznamená do oplogu velký počet operací, čímž se zvětší jeho velikost.
Odstranění se rovná stejnému množství dat jako vložení. K tomu dochází, když se pokusíte odstranit množství dat (téměř) rovnající se množství dat, která vložíte. Tato operace bude mít tendenci zvětšit velikost oplogu.

Závěr

Replikace je jedním z důležitých aspektů databází, kterým musí vývojáři porozumět. Zajišťuje zvýšenou dostupnost dat. Váš server MongoDB může selhat, například kvůli výpadku napájení, ale přesto byste chtěli, aby vaši klienti měli přístup k jeho datům. Pokud jste replikovali data na jiném serveru, vaši klienti budou moci pokračovat v přístupu k datům z něj, pokud primární server selže. Kromě toho došlo ke zvýšenému vyvažování zátěže, takže místo toho, aby všichni uživatelé přistupovali k jedinému serveru, jsme viděli kompromisy v poskytování provozu ze sekundárních replik.