Navrhuji, abyste si přečetli přepis zprávy ze začátku roku 2019 od Andreyho Borodina „Zálohy s WAL-G. Co je v roce 2019?“
Ahoj všichni! Jmenuji se Andrey Borodin. Jsem vývojář ve společnosti Yandex. O PostgreSQL se zajímám od roku 2016, poté, co jsem mluvil s vývojáři a ti řekli, že všechno je jednoduché – vezmeš zdrojový kód a sestavíš ho a všechno bude fungovat. A od té doby nemůžu přestat – píšu různé věci.
Jedna z věcí, na kterých pracuji, je záložní systém. . Obecně v Yandexu pracujeme na zálohovacích systémech v PostgreSQL velmi dlouho. A na internetu můžete najít sérii šesti zpráv o tom, jak vyrábíme záložní systémy. A každý rok se trochu vyvinou, trochu vyvinou a stanou se spolehlivějšími.
Ale dnes zpráva není jen o tom, co jsme udělali, ale také o tom, jak je to jednoduché a co je. Kolik z vás už vidělo mé zprávy o WAL-G? Je dobře, že se dost lidí nedívalo, protože začnu tím nejjednodušším.
Pokud najednou máte cluster PostgreSQL a myslím, že každý jich má u sebe pár, a najednou ještě není žádný zálohovací systém, musíte si pořídit jakékoli úložiště S3 nebo úložiště kompatibilní s Google Cloud.
Můžete například přijít na náš stánek a vzít si propagační kód pro Yandex Object Storage, který je kompatibilní s S3.
Poté vytvořte Bucket. Je to jen schránka na informace.
Vytvořte uživatele služby.
Vytvořte přístupový klíč pro uživatele služby: aws-s3-key.
Stáhněte si nejnovější stabilní verzi WAL-G.
Jak se naše předběžná vydání liší od vydání? Často jsem žádán o předčasné propuštění. A pokud ve verzi není po dostatečnou dobu, například měsíc, žádná chyba, tak ji pustím. Zde je toto vydání z listopadu. A to znamená, že každý měsíc jsme našli nějakou chybu, obvykle v nekritické funkcionalitě, ale zatím jsme nevydali žádnou verzi. Předchozí verze je teprve listopadová. Nejsou v něm známy žádné chyby, tj. chyby byly přidávány v průběhu projektu.
Jakmile si stáhnete WAL-G, můžete spustit jednoduchý příkaz „backup list“ a předat proměnné prostředí. A připojí se k Object Storage a řekne vám, jaké zálohy máte. Zpočátku byste samozřejmě neměli mít zálohy. Smyslem tohoto snímku je ukázat, že vše je docela jednoduché. Toto je příkaz konzoly, který přijímá proměnné prostředí a provádí dílčí příkazy.
Poté můžete provést první zálohu. Řekněte „backup-push“ ve WAL-G a zadejte ve WAL-G umístění pgdata vašeho clusteru. A s největší pravděpodobností vám PostgreSQL řekne, pokud ještě nemáte záložní systém, že musíte povolit "archive-mode".
To znamená, že musíte přejít do nastavení a zapnout „archive_mode = on“ a přidat „archive_command“, což je také dílčí příkaz ve WAL-G. Ale z nějakého důvodu lidé často používají bar skripty na toto téma a obalují to kolem WAL-G. Prosím, nedělejte to. Použijte funkce obsažené ve WAL-G. Pokud vám něco chybí, napište . WAL-G předpokládá, že je to jediný program, který běží v archive_command.
WAL-G používáme hlavně k vytvoření clusteru High Availability ve správě databáze Yandex.
A obvykle se používá v topologii jednoho Master a několika replikací. Zároveň vytvoří záložní kopii v Yandex Object Storage.
Nejběžnějšími scénáři je vytváření kopií clusteru pomocí bodového obnovení. Výkon záložního systému pro nás ale v tomto případě není až tak důležitý. Musíme jen nahrát nový cluster ze zálohy.
Při přidávání nového uzlu obvykle potřebujeme záložní výkon systému. Proč je to důležité? Lidé obvykle přidávají nový uzel do clusteru, protože existující cluster nezvládá zatížení čtení. Potřebují přidat novou repliku. Pokud přidáme zatížení z pg_basebackup do Master, pak se Master může zhroutit. Proto pro nás bylo velmi důležité, že jsme mohli rychle nahrát nový uzel z archivu a vytvořit tak minimální zátěž na Master.
A další podobná situace. Toto je potřeba restartovat starý Master po přepnutí Cluster Master z datového centra, se kterým bylo ztraceno spojení.
- Díky tomu jsme si při formulaci požadavků na kopírovací systém uvědomili, že pg_basebackup se nám při provozu v cloudu nehodí.
- Chtěli jsme mít možnost komprimovat naše data. Ale téměř jakýkoli jiný zálohovací systém než ten, který je součástí balení, zajistí kompresi dat.
- Chtěli jsme vše paralelizovat, protože uživatel v cloudu kupuje velké množství procesorových jader. Pokud ale v nějaké operaci nemáme paralelismus, tak se velké množství jader stává zbytečným.
- Potřebujeme šifrování, protože data často nejsou naše a nelze je uložit jako čistý text. Mimochodem, náš příspěvek k WAL-G začal šifrováním. Dokončili jsme šifrování ve WAL-G, načež jsme byli dotázáni: „Možná někdo z nás vyvine projekt? A od té doby pracuji s WAL-G více než rok.
- Potřebovali jsme také omezování zdrojů, protože postupem času jsme pomocí cloudu zjistili, že lidé mají někdy v noci důležitý náklad s potravinami a do tohoto zatížení nelze zasahovat. Proto jsme přidali omezení zdrojů.
- Stejně jako výpis a správa.
- A ověření.
Podívali jsme se na spoustu různých nástrojů. Naštěstí máme v PostgreSQL obrovský výběr. A všude nám něco chybělo, někdo jedna malá funkce, někdo jedna malá vlastnost.
A po prozkoumání stávajících systémů jsme došli k závěru, že budeme vyvíjet WAL-G. Tehdy to byl nový projekt. Ovlivnit vývoj směrem ke cloudové infrastruktuře zálohovacího systému bylo celkem snadné.
Hlavní ideologií, které se držíme, je, že WAL-G by měla být jednoduchá jako balalajka.
WAL-G má 4 příkazy. Tento:
WAL-PUSH – archivace šachty.
WAL-FETCH – získejte hřídel.
BACKUP-PUSH – vytvoření zálohy.
BACKUP-FETCH – získáte zálohu ze záložního systému.
Ve skutečnosti má WAL-G také správu těchto záloh, tedy výpis a mazání záznamů a záloh v historii, které již nejsou v tuto chvíli potřeba.
Jednou z důležitých funkcí je pro nás funkce vytváření delta kopií.
Delta kopie znamenají, že nevytváříme plnou zálohu celého clusteru, ale pouze změněné stránky změněných souborů v clusteru. Zdá se, že funkčně je to velmi podobné možnosti obnovy pomocí WAL. Ale můžeme srolovat jednovláknovou delta zálohu WAL paralelně. V souladu s tím, když máme základní zálohu vytvořenou v sobotu, delta zálohy denně a ve čtvrtek selžeme, pak musíme shrnout 4 delta zálohy a 10 hodin WAL. Bude to trvat přibližně stejnou dobu, protože delta zálohy běží paralelně.
Rozdíly založené na LSN – to znamená, že při vytváření zálohy budeme muset zkombinovat každou stránku a zkontrolovat její LSN s LSN předchozí zálohy, abychom pochopili, že se změnila. Každá stránka, která by mohla potenciálně obsahovat změněná data, by měla být přítomna v delta záloze.
Jak jsem řekl, poměrně velká pozornost byla věnována paralelismu.
Ale archivní API v PostgreSQL je konzistentní. PostgreSQL archivuje jeden soubor WAL a při obnově požaduje jeden soubor WAL. Ale když databáze požaduje jeden soubor WAL pomocí příkazu "WAL-FETCH", zavoláme příkaz "WAL-PREFETCH", který připraví dalších 8 souborů k paralelnímu načtení dat z úložiště objektů.
A když nás databáze požádá o archivaci jednoho souboru, podíváme se na archive_status a uvidíme, zda existují další soubory WAL. A také se snažíme paralelně stahovat WAL. To poskytuje významný nárůst výkonu a výrazně snižuje vzdálenost v počtu nearchivovaných WAL. Mnoho vývojářů zálohovacích systémů se domnívá, že se jedná o tak riskantní systém, protože se spoléháme na naši znalost vnitřních částí kódu, který není PostgreSQL API. PostgreSQL pro nás nezaručuje přítomnost složky archive_status a nezaručuje tam sémantiku, přítomnost signálů připravenosti pro soubory WAL. Přesto studujeme zdrojový kód, vidíme, že tomu tak je a snažíme se to zneužít. A kontrolujeme směr, kterým se PostgreSQL vyvíjí, pokud se tento mechanismus náhle rozbije, přestaneme jej používat.
Ve své čisté podobě vyžaduje delta WAL na bázi LSN čtení jakéhokoli souboru clusteru, jehož doba režimu v systému souborů se od předchozí zálohy změnila. Žili jsme s tím dlouho, skoro rok. A nakonec jsme došli k závěru, že máme delty WAL.
To znamená, že pokaždé, když archivujeme WAL na Master, nejenže jej zkomprimujeme, zašifrujeme a odešleme do sítě, ale zároveň je také načteme. Analyzujeme a čteme záznamy v něm. Chápeme, které bloky se změnily, a shromažďujeme delta soubory.
Delta soubor popisuje určitý rozsah souborů WAL, popisuje informace o tom, které bloky byly změněny v tomto rozsahu WAL. A pak jsou tyto delta soubory také archivovány.
Zde se potýkáme s tím, že jsme vše paralelizovali celkem rychle, ale nemůžeme paralelně číst sekvenční historii, protože v určitém segmentu můžeme narazit na konec předchozího záznamu WAL, se kterým zatím nemáme co spojit, protože paralelní čtení vedlo k tomu, že nejprve analyzujeme budoucnost, která ještě nemá minulost.
V důsledku toho jsme museli do souborů _delta_partial vkládat nesrozumitelné kousky. Výsledkem je, že když se vrátíme do minulosti, slepíme části záznamu WAL do jednoho, poté jej rozebereme a pochopíme, co se v něm změnilo.
Pokud v historii našeho parsování šachet existuje alespoň jeden bod, kdy nerozumíme tomu, co se dělo, pak budeme při příštím zálohování nuceni číst celý cluster znovu, stejně jako u běžné LSN -založená delta.
V důsledku toho všechno naše utrpení vedlo k tomu, že jsme otevřeli knihovnu pro analýzu WAL-G. Pokud vím, zatím to nikdo nepoužívá, ale pokud by to někdo chtěl, pište a používejte, je to ve veřejné doméně. (Aktualizovaný odkaz )
Ve výsledku tak všechny informační toky vypadají dost komplikovaně. Náš mistr archivuje šachtu a archivuje delta soubory. A replika, která vytváří záložní kopii, musí přijímat rozdílové soubory během doby, která uplynula mezi zálohami. V tomto případě bude třeba přidat části historie hromadně a analyzovat, protože celá historie se nevejde do velkých segmentů. A teprve poté může replika archivovat plnou delta zálohu.
Na grafech vše vypadá mnohem jednodušeji. Toto je stažení z jednoho z našich skutečných clusterů. Máme založené na LSN, vyrobené za jeden den. A vidíme, že delta záloha založená na LSN běžela od tří ráno do pěti ráno. Jedná se o zatížení v počtu procesorových jader. WAL-delta nám zde trvala asi 20 minut, tedy výrazně zrychlila, ale zároveň došlo k intenzivnější výměně po síti.
Protože máme informace o tom, které bloky se změnily a v jakém čase v historii databáze, šli jsme dále a rozhodli jsme se integrovat funkcionalitu – rozšíření PostgreSQL s názvem „pg_prefaulter“
To znamená, že když záložní základna provede příkaz obnovení, řekne WAL-G, aby načetla další soubor WAL. Chápeme, ke kterým datovým blokům bude proces obnovy WAL v blízké budoucnosti přistupovat, a zahájíme operaci čtení těchto bloků. To bylo provedeno za účelem zvýšení výkonu řadičů SSD. Protože role WAL se dostane na stránku, kterou je třeba změnit. Tato stránka je na disku a není v mezipaměti stránek. A bude synchronně čekat, až tato stránka dorazí. Nedaleko je ale WAL-G, která ví, že v příštích stovkách megabajtů WAL budeme potřebovat určité stránky a zároveň je začíná zahřívat. Inicializuje více diskových přístupů, takže jsou prováděny paralelně. To funguje dobře na SSD discích, ale bohužel to absolutně neplatí pro pevný disk, protože do něj zasahujeme pouze našimi výzvami.
Toto je nyní v kódu.
Jsou funkce, které bychom rádi přidali.
Tento obrázek ukazuje, že WAL-delta trvá relativně krátkou dobu. A to je čtení změn, ke kterým došlo v databázi během dne. WAL-delta bychom mohli dělat nejen v noci, protože už to není významný zdroj zátěže. WAL-delta můžeme číst každou minutu, protože je to levné. Během jedné minuty můžeme skenovat všechny změny, které se v clusteru udály. A to by se dalo nazvat "okamžitá WAL-delta".
Jde o to, že když obnovíme cluster, snížíme počet příběhů, které musíme postupně srolovat. To znamená, že množství WAL, které PostgreSQL valí, by se mělo snížit, protože to zabere značný čas.
Ale to není všechno. Pokud víme, že některý blok bude změněn do bodu konzistence zálohy, nemůžeme jej v minulosti změnit. To znamená, že nyní máme optimalizaci předávání WAL-delta soubor po souboru. To znamená, že pokud byla například v úterý tabulka zcela smazána nebo některé soubory byly zcela smazány z tabulky, pak když se delta v pondělí převalí a obnoví se sobotní pg_basebackup, tato data ani nevytvoříme.
Chceme tuto technologii rozšířit na úroveň stránky. To znamená, že pokud se některá část souboru změní v pondělí, ale bude přepsána ve středu, pak při obnově do bodu ve čtvrtek nemusíme zapisovat prvních několik verzí stránek na disk.
Ale to je stále myšlenka, o které se v nás aktivně diskutuje, ale ještě se nedostala do kódu.
Chceme ve WAL-G vytvořit ještě jednu funkci. Chceme, aby byl rozšiřitelný, protože potřebujeme podporovat různé databáze a chtěli bychom mít možnost přistupovat ke správě zálohování stejným způsobem. Problém je ale v tom, že MySQL API jsou radikálně odlišná. V MySQL není PITR založen na fyzickém protokolu WAL, ale na binlogu. A v MySQL nemáme archivační systém, který by nějakému externímu systému řekl, že tento binlog je hotový a je třeba jej archivovat. Musíme stát někde v cronu s databází a zkontrolovat, jestli je něco připraveno?
A stejně tak během obnovy MySQL neexistuje žádný příkaz pro obnovu, který by mohl systému sdělit, že potřebuji takové a takové soubory. Než začnete znovu sestavovat cluster, musíte vědět, jaké soubory budete potřebovat. Sami musíte uhodnout, jaké soubory budete potřebovat. Ale tyto problémy se dají nějak obejít. (Vysvětlení: MySQL je již podporováno)
Ve zprávě jsem chtěl také mluvit o těch případech, kdy pro vás WAL-G není vhodný.
Pokud nemáte synchronní repliku, WAL-G nezaručuje, že bude zachován poslední segment. A pokud archivace zaostává za posledními segmenty historie, je to riziko. Pokud neexistuje synchronní replika, nedoporučoval bych používat WAL-G. Přesto je navržen hlavně pro cloudovou instalaci, což znamená řešení High Availability se synchronní replikou, která je zodpovědná za bezpečnost posledních přidělených bajtů.
Často vidím lidi, kteří se snaží provozovat WAL-G i WAL-E současně. Podporujeme zpětnou kompatibilitu v tom smyslu, že WAL-G může obnovit soubor z WAL-E a může obnovit zálohu vytvořenou ve WAL-E. Ale protože oba tyto systémy používají paralelní wal-push, začnou si navzájem krást soubory. Pokud to opravíme ve WAL-G, zůstane to stále ve WAL-E. Ve WAL-E se podívá na stav archivu, vidí hotové soubory a archivuje je, zatímco jiné systémy prostě nebudou vědět, že tento soubor WAL existoval, protože PostgreSQL se jej podruhé nepokusí archivovat.
Co zde opravíme na straně WAL-G? Nebudeme PostgreSQL informovat, že tento soubor byl přenesen paralelně, a když nás PostgreSQL požádá o jeho archivaci, budeme již vědět, že takový soubor s tímto režimem as tímto md5 již byl archivován a jednoduše řekneme PostgreSQL - OK, vše je připraveno, aniž byste v podstatě cokoliv dělali.
Tento problém však pravděpodobně nebude vyřešen na straně WAL-E, takže v současné době není možné vytvořit archivační příkaz, který by archivoval soubor ve WAL-G i WAL-E.
Navíc jsou případy, kdy se vám WAL-G nyní nehodí, ale určitě to napravíme.
Za prvé, v současné době nemáme vestavěné ověřování záloh. Nemáme ověření ani při zálohování, ani při obnově. To je samozřejmě implementováno v cloudu. Ale to se provádí jednoduše předběžnou kontrolou, jednoduše obnovením clusteru. Chtěl bych tuto funkci poskytnout uživatelům. Ale ověřením předpokládám, že ve WAL-G bude možné obnovit cluster a spustit jej a spustit kouřové testy: pg_dumpall do /dev/null a ověření indexu amcheck.
V současné době ve WAL-G neexistuje způsob, jak odložit jednu zálohu z WAL. To znamená, že podporujeme nějaké okno. Například uložení posledních sedmi dnů, uložení posledních deseti záloh, uložení posledních tří úplných záloh. Docela často lidé přicházejí a říkají: „Potřebujeme zálohu toho, co se stalo na Nový rok, a chceme si to uchovat navždy.“ WAL-G zatím neví, jak to udělat. (Poznámka - Toto již bylo opraveno. Přečtěte si více - Možnost označit zálohu v )
A při ověřování PITR nemáme kontrolní součty stránek a kontroly integrity pro všechny segmenty hřídele.
Z toho všeho jsem dal dohromady projekt pro Google Summer of Code. Pokud znáte chytré studenty, kteří by chtěli něco napsat v Go a získat několik tisíc dolarů od jedné společnosti s písmenem „G“, doporučte jim náš projekt. Budu pro tento projekt působit jako mentor, oni to zvládnou. Pokud nebudou studenti, tak to vezmu a v létě si to udělám sám.
A máme spoustu dalších drobných problémů, na kterých postupně pracujeme. A dějí se docela zvláštní věci.
Pokud například WAL-G dáte prázdnou zálohu, jednoduše spadne. Například když mu řeknete, že potřebuje zálohovat prázdnou složku. Soubor pg_control tam nebude. A bude si myslet, že něčemu nerozumí. Teoreticky v tomto případě musíte napsat normální zprávu uživateli, abyste mu vysvětlili, jak nástroj používat. Ale to ani není vlastnost programování, ale vlastnost dobrého, srozumitelného jazyka.
Nevíme, jak zálohovat offline. Pokud databáze lže, nemůžeme ji zálohovat. Všechno je zde ale velmi jednoduché. Zálohy nazýváme LSN, když to začalo. LSN základní báze musí být načteno z kontrolního souboru. A to je taková nerealizovaná vlastnost. Mnoho zálohovacích systémů může zálohovat podkladovou databázi. A je to pohodlné.
V současné době nedokážeme správně zvládnout nedostatek místa pro zálohování. Protože doma většinou pracujeme s velkými zálohami. A nedostali se k tomu. Ale pokud chce někdo programovat v Go právě teď, přidejte do bucketu zpracování chyb s nedostatkem místa. Určitě se podívám na žádost o stažení.
A hlavní věc, která nás znepokojuje, je, že chceme co nejvíce testů integrace dockerů, které kontrolují různé scénáře. Momentálně testujeme pouze základní scénáře. Při každém odevzdání, ale chceme po každém potvrzení zkontrolovat všechny funkce, které podporujeme. Konkrétně například budeme mít dostatečnou podporu pro PostgreSQL 9.4-9.5. Podporujeme je, protože komunita podporuje PostgreSQL, ale nekontrolujeme odevzdání po odevzdání, abychom se ujistili, že není vše porušeno. A zdá se mi, že to je docela vážné riziko.
Ve správě databáze Yandex běží WAL-G na více než tisíci clusterech. A každý den zálohuje několik stovek terabajtů dat.
V našem kódu máme hodně TODO. Pokud chcete programovat, přijďte, čekáme na pull requesty, čekáme na dotazy.
otázky
Dobrý večer! Děkuji! Můj odhad je, že pokud používáte WAL-delta, pravděpodobně hodně spoléháte na celostránkové zápisy. A pokud ano, dělal jsi testy? Ukázal jsi krásný graf. O kolik krásnější to bude, když je FPW vypnutý?
Zápis na celou stránku je pro nás povolen, nezkoušeli jsme jej zakázat. To znamená, že jsem to jako vývojář nezkoušel vypnout. Správci systému, kteří zkoumali tento problém pravděpodobně zkoumali. Ale potřebujeme FPW. Téměř nikdo to nevypíná, protože jinak nelze zálohu z repliky vzít.
Díky za zprávu! Mám dvě otázky. První otázkou je, co se stane s tabulkovými prostory?
Čekáme na žádost o stažení. Naše databáze žijí na discích SSD a NMVE a tuto funkci opravdu nepotřebujeme. Nejsem připravený trávit teď vážně čas tím, abych to udělal dobře. Z celého srdce se přimlouvám za to, abychom to podpořili. Jsou lidé, kteří to podpořili, ale podpořili to způsobem, který jim vyhovuje. Udělali vidličku, ale nevyžadují tah. (Přidáno ve verzi 0.2.13)
A druhá otázka. Hned na začátku jste řekl, že WAL-G předpokládá, že funguje samostatně a nejsou potřeba žádné obaly. Sama používám zavinovačky. Proč by se neměly používat?
Chceme, aby to bylo jednoduché jako balalajka. To znamená, že kromě balalajky nepotřebujete vůbec nic. Chceme, aby byl systém jednoduchý. Pokud máte funkce, které potřebujete udělat ve skriptu, přijďte a řekněte nám – uděláme to v Go.
Dobrý večer! Díky za zprávu! Nepodařilo se nám přimět WAL-G, aby fungovala s dešifrováním GPG. Normálně šifruje, ale nechce dešifrovat. Je to něco, co se nám nepovedlo? Situace je depresivní.
Vytvořte problém na GitHubu a pojďme na to přijít.
To znamená, že jste se s tím nesetkali?
Chybová zpráva má vlastnost, že když WAL-G nerozumí, o jaký druh souboru se jedná, zeptá se: „Možná je to zašifrováno? Možná problém vůbec není v šifrování. Chci zlepšit logování na toto téma. Musí to dešifrovat. Momentálně na tomto tématu pracujeme v tom smyslu, že se nám moc nelíbí, jak je organizován systém získávání veřejných a soukromých klíčů. Protože externímu GPG říkáme, aby nám dal své klíče. A pak vezmeme tyto klíče a přeneseme je do interního GPG, což je otevřené PGP, které je pro nás zkompilováno uvnitř WAL-G, a tam nazýváme šifrování. V tomto ohledu chceme vylepšit systém a chceme podporovat šifrování Libsodium (Přidáno ve verzi 0.2.15). Dekódování by samozřejmě mělo fungovat, pojďme na to – potřebujete více symptomu než pár slov. Můžete se někdy shromáždit v řečnické místnosti a podívat se na systém. (Šifrování PGP bez externího GPG - v0.2.9)
Ahoj! Díky za zprávu! Mám dvě otázky. Mám zvláštní touhu udělat pg_basebackup a WAL přihlásit dva poskytovatele, tj. chci udělat jeden cloud a druhý. Existuje nějaký způsob, jak to udělat?
To teď neexistuje, ale je to zajímavý nápad.
Jen nevěřím jednomu poskytovateli, chci mít to samé v jiném, pro každý případ.
Myšlenka je to zajímavá. Technicky to není vůbec těžké realizovat. Aby se nápad neztratil, mohu vás požádat, abyste udělali problém na GitHubu?
Ano, samozřejmě.
A pak, když studenti přijdou na Google Summer of Code, přidáme je do projektu, aby bylo více práce, abychom z nich dostali více.
A druhá otázka. Na GitHubu je problém. Myslím, že už je zavřeno. Během obnovy nastává panika. A abyste to porazili, vytvořili jste samostatnou sestavu. V otázkách je to správně. A existuje možnost udělat variabilní prostředí v jednom vlákně. A proto to funguje velmi pomalu. A narazili jsme na tento problém a dosud nebyl vyřešen.
Problém je v tom, že úložiště (CEPH) z nějakého důvodu resetuje připojení, když k němu přijdeme s vysokou souběžností. Co se s tím dá dělat? Logika opakování vypadá takto. Snažíme se soubor stáhnout znovu. V jednom průchodu jsme měli řadu nestažených souborů, uděláme druhý pro všechny, kteří se nepřihlásili. A dokud je načten alespoň jeden soubor na iteraci, opakujeme a opakujeme a opakujeme. Vylepšili jsme logiku opakování – exponenciální couvání. Není však zcela jasné, co dělat s tím, že se spojení jednoduše přeruší na straně úložného systému. To znamená, že když nahrajeme do jednoho streamu, tato spojení to nepřeruší. Co zde můžeme zlepšit? Máme omezení sítě, každé připojení můžeme omezit počtem bajtů, které odešle. Jinak nevím, jak se vypořádat s tím, že úložiště objektů nám z něj neumožňuje paralelně stahovat nebo stahovat.
Žádné SLA? Není pro ně napsáno, jak se nechají mučit?
Jde o to, že lidé, kteří s touto otázkou přicházejí, mají většinou svůj trezor. To znamená, že nikdo nepochází z Amazonu nebo Google Cloud nebo Yandex Object Storage.
Možná už tato otázka není pro vás?
Otázka zde v tomto případě není důležitá pro koho. Pokud existují nějaké nápady, jak se s tím vypořádat, udělejme to ve WAL-G. Ale zatím nemám dobrý nápad, jak se s tím vypořádat. Existují některá úložiště objektů, která podporují vypisování záloh odlišně. Požádáte je, aby vypsali objekty, a oni tam přidají složku. WAL-G se toho děsí - je tu nějaká věc, která není soubor, nemohu ji obnovit, což znamená, že záloha nebyla obnovena. To znamená, že ve skutečnosti máte kompletně obnovený cluster, ale vrátí vám chybný stav, protože Object Storage vrátilo nějaké podivné informace, kterým plně nerozumělo.
To je věc, která se děje v cloudu pošty.
Pokud dokážete vytvořit reprodukci...
Je důsledně reprodukován...
Pokud dojde k reprodukci, pak si myslím, že budeme experimentovat se strategiemi opakování a zjistíme, jak to zopakovat a pochopit, co od nás cloud vyžaduje. Snad nám to bude stabilní na třech spojích a nepřeruší spoj, pak opatrně dojedeme na tři. Protože nyní velmi rychle ukončíme připojení, tj. pokud jsme spustili obnovu s 16 vlákny, tak po prvním opakování bude 8 vláken, 4 vlákna, 2 vlákna a jedno. A pak to stáhne soubor do jednoho proudu. Pokud existují nějaké magické hodnoty, jako je 7,5 vlákna jsou nejlepší pro čerpání, pak se u nich pozastavíme a zkusíme vytvořit dalších 7,5 vláken. Tady je nápad.
Díky za zprávu! Jak vypadá kompletní pracovní postup pro práci s WAL-G? Například v hloupém případě, kdy mezi stránkami není žádná delta. A vezmeme a odstraníme počáteční zálohu, pak archivujeme šachtu, dokud nezmodráme. Tady, jak jsem to pochopil, došlo ke zhroucení. V určitém okamžiku potřebujete udělat delta zálohu stránek, tj. nějaký externí proces to řídí nebo jak se to stane?
Delta backup API je docela jednoduché. Je tam číslo – maximální delta kroků, tak se tomu říká. Výchozí je nula. To znamená, že pokaždé, když provedete zálohování, stáhne se plná záloha. Pokud jej změníte na jakékoli kladné číslo, například 3, pak při příštím spuštění zálohy se podívá na historii předchozích záloh. Vidí, že nepřekročíte řetězec 3 delt a udělá deltu.
To znamená, že pokaždé, když spustíme WAL-G, pokusí se vytvořit úplnou zálohu?
Ne, používáme WAL-G a pokusí se vytvořit rozdíl, pokud to vaše zásady umožňují.
Zhruba řečeno, pokud jej spustíte pokaždé s nulou, bude se chovat jako pg_basebackup?
Ne, stále poběží rychleji, protože používá kompresi a paralelismus. Pg_basebackup umístí šachtu vedle vás. WAL-G předpokládá, že máte nakonfigurovanou archivaci. A pokud není nakonfigurován, vydá varování.
Pg_basebackup lze spustit bez hřídelí.
Ano, pak se budou chovat téměř stejně. Pg_basebackup zkopíruje do systému souborů. Mimochodem, máme tu novou funkci, kterou jsem zapomněl zmínit. Nyní můžeme zálohovat do systému souborů z pg_basebackup. Nevím, proč je to potřeba, ale je to tam.
Například na CephFS. Ne každý chce konfigurovat úložiště objektů.
Ano, to je pravděpodobně důvod, proč se zeptali na tuto funkci, abychom to mohli udělat. A dokázali jsme to.
Díky za zprávu! Je tu jen otázka ohledně kopírování do souborového systému. Po vybalení, podporujete nyní kopírování do vzdáleného úložiště, například pokud je v datovém centru nějaká police nebo něco jiného?
V této formulaci je to těžká otázka. Ano, podporujeme, ale tato funkce zatím není zahrnuta v žádné verzi. To znamená, že všechny předběžné verze to podporují, ale verze ne. Tato funkce byla přidána ve verzi 0.2. Určitě bude brzy vydán, jakmile opravíme všechny známé chyby. Ale právě teď to lze provést pouze v předběžné verzi. V předběžné verzi jsou dvě chyby. Problém s obnovou WAL-E, neopravili jsme ho. A v nejnovější předběžné verzi byla přidána chyba týkající se zálohování delta. Proto všem doporučujeme používat vydané verze. Jakmile se v předběžném vydání neobjeví žádné další chyby, můžeme říci, že podporujeme Google Cloud, věci kompatibilní s S3 a úložiště souborů.
Dobrý den, děkujeme za zprávu. Pokud tomu rozumím, WAL-G není nějaký druh centralizovaného systému jako barmani? Plánujete se ubírat tímto směrem?
Problém je, že jsme se od tohoto směru vzdálili. WAL-G žije na základním hostiteli, na hostiteli klastru a na všech hostitelích v klastru. Když jsme se přestěhovali do několika tisíc klastrů, měli jsme mnoho barmanských instalací. A pokaždé, když se v nich něco rozpadne, je to velký problém. Protože je třeba je opravit, musíte pochopit, které clustery nyní nemají zálohy. Neplánuji vyvíjet WAL-G ve směru fyzického hardwaru pro zálohovací systémy. Pokud tady chce komunita nějakou funkcionalitu, vůbec mi to nevadí.
Máme týmy, které jsou zodpovědné za skladování. A cítíme se tak dobře, že to nejsme my, že existují speciální lidé, kteří ukládají naše soubory tam, kde jsou soubory v bezpečí. Dělají tam všemožné chytré kódování, aby vydrželo ztrátu určitého počtu souborů. Jsou zodpovědní za šířku pásma sítě. Když máte barmana, můžete najednou zjistit, že se na stejném serveru shromáždily malé databáze s velkým provozem. Zdá se, že na něm máte spoustu místa, ale z nějakého důvodu se vše nevejde přes síť. Může to dopadnout i naopak. Je tam spousta sítí, jsou tam procesorová jádra, ale nejsou tady disky. A tato potřeba s něčím žonglovat nás omrzela a přešli jsme k tomu, že ukládání dat je samostatná služba, za kterou jsou zodpovědní zvláštní lidé.
PS Byla vydána nová verze , ve kterém můžete použít konfigurační soubor .walg.json, který se standardně nachází v domovském adresáři postgres. Můžete opustit bash skripty. Příklad .walg.json je v tomto vydání
Video:
Zdroj: www.habr.com