Odstraňování problémů se sdíleným clusterem MongoDB

Výběr Shard Keys a Cluster Availability

Sharding zahrnuje rozdělení dat do malých skupin nazývaných fragmenty, aby se snížilo celkové pracovní zatížení pro danou propustnost úkon. Tohoto seskupení je dosaženo výběrem optimálního klíče, což je hlavně nejdůležitější část před shardováním. Optimální klíč by měl zajistit:

1. Mongové mohou většinu dotazů izolovat na konkrétního mongoda. Pokud je například více operací podrobeno jednomu datovému fragmentu, selhání tohoto fragmentu způsobí, že pouze data s ním spojená nebudou v daném okamžiku chybět. Je vhodné vybrat shard klíč, který poskytne více shardů, aby se snížilo množství nedostupných dat v případě selhání fragmentu.
2. MongoDB bude moci rozdělit data rovnoměrně na části. To zajišťuje, že propustnost operací bude také distribuována rovnoměrně, čímž se sníží šance na jakékoli selhání v důsledku větší zátěže.
3. Škálovatelnost zápisu napříč clusterem pro zajištění vysoké dostupnosti. Každý fragment by měl být sadou replik v tom smyslu, že pokud určitá instance mongoda selže, zbývající členové sady replik jsou schopni zvolit jiného člena jako primárního, a tím zajistit provozní kontinuitu.

Pokud má daný fragment v každém případě tendenci selhat, začněte tím, že zkontrolujete, kolik operací propustnosti podléhá a zvažuje výběr lepšího shardovacího klíče, aby měl více úlomků.

Co když? Instance Mongos chybí

Nejprve zkontrolujte, zda se připojujete ke správnému portu, protože jste se mohli nevědomky změnit. Například při nasazení s platformou AWS existuje pravděpodobnost tohoto problému kvůli skupinám zabezpečení, které nemusí povolit připojení na tomto portu. Pro okamžitý test zkuste zadat úplný hostitel:port, abyste se ujistili, že používáte rozhraní zpětné smyčky. Dobrá věc je, že pokud má každý aplikační server svou vlastní instanci mongos, mohou aplikační servery pokračovat v přístupu k databázi. Kromě toho se jejich stavy mongos mění s časem a mohou se restartovat bez nutnosti ztráty dat. Když je instance znovu připojena, získá kopii konfigurační databáze a začne směrovat dotazy.

Ujistěte se, že port, ke kterému se pokoušíte znovu připojit, také není obsazen jiným procesem.

Co když? Člen se stane nepřítomným v sadě replik úlomků

Začněte kontrolou stavu datového fragmentu spuštěním příkazu sh.status(). Pokud vrácený výsledek nemá clusterId, pak je fragment skutečně nedostupný. Vždy prozkoumejte přerušení a selhání dostupnosti a pokud se vám nepodaří jej obnovit v co nejkratším čase, vytvořte nového člena, který jej co nejdříve nahradí, abyste předešli další ztrátě dat.

Pokud se sekundární člen stane nedostupným, ale s aktuálními položkami oplogu, po opětovném připojení může dohnat poslední nastavený stav čtením aktuálních dat z oplogu jako normální replikační proces. Pokud se nepodaří replikovat data, musíte provést počáteční synchronizaci pomocí jedné z těchto dvou možností...

1. Restartujte mongoda s prázdným datovým adresářem a nechte data obnovit běžnou funkcí počáteční synchronizace MongoDB. Tento přístup však trvá dlouho, než se data zkopírují, ale poměrně přímočaré.
2. Restartujte hostitelský počítač s kopií aktuálního datového adresáře od jiného člena v sadě replik. Rychlý proces, ale se složitými kroky

Počáteční synchronizace umožní MongoDB...

1. Klonujte všechny dostupné databáze kromě lokální databáze. Ujistěte se, že cílový člen má v místní databázi dostatek místa na disku k dočasnému uložení záznamů oplog po dobu kopírování dat.
2. Použijte  všechny změny na soubor dat pomocí oplogu ze zdroje. Proces bude dokončen pouze v případě, že stav repliky přejde z STARTUP2 na SECONDARY.

Co když? Všichni členové sady replik jsou nepřítomní

