Cassandra generuje náhrobky při mazání dat. Za určitých okolností mohou přebytečné náhrobky způsobit dlouhé pauzy GC, latenci, selhání čtení nebo chyby haldy. Tento článek poskytuje rady pro správu náhrobků.

obsah

co je náhrobek?

v Cassandře nejsou smazaná data okamžitě vymazána z disku. Místo toho Cassandra píše speciální hodnotu, známou jako náhrobek, která označuje, že data byla smazána. Náhrobky zabránit smazaných dat před vrácením během čtení, a nakonec umožní data, která mají být zrušena prostřednictvím zhutnění.

náhrobky jsou zápisy-procházejí normální cestou zápisu, zabírají místo na disku a využívají mechanismů konzistence Cassandry. Náhrobky mohou být šířeny po celém clusteru pomocí rad a oprav. Pokud je cluster spravován správně, zajistí to, že data zůstanou smazána, i když je uzel při vydání odstranění nefunkční.

náhrobky jsou generovány:

• smazat příkazy
• nastavení TTLs
• vkládání hodnot null
• vkládání dat do částí sbírky.

jaký je normální životní cyklus náhrobků?

náhrobky jsou psány s časovým razítkem. Za ideálních okolností budou náhrobky (a jejich související údaje) během zhutňování po uplynutí určité doby upuštěny.

pro odstranění náhrobků musí být splněna následující tři kritéria:

• náhrobky byly vytvořeny před více než gc_grace_seconds.
• tabulka obsahující náhrobek se podílí na zhutnění.
• do zhutnění jsou zapojeny všechny sstably, které by mohly obsahovat relevantní údaje.

každá tabulka má nastavení gc_grace_seconds. Ve výchozím nastavení je toto nastaveno na 864000, což odpovídá 10 dnům. Záměrem je poskytnout clusteru čas k dosažení konzistence prostřednictvím oprav (a tím zabránit vzkříšení smazaných dat).

náhrobky budou zhutněny pouze tehdy, pokud jsou do zhutnění zapojeny všechny tabulky, které by mohly obsahovat příslušné údaje. Pokud mezi zápisem původních dat a vydáním DELETE uplynulo hodně času, je to méně pravděpodobné:

• strategie zhutnění s odstupňovanou velikostí zhutní sstables podobné velikosti dohromady. Data mají tendenci se pohybovat do větších sstables, jak stárne, takže náhrobek (v novém, malém sstablu) je nepravděpodobné, že by byl zhutněn s daty (ve starém, velkém sstablu).
• vyrovnaná strategie zhutňování je rozdělena do mnoha úrovní, které jsou zhutněny Samostatně. Náhrobek bude zapsán do úrovně 0 a bude účinně „pronásledovat“ data přes úrovně – nakonec by to mělo dohnat.
• Čas-Okna Zhutnění Strategie (nebo Datum-Stupňová Zhutnění Strategie) nikdy kompaktní náhrobku s daty, pokud jsou psány v různých časových windows.

kdy náhrobky způsobují problémy?

využití Disku

Když data odstraněna, prostor bude vlastně být osvobozen alespoň gc_grace lhůtě stanovené v tabulce nastavení. To může způsobit problémy, pokud se shluk rychle zaplní.

za určitých okolností nebude prostor nikdy uvolněn bez ručního zásahu.

výkon čtení

vážné problémy s výkonem mohou nastat, pokud čtení narazí na velké množství náhrobků.

problémy s Výkonem jsou nejvíce pravděpodobné, že se stane s následujícími typy dotazu:

