Co je řetězová replikace?
Když mluvíme o replikaci, máme na mysli proces vytváření redundantních kopií dat za účelem splnění návrhových kritérií dostupnosti dat. Řetězová replikace tedy odkazuje na lineární řazení serverů MongoDB tak, aby vytvořily synchronizovaný řetězec. Řetězec obsahuje primární uzel, následovaný sekundárními servery uspořádanými lineárně. Jak naznačuje řetězec slov, server nejblíže primárnímu serveru se z něj replikuje, zatímco každý další následující sekundární server se replikuje z předchozího sekundárního serveru MongoDB. Toto je hlavní rozdíl mezi zřetězenou replikací a normální replikací. Zřetězená replikace nastane, když sekundární uzel vybere svůj cíl pomocí času ping nebo když je nejbližší uzel sekundární. Ačkoli řetězová replikace, jak se zdá, snižuje zatížení primárního uzlu, může způsobit zpoždění replikace.
Proč používat řetězovou replikaci?
Systémové infrastruktury někdy trpí nepředvídatelnými poruchami, které vedou ke ztrátě serveru, a tím ovlivňují dostupnost. Replikace zajišťuje, že nepředvídatelná selhání neovlivní dostupnost. Replikace dále umožňuje zotavení po selhání hardwaru a přerušení služby. Zřetězená i nezřetězená replikace slouží tomuto účelu zajištění dostupnosti i přes selhání systému. Po zjištění, že replikace je důležitá, se můžete zeptat, proč používat řetězovou replikaci konkrétně. Mezi zřetězenou a nezřetězenou replikací v MongoDb není žádný rozdíl ve výkonu. V obou případech, kdy primární uzel selže, sekundární servery hlasují pro nového fungujícího primárního, a proto zápis a čtení dat není v obou případech ovlivněno. Zřetězená replikace je však výchozím typem replikace v MongoDb.
Jak nastavit repliku řetězu
Ve výchozím nastavení je v MongoDB povolena zřetězená replikace. Budeme se proto podrobněji zabývat procesem deaktivace řetězové replikace. Hlavním důvodem, proč lze řetězovou replikaci zakázat, je, že způsobuje zpoždění. Podstata řetězové replikace je však lepší než nevýhoda zpoždění, a proto je ve většině případů deaktivace zbytečná. V případě, že řetězová replikace není ve výchozím nastavení aktivní, pomohou vám s aktivací následující příkazy.
cfg = rs.config()
cfg.settings.chainingAllowed = true
rs.reconfig(cfg)Tento proces je reverzibilní. Když jste nuceni deaktivovat řetězovou replikaci, následuje nábožensky následující proces.
cfg = rs.config()
cfg.settings.chainingAllowed = false
rs.reconfig(cfg)Tipy a triky pro řetězovou replikaci
Nejstrašnějším omezením řetězové replikace je zpoždění replikace. Prodleva replikace se týká zpoždění, ke kterému dochází mezi časem, kdy je operace provedena na primárním místě, a kdy je stejná operace replikována na sekundárním. I když je to přirozeně nemožné, je vždy žádoucí, aby rychlost replikace byla při tomto zpoždění replikace nulová. Aby se zabránilo nebo minimalizovalo zpoždění replikace, aby se blížilo nule, je rozumné použít primární a sekundární hostitele se stejnými specifikacemi, pokud jde o CPU, RAM, IO a specifikace související se sítí.
Přestože řetězová replikace zajišťuje dostupnost dat, lze řetězovou replikaci používat společně s žurnálováním. Žurnálování zajišťuje bezpečnost dat zápisem do protokolu, který je pravidelně zapisován na disk. Když se tyto dva zkombinují, tři servery jsou zapsány na žádost o zápis na rozdíl od samotné řetězové replikace, kde jsou na žádost o zápis zapsány pouze dva servery.
Dalším důležitým tipem je použití w s replikací. Parametr w řídí počet serverů, na které by měla být zapsána odpověď, než se vrátí úspěšná. Když je nastaven parametr w, getlasterror zkontroluje oplog serverů a počká, dokud daný počet serverů „w“ neprovede operaci.
Použití monitorovacího nástroje, jako je MongoDB Monitoring Service (MMS) nebo ClusterControl, vám umožní získat stav vašich replikových uzlů a vizualizovat změny v průběhu času. Například v MMS můžete najít replikované grafy zpoždění sekundárních uzlů ukazující změny v době zpoždění replikace.
Měření výkonu řetězové replikace
Nyní jste si vědomi toho, že nejdůležitějším parametrem výkonu řetězové replikace je doba zpoždění replikace. Budeme proto diskutovat o tom, jak testovat dobu zpoždění replikace. Tento test lze provést prostřednictvím skriptu prostředí MongoDb. Abychom provedli test zpoždění replikace, porovnáme oplog poslední události na primárním uzlu a oplog poslední události na sekundárním uzlu.
Chcete-li zkontrolovat informace o primárním uzlu, spustíme následující kód.
db.printSlaveReplicationInfo()Výše uvedený příkaz poskytne informace o všech nedávných operacích na primárním uzlu. Výsledky by měly vypadat jako níže.
rs-ds046297:PRIMARY db.printSlaveReplicationInfo()
source: ds046297-a1.mongolab.com:46297
synced To: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
= 7475 secs ago (2.08hrs)
source: ds046297-a2.mongolab.com:46297
synced To: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
= 7475 secs ago (2.08hrs)Po získání oplogu pro primární uzel nás nyní zajímá oplog pro sekundární uzel. Následující příkaz nám pomůže získat oplog.
db.printReplicationInfo()Tento příkaz poskytne výstup s podrobnostmi o velikosti oplog, délce protokolu, čase pro první událost oplog, čase pro poslední událost oplog a aktuálním čase. Výsledky se zobrazí níže.
rs-ds046297:PRIMARY db.printReplicationInfo()
configured oplog size: 1024MB
log length start to end: 5589 secs (1.55hrs)
oplog first event time: Tue Mar 05 2013 06:15:19 GMT-0800 (PST)
oplog last event time: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
now: Tue Mar 05 2013 09:53:07 GMT-0800 (PST)Z oplogu primárního serveru došlo k poslední synchronizaci v úterý 5. března 2013 07:48:19 GMT-0800 (PST). Z oplogu sekundárního serveru k poslední operaci došlo v úterý 5. března 2013 07:48:19 GMT-0800 (PST). Zpoždění replikace bylo nulové, a proto náš řetězově replikovaný systém funguje správně. Časová prodleva replikace se však může lišit v závislosti na množství změn, které je třeba replikovat.