Data uložená ve fragmentu budou nedostupná, pokud nebudou chybět všichni členové fragmentu sady replik. Protože ostatní fragmenty zůstávají dostupné, operace čtení a zápisu jsou stále možné, kromě toho, že aplikace bude obsluhována částečnými daty. Budete muset prozkoumat příčinu přerušení a pokusit se znovu aktivovat fragment co nejdříve. Zkontrolujte, který profilovač dotazů nebo metoda vysvětlení, co mohlo vést k tomuto problému.

Co když? Zastaralá konfigurační data vedou k selhání kurzoru

Někdy může instanci mongos trvat dlouho, než aktualizuje mezipaměť metadat z konfigurační databáze, což vede k návratu dotazu varování: 

could not initialize cursor across all shards because : stale config detected

Tato chyba se bude zobrazovat vždy, dokud instance mongos neobnoví své mezipaměti. To by se nemělo šířit zpět do aplikace. Chcete-li to vyřešit, musíte vynutit aktualizaci instance spuštěním fluRouterConfig.

Pro vyprázdnění mezipaměti pro konkrétní běh sbírky

db.adminCommand({ flushRouterConfig: "<db.collection>" } )

Vyprázdnění mezipaměti pro konkrétní běh databáze 

db.adminCommand({ flushRouterConfig: "<db>" } )

Pro vyprázdnění mezipaměti pro všechny databáze a jejich kolekce spusťte:

db.adminCommand("flushRouterConfig")

db.adminCommand( { flushRouterConfig: 1 } )

Co když? Konfigurační server se stává nedostupným

Konfigurační server lze v tomto případě považovat za primárního člena, ze kterého sekundární uzly replikují svá data. Pokud nebude chybět, dostupné sekundární uzly budou muset zvolit jednoho ze svých členů, který se stane primárním. Abyste se nedostali do situace, kdy možná nebudete mít konfigurační server, zvažte distribuci členů sady replik mezi dvě datová centra, protože...

• Pokud dojde k výpadku jednoho datového centra, data budou stále dostupná pro čtení, nikoli žádné operace, pokud jste použili jediné datové centrum .
• Pokud dojde k výpadku datového centra, které zahrnuje menšinové členy, sada replik může stále sloužit operacím zápisu i čtení.

Je vhodné rozdělit členy alespoň do tří datových center.

Další možností distribuce je rovnoměrně rozdělit členy nesoucí data mezi dvě datová centra a zbývající členy v cloud.

Oprava chyby řetězce databáze

Od MongoDB 3.4 nejsou konfigurační servery SCCC podporovány pro zrcadlené instance mongodů. Pokud potřebujete upgradovat svůj sdílený cluster na verzi 3.4, musíte převést konfigurační servery z SCCC na CSRS.

Předcházení výpadkům při přesunu konfiguračních serverů

Prostoje mohou nastat v důsledku některých faktorů, jako je výpadek napájení nebo frekvence sítě, což může mít za následek selhání konfiguračního serveru do clusteru. Použijte CNAME k identifikaci tohoto serveru pro přejmenování nebo přečíslování během opětovného připojení. Pokud příkaz moveChunk commit během procesu migrace selže, MongoDB ohlásí chybu:

ERROR: moveChunk commit failed: version is at <n>|<nn> instead of

<N>|<NN>" and "ERROR: TERMINATING"

To znamená, že fragment také nebyl připojen ke konfigurační databázi, a proto primárního člena ukončí abyste se vyhnuli nekonzistenci dat. Selhání migrace chunků musíte vyřešit nezávisle na konzultaci s podporou MongoDB. Také zajistěte, aby byly clusteru poskytnuty stabilní zdroje, jako je síť a napájení.

Závěr

Sharded cluster MongoDB snižuje zátěž, které by byl vystaven jeden server, a tím zlepšuje výkon výkonových operací. Selhání při správné konfiguraci některých parametrů, jako je výběr optimálního klíče zlomku, však může způsobit nerovnováhu zatížení, a proto některé fragmenty selžou.

Za předpokladu, že je konfigurace provedena správně, mohou také nastat některé nevyhnutelné překážky, jako jsou výpadky proudu. Chcete-li pokračovat v podpoře vaší aplikace s minimálními prostoji, zvažte použití alespoň 3 datových center. Pokud jeden selže, ostatní budou k dispozici pro podporu operací čtení, pokud je primární mezi dotčenými členy. Upgradujte také svůj systém alespoň na verzi 3.4, protože podporuje více funkcí.