• Dotazy, které běží přes všechny oddíly v tabulce („select * from keyspace.tabulka“)
• rozsah dotazů („select * from keyspace.tabulka kde hodnota > x“, nebo „kde hodnota v (value1, value2,…)“
• jakýkoli dotaz, který lze spustit pouze s klauzulí „povolit filtrování“.

tyto problémy s výkonem se vyskytují kvůli chování náhrobků během čtení. V dotazu rozsahu bude ovladač Cassandra normálně používat stránkování, což uzlům umožňuje vrátit omezený počet odpovědí najednou. Když cassandra náhrobky jsou zapojeny, uzel musí udržet náhrobků, že došlo v paměti a vrátí jim koordinátor, v případě, že jeden z repliky je vědom, že příslušné údaje byly vymazány. Náhrobky nelze stránkovat, protože je nezbytné, aby vrátit všechny z nich, takže latence a využití paměti zvýší úměrně k počtu náhrobky setkal.

zda se náhrobky vyskytnou, závisí na způsobu ukládání a načítání dat. Pokud se například Cassandra používá k ukládání dat do fronty (což se nedoporučuje), mohou se dotazy setkat s desítkami tisíc náhrobků, které vrátí několik řádků dat.

Jak mohu diagnostikovat problémy související s náhrobkem?

dotazy, které se setkávají s velkým počtem náhrobků, se zobrazí v protokolech. Ve výchozím nastavení vygeneruje čtení s více než tisícem náhrobků varování:

WARN org.Apač.cassandro.DB.ReadCommand číst 0 živé řádky a 87051 náhrobní buňky pro dotaz vyberte * z příkladu . tabulka

ve výchozím nastavení, setkání s více než 100,000 náhrobky způsobí selhání dotazu s Tombstoneoverwromingexception.

Chcete-li ověřit, zda čtení náhrobku způsobuje problémy s výkonem, zkontrolujte, zda čtení koreluje se zvýšením latence čtení a trvání pauzy GC.

Pokud je jasné, že náhrobky jsou otázky, následující techniky mohou pomoci zúžit rozsah problému:

• počet náhrobků se vrátil v konkrétní dotaz, lze nalézt spuštěním dotazu v cqlsh s trasování povoleno.
• statistiky počtu náhrobků, které se v poslední době vyskytly v každé tabulce, jsou k dispozici ve výstupu z nodetool cfstats.
• pro clustery v naší spravované službě jsou statistiky nedávno nalezených náhrobků k dispozici na stránce clusteru v seznamech metrik > informace o tabulce. To zahrnuje živé buňky na čtení a průměr a max náhrobky na čtení, členěné podle uzlu nebo tabulky pro dané časové období.
• podrobnější informace o uložených náhrobcích lze nalézt pomocí ic-tools.

jak se mohu vyhnout problémům s náhrobkem?

následující možnosti:

• Vyhněte se dotazy, které poběží na všech příčky v tabulce (např. dotazy bez klauzule where, nebo jakýkoliv dotaz, který vyžaduje UMOŽŇUJÍ FILTROVÁNÍ).
• změnit rozsah dotazů, aby se zabránilo dotazování smazaných dat, nebo pracovat na užším rozsahu dat. Problémy s výkonem se vyskytují pouze v případě, že náhrobky jsou čteny, a měřítko s počtem náhrobků číst.
• Navrhněte datový model, abyste se vyhnuli mazání velkého množství dat.
• pokud plánujete odstranit všechna data v tabulce, zkrátit nebo zrušit tabulku, abyste odstranili všechna data bez generování náhrobků.
• použijte výchozí hodnotu time-to-live. Tato jediná funguje efektivně, pokud primární klíč vaše data je čas na bázi, vaše údaje jsou psány v chronologickém pořadí, a data budou vymazány při známé datum. K tomu, nastavit výchozí TTL v tabulce-možnosti úrovni, a nastavit čas-založené zhutnění strategie (TimeWindowCompactionStrategy pokud je k dispozici, DateTieredCompactionStrategy jinak). To bude stále vytvářet náhrobky, ale celé sstables budou účinně upuštěny, jakmile TTL na veškerý jejich obsah projde.

jak se mohu zbavit existujících náhrobků?

ve většině případů je nejlepším přístupem počkat, až se náhrobek normálně zhutní. Pokud naléhavé problémy s výkonem nebo používáním disku vyžadují okamžitou akci, existují dva příkazy nodetool, které lze použít k vynucení zhutnění,což může pomoci při pádu náhrobků. Ty by měly být považovány za poslední možnost-ve zdravém klastru s dobře navrženým datovým modelem není nutné spouštět ruční komprese.

Běh nodetool compact nutí zhutnění všech sstables. To vyžaduje velké množství volného místa na disku. Argumenty Keyspace a table by měly být použity k omezení zhutnění na tabulky, kde jsou náhrobky problémem. Na stolech, kde Velikost-Stupňová Zhutnění Strategie se používá, tento příkaz může vést k vytvoření jedné obrovské sstable, že nikdy nebude mít vrstevníci na kompaktní s; pokud je k dispozici příznak –split-output, měl by být použit.

příkaz nodetool garbagecollect je k dispozici od Cassandra 3.10. Tento příkaz spouští řadu menších kompresí, které také kontrolují překrývající se sstables. Je náročnější na CPU a časově náročnější než nodetool compact, ale vyžaduje méně volného místa na disku.

náhrobky budou odstraněny pouze tehdy, pokud uplynuly gc_grace_seconds od vytvoření náhrobků. Účel gc_grace_seconds je poskytnout čas na opravy k obnovení konzistence clusteru, takže buďte opatrní při úpravou – předčasně odstranění náhrobků může mít za následek vzkříšení smazaná data. Také, gc_grace_seconds nastavení ovlivňuje uplynutí rady vytvořené pro naznačil, předání, tak to je nebezpečné pro snížení gc_grace_seconds pod dobu trvání naznačil předávku na okno (ve výchozím nastavení, 3 hodiny).

opravy

opravy mohou zpozdit nebo zabránit pádu náhrobků. Při úplné nebo přírůstkové oprava je běh, sstables to má vliv, jsou označeny jako opravené; v následné compactions, tyto tabulky budou zpevněné odděleně od sstables, které nebyly opraveny. Pokud náhrobky jsou v neopravené sstables a stínu dat je v opravě sstables (nebo naopak), nelze data stažena, protože sstables nemůže být zhutní společně.
Pokud pravidelně spustit úplnou nebo dílčí opravy na clusteru, to by nemělo být příliš velký problém, protože náhrobky a data se nakonec opravit. Pokud však máte kombinaci opravených a neopravených dat a pravidelně neprovádíte opravy, může se to stát problémem. sstablemetadata vám pomůže zkontrolovat opravený stav vašich sstables, abyste zjistili, zda se to děje. Pokud ano, může být vhodné nastavit všechny sstables jako neopravené pomocí sstablerepairedset, aby mohly být zhutněny dohromady.
Vezměte prosím na vědomí, že dílčí opravy neoznačují data jako opravená.