Navrhujem, aby ste si prečítali prepis správy zo začiatku roka 2019 od Andreyho Borodina „Zálohy s WAL-G. Čo je tam v roku 2019?“
Ahojte všetci! Moje meno je Andrey Borodin. Som vývojár v Yandex. O PostgreSQL sa zaujímam od roku 2016, po tom, čo som hovoril s vývojármi a povedali, že všetko je jednoduché - vezmete zdrojový kód a zostavíte ho a všetko bude fungovať. A odvtedy nemôžem prestať – píšem rôzne veci.
Jedna z vecí, na ktorých pracujem, je záložný systém. . Vo všeobecnosti v Yandex pracujeme na zálohovacích systémoch v PostgreSQL už veľmi dlho. A na internete nájdete sériu šiestich správ o tom, ako vyrábame zálohovacie systémy. A každý rok sa trochu vyvíjajú, trochu rozvíjajú a stávajú sa spoľahlivejšími.
Ale dnes správa nie je len o tom, čo sme urobili, ale aj o tom, aké je to jednoduché a čo je. Koľkí z vás si už pozreli moje reportáže o WAL-G? Je dobré, že to nepozeralo dosť ľudí, pretože začnem tou najjednoduchšou vecou.
Ak zrazu máte klaster PostgreSQL a myslím si, že každý ich má so sebou a zrazu ešte neexistuje žiadny zálohovací systém, musíte si zaobstarať akékoľvek úložisko S3 alebo úložisko kompatibilné s Google Cloud.
Môžete napríklad prísť do nášho stánku a vziať si propagačný kód pre Yandex Object Storage, ktorý je kompatibilný s S3.
Potom vytvorte vedierko. Je to len schránka na informácie.
Vytvorte používateľa služby.
Vytvorte prístupový kľúč pre používateľa služby: aws-s3-key.
Stiahnite si najnovšiu stabilnú verziu WAL-G.
Ako sa naše predbežné vydania líšia od vydaní? Často ma žiadajú o skoré prepustenie. A ak nie je vo verzii dostatočná doba, napríklad mesiac, žiadna chyba, potom ju pustím. Tu je toto vydanie z novembra. A to znamená, že každý mesiac sme našli nejaký druh chyby, zvyčajne v nekritických funkciách, ale zatiaľ sme nevydali žiadne vydanie. Predchádzajúca verzia je len novembrová. Nie sú v ňom známe žiadne chyby, t. j. chyby boli pridávané v priebehu projektu.
Po stiahnutí WAL-G môžete spustiť jednoduchý príkaz „zoznam záloh“ a odovzdať premenné prostredia. A pripojí sa k Object Storage a povie vám, aké zálohy máte. Najprv by ste, samozrejme, nemali mať zálohy. Cieľom tejto snímky je ukázať, že všetko je celkom jednoduché. Toto je príkaz konzoly, ktorý prijíma premenné prostredia a vykonáva podpríkazy.
Potom môžete vytvoriť prvú zálohu. Povedzte „backup-push“ vo WAL-G a špecifikujte vo WAL-G umiestnenie pgdata vášho klastra. A s najväčšou pravdepodobnosťou vám PostgreSQL povie, ak ešte nemáte záložný systém, že musíte povoliť "archive-mode".
To znamená, že musíte prejsť do nastavení a zapnúť „archive_mode = on“ a pridať „archive_command“, čo je tiež podpríkaz vo WAL-G. Ale z nejakého dôvodu ľudia často používajú barové skripty na túto tému a omotajú to okolo WAL-G. Prosím, nerobte to. Použite funkcie uvedené vo WAL-G. Ak vám niečo chýba, napíšte . WAL-G predpokladá, že je to jediný program, ktorý beží v archive_command.
WAL-G používame hlavne na vytvorenie klastra s vysokou dostupnosťou v správe databázy Yandex.
A zvyčajne sa používa v topológii jedného Mastera a niekoľkých replikácií. Zároveň vytvorí záložnú kópiu v úložisku objektov Yandex.
Najbežnejšími scenármi je vytváranie kópií klastra pomocou obnovy v bode v čase. No v tomto prípade nie je pre nás výkon záložného systému až taký dôležitý. Potrebujeme len nahrať nový klaster zo zálohy.
Pri pridávaní nového uzla zvyčajne potrebujeme výkon záložného systému. Prečo je to dôležité? Ľudia zvyčajne pridávajú nový uzol do klastra, pretože existujúci klaster nedokáže zvládnuť zaťaženie čítania. Potrebujú pridať novú repliku. Ak pridáme zaťaženie z pg_basebackup do Master, potom sa Master môže zrútiť. Preto bolo pre nás veľmi dôležité, aby sme mohli rýchlo nahrať nový uzol z archívu a vytvoriť tak minimálnu záťaž na Master.
A ďalšia podobná situácia. Toto je potreba reštartovať starý Master po prepnutí Cluster Master z dátového centra, s ktorým sa stratilo spojenie.
- Výsledkom bolo, že pri formulovaní požiadaviek na kopírovací systém sme si uvedomili, že pg_basebackup nie je pre nás vhodný pri prevádzke v cloude.
- Chceli sme mať možnosť komprimovať naše dáta. Kompresiu dát však zabezpečí takmer každý iný zálohovací systém, než ktorý je súčasťou balenia.
- Chceli sme všetko paralelizovať, pretože používateľ v cloude nakupuje veľké množstvo procesorových jadier. Ale ak v nejakej operácii nemáme paralelizmus, potom sa veľké množstvo jadier stáva zbytočným.
- Potrebujeme šifrovanie, pretože údaje často nie sú naše a nemožno ich uložiť ako čistý text. Mimochodom, náš príspevok k WAL-G začal šifrovaním. Dokončili sme šifrovanie vo WAL-G, po ktorom sme dostali otázku: „Možno jeden z nás vyvinie projekt? A odvtedy pracujem s WAL-G viac ako rok.
- Potrebovali sme aj obmedzovanie zdrojov, pretože postupom času sme pomocou cloudu zistili, že ľudia majú niekedy v noci dôležitý náklad s potravinami a do tohto zaťaženia sa nedá zasahovať. Preto sme pridali obmedzovanie zdrojov.
- Rovnako ako výpis a správa.
- A overenie.
Pozreli sme sa na množstvo rôznych nástrojov. Našťastie máme v PostgreSQL obrovský výber. A všade nám niečo chýbalo, niekomu jedna malá funkcia, niekomu jedna drobnosť.
A po preskúmaní existujúcich systémov sme dospeli k záveru, že budeme vyvíjať WAL-G. Vtedy to bol nový projekt. Ovplyvniť vývoj smerom ku cloudovej infraštruktúre zálohovacieho systému bolo celkom jednoduché.
Hlavná ideológia, ktorej sa držíme, je, že WAL-G by mala byť jednoduchá ako balalajka.
WAL-G má 4 príkazy. toto:
WAL-PUSH – archivácia šachty.
WAL-FETCH – získajte hriadeľ.
BACKUP-PUSH – vytvorte zálohu.
BACKUP-FETCH – získajte zálohu zo záložného systému.
V skutočnosti má WAL-G aj správu týchto záloh, teda výpis a mazanie záznamov a záloh v histórii, ktoré už nie sú momentálne potrebné.
Jednou z dôležitých funkcií je pre nás funkcia vytvárania delta kópií.
Delta kópie znamenajú, že nevytvárame plnú zálohu celého klastra, ale iba zmenené stránky zmenených súborov v klastri. Zdalo by sa, že funkčne je to veľmi podobné možnosti obnovy pomocou WAL. Ale môžeme paralelne zrolovať jednovláknovú delta zálohu WAL. Preto, keď máme základnú zálohu urobenú v sobotu, delta zálohy denne a vo štvrtok zlyháme, potom potrebujeme zhrnúť 4 delta zálohy a 10 hodín WAL. Bude to trvať približne rovnaký čas, pretože delta zálohy prebiehajú paralelne.
Delty založené na LSN – to znamená, že pri vytváraní zálohy budeme musieť skombinovať každú stránku a skontrolovať jej LSN s LSN predchádzajúcej zálohy, aby sme pochopili, že sa zmenila. Každá stránka, ktorá by mohla potenciálne obsahovať zmenené údaje, by mala byť prítomná v zálohe delta.
Ako som povedal, pomerne veľká pozornosť sa venovala paralelizmu.
Ale archívne API v PostgreSQL je konzistentné. PostgreSQL archivuje jeden súbor WAL a pri obnove požaduje jeden súbor WAL. Keď však databáza požaduje jeden súbor WAL pomocou príkazu „WAL-FETCH“, zavoláme príkaz „WAL-PREFETCH“, ktorý pripraví ďalších 8 súborov na paralelné načítanie údajov z úložiska objektov.
A keď nás databáza požiada o archiváciu jedného súboru, pozrieme sa na archive_status a uvidíme, či existujú ďalšie súbory WAL. A tiež sa snažíme paralelne sťahovať WAL. To poskytuje významný nárast výkonu a výrazne znižuje vzdialenosť v počte nearchivovaných WAL. Mnoho vývojárov zálohovacích systémov verí, že je to taký riskantný systém, pretože sa spoliehame na naše znalosti vnútorných častí kódu, ktorý nie je PostgreSQL API. PostgreSQL nám nezaručuje prítomnosť zložky archive_status a nezaručuje tam sémantiku, prítomnosť signálov pripravenosti pre súbory WAL. Napriek tomu študujeme zdrojový kód, vidíme, že je to tak a snažíme sa ho zneužiť. A kontrolujeme smer, ktorým sa PostgreSQL vyvíja; ak sa tento mechanizmus náhle pokazí, prestaneme ho používať.
Vo svojej čistej forme si delta WAL na báze LSN vyžaduje čítanie akéhokoľvek súboru klastra, ktorého čas režimu v súborovom systéme sa od predchádzajúcej zálohy zmenil. Žili sme s tým dlho, skoro rok. A nakoniec sme prišli na to, že máme delty WAL.
To znamená, že zakaždým, keď WAL archivujeme na Master, nielenže ho skomprimujeme, zašifrujeme a pošleme do siete, ale zároveň ho aj načítame. Analyzujeme a čítame záznamy v ňom. Rozumieme, ktoré bloky sa zmenili, a zhromažďujeme delta súbory.
Delta súbor popisuje určitý rozsah súborov WAL, popisuje informácie o tom, ktoré bloky boli zmenené v tomto rozsahu WAL. A potom sa tieto delta súbory tiež archivujú.
Tu sa stretávame s tým, že sme všetko paralelizovali pomerne rýchlo, ale nemôžeme paralelne čítať sekvenčnú históriu, pretože v určitom segmente sa môžeme stretnúť s koncom predchádzajúceho záznamu WAL, s ktorým zatiaľ nemáme nič spoločné. pretože paralelné čítanie viedlo k tomu, že najskôr analyzujeme budúcnosť, ktorá ešte nemá minulosť.
V dôsledku toho sme museli do súborov _delta_partial vkladať nezrozumiteľné časti. Výsledkom je, že keď sa vrátime do minulosti, zlepíme časti záznamu WAL do jedného, potom ho analyzujeme a pochopíme, čo sa v ňom zmenilo.
Ak v histórii našej analýzy hriadeľa existuje aspoň jeden bod, v ktorom nerozumieme tomu, čo sa stalo, potom budeme pri ďalšom zálohovaní nútení znova prečítať celý klaster, rovnako ako pri bežnom LSN. -založená delta.
V dôsledku toho všetko naše utrpenie viedlo k tomu, že sme sprístupnili knižnicu na analýzu WAL-G. Pokiaľ viem, zatiaľ to nikto nepoužíva, ale ak to niekto chce, napíšte a používajte, je to vo verejnej doméne. (Aktualizovaný odkaz )
Výsledkom je, že všetky informačné toky vyzerajú dosť komplikovane. Náš majster archivuje šachtu a archivuje delta súbory. A replika, ktorá vytvára záložnú kópiu, musí prijímať delta súbory počas doby, ktorá uplynula medzi zálohami. V tomto prípade bude potrebné pridať časti histórie hromadne a analyzovať, pretože nie celá história sa zmestí do veľkých segmentov. A až potom môže replika archivovať úplnú delta zálohu.
Na grafoch vyzerá všetko oveľa jednoduchšie. Toto je stiahnutie z jedného z našich skutočných klastrov. Máme založené na LSN, vyrobené za jeden deň. A vidíme, že delta záloha založená na LSN bežala od tretej ráno do piatej ráno. Ide o zaťaženie v počte procesorových jadier. WAL-delta nám tu trvala asi 20 minút, teda výrazne sa zrýchlila, no zároveň došlo k intenzívnejšej výmene po sieti.
Keďže máme informácie o tom, ktoré bloky a v akom čase sa v histórii databázy zmenili, zašli sme ďalej a rozhodli sme sa integrovať funkcionalitu – rozšírenie PostgreSQL s názvom „pg_prefaulter“
To znamená, že keď záložná základňa vykoná príkaz na obnovenie, povie WAL-G, aby načítala ďalší súbor WAL. Rozumieme, ku ktorým dátovým blokom bude proces obnovy WAL v blízkej budúcnosti pristupovať, a spustíme operáciu čítania týchto blokov. Toto bolo urobené s cieľom zvýšiť výkon radičov SSD. Pretože rolka WAL sa dostane na stránku, ktorú je potrebné zmeniť. Táto stránka je na disku a nie je vo vyrovnávacej pamäti stránky. A bude synchrónne čakať na príchod tejto stránky. Neďaleko je však WAL-G, ktorý vie, že v najbližších stovkách megabajtov WAL budeme potrebovať určité stránky a zároveň ich začína zahrievať. Inicializuje prístupy k viacerým diskom, takže sa vykonávajú paralelne. Funguje to dobre na jednotkách SSD, ale, bohužiaľ, nie je to absolútne použiteľné pre pevný disk, pretože do toho zasahujeme iba našimi výzvami.
Toto je teraz v kóde.
Existujú funkcie, ktoré by sme chceli pridať.
Tento obrázok ukazuje, že WAL-delta trvá relatívne krátky čas. A to je čítanie zmien, ktoré nastali v databáze počas dňa. WAL-delta by sme mohli robiť nielen v noci, pretože už nie je významným zdrojom záťaže. WAL-delta môžeme čítať každú minútu, pretože je to lacné. Za jednu minútu dokážeme naskenovať všetky zmeny, ktoré nastali v klastri. A toto by sa dalo nazvať „instantná WAL-delta“.
Ide o to, že keď obnovíme klaster, znížime počet príbehov, ktoré musíme postupne zrolovať. To znamená, že množstvo WAL, ktoré PostgreSQL valcuje, by sa malo znížiť, pretože to zaberá značný čas.
To však nie je všetko. Ak vieme, že niektorý blok bude zmenený na úroveň konzistencie zálohy, nemôžeme to zmeniť v minulosti. To znamená, že teraz máme optimalizáciu preposielania WAL-delta súbor po súbore. To znamená, že ak bola napríklad v utorok tabuľka úplne vymazaná alebo niektoré súbory boli úplne vymazané z tabuľky, potom, keď sa delta prevalí v pondelok a obnoví sa sobotňajší pg_basebackup, tieto údaje ani nevytvoríme.
Chceme túto technológiu rozšíriť na úroveň stránky. To znamená, že ak sa niektorá časť súboru zmení v pondelok, ale bude prepísaná v stredu, potom pri obnove do bodu vo štvrtok nemusíme zapisovať prvých pár verzií stránok na disk.
Ale to je stále myšlienka, o ktorej sa v nás aktívne diskutuje, no ešte sa nedostala do kódu.
Chceme urobiť ešte jednu funkciu vo WAL-G. Chceme ho rozšíriť, pretože potrebujeme podporovať rôzne databázy a chceli by sme mať možnosť pristupovať k správe záloh rovnakým spôsobom. Problém je však v tom, že MySQL API sú radikálne odlišné. V MySQL nie je PITR založený na fyzickom protokole WAL, ale na binlogu. A v MySQL nemáme archivačný systém, ktorý by nejakému externému systému oznámil, že tento binlog je hotový a treba ho archivovať. Musíme stáť niekde v crone s databázou a skontrolovať, či je niečo pripravené?
A rovnako tak počas obnovy MySQL neexistuje príkaz na obnovu, ktorý by mohol systému povedať, že potrebujem také a také súbory. Skôr ako začnete s prestavbou klastra, musíte vedieť, aké súbory budete potrebovať. Sami musíte uhádnuť, aké súbory budete potrebovať. Ale tieto problémy sa dajú nejako obísť. (Vysvetlenie: MySQL je už podporovaný)
V správe som chcel hovoriť aj o tých prípadoch, keď pre vás WAL-G nie je vhodný.
Ak nemáte synchrónnu repliku, WAL-G nezaručuje, že sa zachová posledný segment. A ak archivácia zaostáva za niekoľkými poslednými segmentmi histórie, je to riziko. Ak neexistuje synchrónna replika, neodporúčam používať WAL-G. Napriek tomu je určený hlavne pre cloudovú inštaláciu, čo znamená riešenie High Availability so synchrónnou replikou, ktorá je zodpovedná za bezpečnosť posledných odovzdaných bajtov.
Často vidím ľudí, ktorí sa snažia spustiť súčasne WAL-G aj WAL-E. Podporujeme spätnú kompatibilitu v tom zmysle, že WAL-G dokáže obnoviť súbor z WAL-E a môže obnoviť zálohu vytvorenú vo WAL-E. Ale keďže oba tieto systémy používajú paralelný wal-push, začnú si navzájom kradnúť súbory. Ak to opravíme vo WAL-G, stále zostane vo WAL-E. Vo WAL-E sa pozerá na stav archívu, vidí hotové súbory a archivuje ich, zatiaľ čo iné systémy jednoducho nebudú vedieť, že tento súbor WAL existoval, pretože PostgreSQL sa ho už druhýkrát nepokúsi archivovať.
Čo tu opravíme na strane WAL-G? Nebudeme PostgreSQL informovať, že tento súbor bol prenesený paralelne, a keď nás PostgreSQL požiada, aby sme ho archivovali, už budeme vedieť, že takýto súbor s týmto mode-time as týmto md5 už bol archivovaný a jednoducho povieme PostgreSQL - OK, všetko je pripravené bez toho, aby ste v podstate niečo robili.
Je však nepravdepodobné, že by sa tento problém vyriešil na strane WAL-E, takže v súčasnosti nie je možné vytvoriť archívny príkaz, ktorý by archivoval súbor vo WAL-G aj WAL-E.
Okrem toho sú prípady, kedy sa vám WAL-G teraz nehodí, ale určite to napravíme.
Po prvé, v súčasnosti nemáme vstavané overenie zálohy. Nemáme overenie ani počas zálohovania, ani obnovy. Toto je samozrejme implementované v cloude. Ale toto sa realizuje jednoducho predbežnou kontrolou, jednoducho obnovením klastra. Chcel by som túto funkciu poskytnúť používateľom. Ale overením predpokladám, že vo WAL-G bude možné obnoviť klaster a spustiť ho a spustiť dymové testy: pg_dumpall do /dev/null a overenie indexu amcheck.
V súčasnosti vo WAL-G neexistuje spôsob, ako odložiť jednu zálohu z WAL. To znamená, že podporujeme nejaké okno. Napríklad uloženie posledných siedmich dní, uloženie posledných desiatich záloh, uloženie posledných troch úplných záloh. Pomerne často ľudia prídu a hovoria: „Potrebujeme zálohu toho, čo sa stalo na Nový rok, a chceme si to uchovať navždy.“ WAL-G zatiaľ nevie, ako to urobiť. (Poznámka – Toto už bolo opravené. Prečítajte si viac – Možnosť označenia zálohy v )
A pri validácii PITR nemáme kontrolné súčty stránok a kontroly integrity pre všetky segmenty hriadeľa.
Z toho všetkého som dal dokopy projekt pre Google Summer of Code. Ak poznáte šikovných študentov, ktorí by chceli niečo napísať v Go a získať niekoľko tisíc dolárov od jednej spoločnosti s písmenom „G“, odporučte im náš projekt. Budem pôsobiť ako mentor pre tento projekt, oni to dokážu. Ak nebudú študenti, tak to vezmem a urobím to v lete sám.
A máme mnoho ďalších malých problémov, na ktorých postupne pracujeme. A dejú sa dosť zvláštne veci.
Napríklad, ak dáte WAL-G prázdnu zálohu, jednoducho spadne. Napríklad, ak mu poviete, že potrebuje zálohovať prázdny priečinok. Súbor pg_control tam nebude. A bude si myslieť, že niečomu nerozumie. Teoreticky v tomto prípade musíte používateľovi napísať normálnu správu, aby ste mu vysvetlili, ako nástroj používať. Ale to nie je ani vlastnosť programovania, ale vlastnosť dobrého, zrozumiteľného jazyka.
Nevieme, ako zálohovať offline. Ak databáza klame, nemôžeme ju zálohovať. Ale tu je všetko veľmi jednoduché. Keď to začalo, voláme zálohy podľa LSN. LSN základnej bázy sa musí prečítať z kontrolného súboru. A to je taká nerealizovaná vlastnosť. Mnoho zálohovacích systémov dokáže zálohovať základnú databázu. A je to pohodlné.
V súčasnosti nedokážeme správne zvládnuť nedostatok záložného priestoru. Pretože väčšinou doma pracujeme s veľkými zálohami. A nedostali sa k tomu. Ale ak chce niekto programovať v Go práve teraz, pridajte do vedra spracovanie chýb s nedostatkom miesta. Určite sa pozriem na žiadosť o stiahnutie.
A hlavná vec, ktorá nás znepokojuje, je, že chceme čo najviac testov integrácie dockerov, ktoré kontrolujú rôzne scenáre. Momentálne testujeme len základné scenáre. Pri každom potvrdení, ale chceme skontrolovať potvrdenia po potvrdení všetky funkcie, ktoré podporujeme. Najmä napríklad budeme mať dostatočnú podporu pre PostgreSQL 9.4-9.5. Podporujeme ich, pretože komunita podporuje PostgreSQL, ale nekontrolujeme odovzdanie po odovzdaní, aby sme sa uistili, že všetko nie je porušené. A zdá sa mi, že je to dosť vážne riziko.
Máme WAL-G spustený na viac ako tisícke klastrov v správe databázy Yandex. A každý deň zálohuje niekoľko stoviek terabajtov dát.
V našom kóde máme veľa TODO. Ak chcete programovať, príďte, čakáme na požiadavky na ťahanie, čakáme na otázky.
otázky
Dobrý večer! Ďakujem! Domnievam sa, že ak používate WAL-delta, pravdepodobne sa vo veľkej miere spoliehate na zápisy na celú stránku. A ak áno, robili ste testy? Ukázal si krásny graf. O čo krajšie sa stane, ak je FPW vypnutý?
Zápis na celú stránku je pre nás povolený, nepokúšali sme sa ho zakázať. To znamená, že ja ako vývojár som to neskúšal vypnúť. Správcovia systému, ktorí skúmali, pravdepodobne preskúmali tento problém. Ale potrebujeme FPW. Takmer nikto to nevypína, pretože inak sa záloha z repliky nedá urobiť.
Ďakujeme za správu! mam dve otazky. Prvá otázka je, čo sa stane s tabuľkovými priestormi?
Čakáme na žiadosť o stiahnutie. Naše databázy žijú na diskoch SSD a NMVE a túto funkciu v skutočnosti nepotrebujeme. Nie som pripravený tráviť seriózny čas tým, aby som to urobil dobre. Z celého srdca som za to, aby sme to podporili. Sú ľudia, ktorí to podporili, ale podporili to tak, ako im to vyhovuje. Urobili vidličku, ale nedávajú požiadavky na ťahanie. (Pridané vo verzii 0.2.13)
A druhá otázka. Hneď na začiatku ste povedali, že WAL-G predpokladá, že funguje samostatne a nie sú potrebné žiadne obaly. Sama používam zavinovačky. Prečo by sa nemali používať?
Chceme, aby to bolo jednoduché ako balalajka. To znamená, že okrem balalajky nepotrebujete vôbec nič. Chceme, aby bol systém jednoduchý. Ak máte funkcie, ktoré potrebujete urobiť v skripte, príďte a povedzte nám – urobíme to v Go.
Dobrý večer! Ďakujeme za správu! Nepodarilo sa dosiahnuť, aby WAL-G fungovala s dešifrovaním GPG. Normálne šifruje, ale nechce dešifrovať. Je to niečo, čo nám nevyšlo? Situácia je deprimujúca.
Vytvorte problém na GitHub a poďme na to.
Teda nestretli ste sa s tým?
Chybové hlásenie má vlastnosť, že keď WAL-G nerozumie, o aký druh súboru ide, spýta sa: „Možno je zašifrovaný? Možno problém vôbec nie je v šifrovaní. Chcem zlepšiť logovanie na túto tému. Musí to rozlúštiť. Momentálne pracujeme na tejto téme v tom zmysle, že sa nám veľmi nepáči, ako je organizovaný systém získavania verejných a súkromných kľúčov. Pretože externé GPG voláme, aby nám dal svoje kľúče. A potom vezmeme tieto kľúče a prenesieme ich do interného GPG, čo je otvorený PGP, ktorý je pre nás skompilovaný vo WAL-G a tam nazývame šifrovanie. V tomto smere chceme vylepšiť systém a chceme podporovať šifrovanie Libsodium (Pridané vo verzii 0.2.15). Samozrejme, dekódovanie by malo fungovať, poďme na to - potrebujete viac symptómu ako pár slov. Môžete sa niekedy zhromaždiť v miestnosti rečníka a pozrieť sa na systém. (Šifrovanie PGP bez externého GPG - v0.2.9)
Ahoj! Ďakujeme za správu! mam dve otazky. Mám zvláštnu túžbu urobiť pg_basebackup a WAL prihlásiť dvoch poskytovateľov, t.j. chcem urobiť jeden cloud a druhý. Dá sa to nejako urobiť?
Toto teraz neexistuje, ale je to zaujímavý nápad.
Len neverím jednému poskytovateľovi, chcem mať to isté v inom, pre každý prípad.
Myšlienka je to zaujímavá. Technicky to nie je vôbec ťažké realizovať. Ak chcete zabrániť strate nápadu, môžem vás požiadať, aby ste urobili problém na GitHub?
Áno, samozrejme.
A potom, keď študenti prídu na Google Summer of Code, pridáme ich do projektu, aby bolo viac práce vyťažiť z nich viac.
A druhá otázka. Na GitHub sa vyskytol problém. Myslím, že je to už zatvorené. Počas obnovy nastáva panika. A aby ste to porazili, urobili ste samostatnú montáž. V otázkach je to správne. A je tu možnosť urobiť variabilné prostredie v jednom vlákne. A preto to funguje veľmi pomaly. A narazili sme na tento problém, ktorý ešte nebol vyriešený.
Problém je, že z nejakého dôvodu úložisko (CEPH) resetuje spojenie, keď k nemu prídeme s vysokou súbežnosťou. Čo sa s tým dá robiť? Logika opakovania vyzerá takto. Pokúšame sa znova stiahnuť súbor. V jednom prechode sme mali niekoľko nestiahnutých súborov, urobíme druhý pre všetkých, ktorí sa neprihlásili. A pokiaľ je načítaný aspoň jeden súbor na iteráciu, opakujeme a opakujeme a opakujeme. Vylepšili sme logiku opakovaného pokusu – exponenciálny ústup. Nie je však úplne jasné, čo robiť so skutočnosťou, že spojenie sa jednoducho preruší na strane úložného systému. To znamená, že keď nahrávame do jedného streamu, tieto spojenia to nepreruší. Čo tu môžeme zlepšiť? Máme obmedzovanie siete, každé pripojenie môžeme obmedziť počtom bajtov, ktoré odošle. Inak neviem, ako sa vysporiadať s tým, že úložisko objektov nám neumožňuje z neho sťahovať alebo sťahovať paralelne.
Žiadna SLA? Nie je pre nich napísané, ako sa nechávajú trápiť?
Ide o to, že ľudia, ktorí prídu s touto otázkou, majú väčšinou svoj vlastný trezor. To znamená, že nikto nepochádza z Amazonu alebo Google Cloud alebo Yandex Object Storage.
Možno už táto otázka nie je pre vás?
Otázka tu v tomto prípade nie je dôležitá pre koho. Ak existujú nejaké nápady, ako sa s tým vysporiadať, urobme to vo WAL-G. Ale zatiaľ nemám dobré nápady, ako sa s tým vysporiadať. Existuje niekoľko objektových úložísk, ktoré podporujú zobrazovanie záloh odlišne. Požiadate ich, aby vypísali objekty, a oni tam pridajú priečinok. WAL-G sa toho bojí - je tu niečo, čo nie je súbor, nemôžem to obnoviť, čo znamená, že záloha nebola obnovená. To znamená, že v skutočnosti máte úplne obnovený klaster, ale vráti vám chybný stav, pretože Object Storage vrátilo nejaké zvláštne informácie, ktorým úplne nerozumelo.
Toto je vec, ktorá sa deje v cloude pošty.
Ak dokážete vytvoriť reprodukciu...
Dôsledne sa reprodukuje...
Ak dôjde k reprodukcii, potom si myslím, že budeme experimentovať so stratégiami opakovania a prídeme na to, ako to znova vyskúšať a pochopiť, čo od nás cloud vyžaduje. Snáď nám to bude stabilné na troch spojeniach a nepreruší spojenie, potom opatrne dorazíme na tri. Pretože teraz veľmi rýchlo zrušíme pripojenie, t.j. ak sme spustili obnovu so 16 vláknami, tak po prvom opakovaní bude 8 vlákien, 4 vlákna, 2 vlákna a jedno. A potom to stiahne súbor do jedného prúdu. Ak existujú nejaké magické hodnoty, ako je 7,5 vlákien, ktoré sú najlepšie na čerpanie, potom sa pri nich zastavíme a pokúsime sa vytvoriť ďalších 7,5 vlákien. Tu je nápad.
Ďakujeme za správu! Ako vyzerá kompletný pracovný postup pre prácu s WAL-G? Napríklad v hlúpom prípade, keď medzi stránkami neexistuje delta. A vezmeme a odstránime počiatočnú zálohu, potom archivujeme šachtu, kým nezmodrieme v tvári. Tu, ako som pochopil, došlo k rozpisu. V určitom okamihu musíte urobiť delta zálohu stránok, t. j. nejaký externý proces to riadi alebo ako sa to stane?
Delta zálohovacie API je celkom jednoduché. Je tam číslo – max delta krokov, tak sa to volá. Predvolene je nastavená na nulu. To znamená, že zakaždým, keď vykonáte zálohovanie, stiahne sa úplná záloha. Ak ho zmeníte na akékoľvek kladné číslo, napríklad 3, potom pri ďalšom vykonaní zálohovania sa pozrie na históriu predchádzajúcich záloh. Vidí, že neprekročíte reťazec 3 delt a urobí deltu.
To znamená, že zakaždým, keď spustíme WAL-G, pokúsi sa vytvoriť úplnú zálohu?
Nie, používame WAL-G a pokúša sa vytvoriť rozdiel, ak to vaše pravidlá umožňujú.
Zhruba povedané, ak ho spustíte zakaždým s nulou, bude sa správať ako pg_basebackup?
Nie, stále bude bežať rýchlejšie, pretože používa kompresiu a paralelizmus. Pg_basebackup umiestni šachtu vedľa vás. WAL-G predpokladá, že máte nakonfigurovanú archiváciu. A vydá varovanie, ak nie je nakonfigurované.
Pg_basebackup je možné spustiť bez hriadeľov.
Áno, potom sa budú správať takmer rovnako. Pg_basebackup skopíruje do systému súborov. Mimochodom, máme novú funkciu, ktorú som zabudol spomenúť. Teraz môžeme zálohovať do súborového systému z pg_basebackup. Neviem, prečo je to potrebné, ale je to tam.
Napríklad na CephFS. Nie každý chce konfigurovať Object Storage.
Áno, pravdepodobne preto položili otázku o tejto funkcii, aby sme to mohli urobiť. A podarilo sa nám to.
Ďakujeme za správu! Je tu len otázka o kopírovaní do súborového systému. Po vybalení, podporujete teraz kopírovanie na vzdialené úložisko, napríklad ak je v dátovom centre nejaká polica alebo niečo iné?
V tejto formulácii je to ťažká otázka. Áno, podporujeme, ale táto funkcia zatiaľ nie je zahrnutá v žiadnom vydaní. To znamená, že všetky predbežné vydania to podporujú, ale verzie nie. Táto funkcia bola pridaná vo verzii 0.2. Určite bude čoskoro vydaný, hneď ako opravíme všetky známe chyby. Ale práve teraz to možno urobiť len v predbežnom vydaní. V predbežnom vydaní sú dve chyby. Problém s obnovou WAL-E, neopravili sme ho. A v najnovšom predbežnom vydaní bola pridaná chyba o delta zálohovaní. Preto každému odporúčame používať vydané verzie. Hneď ako sa v predbežnom vydaní neobjavia žiadne chyby, môžeme povedať, že podporujeme Google Cloud, veci kompatibilné s S3 a ukladanie súborov.
Dobrý deň, ďakujeme za správu. Ak tomu dobre rozumiem, WAL-G nie je nejaký centralizovaný systém ako barmani? Plánujete sa uberať týmto smerom?
Problém je, že sme sa z tohto smeru vzdialili. WAL-G žije na základnom hostiteľovi, na hostiteľovi klastra a na všetkých hostiteľoch v klastri. Keď sme sa presťahovali do niekoľko tisíc klastrov, mali sme veľa barmanských zariadení. A vždy, keď sa v nich niečo rozpadne, je to veľký problém. Pretože je potrebné ich opraviť, musíte pochopiť, ktoré klastre teraz nemajú zálohy. WAL-G neplánujem vyvíjať v smere fyzického hardvéru pre zálohovacie systémy. Ak tu chce komunita nejakú funkcionalitu, vôbec mi to nevadí.
Máme tímy, ktoré sú zodpovedné za skladovanie. A cítime sa tak dobre, že to nie sme my, ale že existujú špeciálni ľudia, ktorí ukladajú naše súbory tam, kde sú súbory v bezpečí. Robia tam všelijaké šikovné kódovanie, aby vydržali stratu určitého počtu súborov. Sú zodpovední za šírku pásma siete. Keď máte barmana, môžete zrazu zistiť, že na tom istom serveri sa zhromaždili malé databázy s veľkou návštevnosťou. Zdá sa, že na ňom máte veľa miesta, ale z nejakého dôvodu sa všetko cez sieť nezmestí. Môže to dopadnúť aj naopak. Je tam veľa sietí, sú tam jadrá procesorov, ale nie sú tu žiadne disky. A už nás táto potreba s niečím žonglovať unavila a prešli sme k tomu, že ukladanie dát je samostatná služba, za ktorú sú zodpovední samostatní špeciálni ľudia.
PS Bola vydaná nová verzia , v ktorom môžete použiť konfiguračný súbor .walg.json, ktorý sa štandardne nachádza v domovskom adresári postgres. Môžete opustiť bash skripty. Príklad .walg.json je v tomto vydaní
Video:
Zdroj: hab.com