Predlažem da pročitate transkript izvještaja Andreja Borodina s početka 2019. „Rezervne kopije sa WAL-G. Šta ima u 2019. godini?“
Zdravo svima! Moje ime je Andrej Borodin. Ja sam programer u Yandexu. PostgreSQL me zanima od 2016. godine, nakon što sam razgovarao sa programerima i rekli su da je sve jednostavno - uzmeš izvorni kod i napraviš ga i sve će uspjeti. I od tada ne mogu da prestanem – pišem razne stvari.
Jedna od stvari na kojoj radim je rezervni sistem. . Općenito, u Yandexu već dugo radimo na backup sistemima u PostgreSQL-u. A na internetu možete pronaći seriju od šest izvještaja o tome kako pravimo rezervne sisteme. I svake godine malo evoluiraju, malo se razvijaju i postaju pouzdaniji.
Ali danas izveštaj nije samo o tome šta smo uradili, već i o tome koliko je to jednostavno i šta jeste. Koliko vas je već pogledalo moje izvještaje o WAL-G-u? Dobro je što dosta ljudi nije pogledalo, jer ću početi od najjednostavnije stvari.
Ako odjednom imate PostgreSQL klaster, a mislim da ih svi imaju po nekoliko sa sobom, a odjednom još nema sistema za sigurnosnu kopiju, onda morate nabaviti bilo koju S3 pohranu ili skladište kompatibilno s Google Cloudom.
Na primjer, možete doći na naš štand i uzeti promotivni kod za Yandex Object Storage, koji je kompatibilan sa S3.
Zatim kreirajte Bucket. To je samo kontejner za informacije.
Kreirajte korisnika usluge.
Kreirajte pristupni ključ za korisnika usluge: aws-s3-key.
Preuzmite najnovije stabilno izdanje WAL-G.
Po čemu se naša predizdanja razlikuju od izdanja? Često me traže da se prijevremeno pustim na slobodu. A ako nema greške u verziji dovoljno vremena, na primjer, mjesec dana, onda je puštam. Evo ovog izdanja iz novembra. A to znači da smo svakog mjeseca pronašli neku vrstu greške, obično u nekritičnoj funkcionalnosti, ali još nismo objavili izdanje. Prethodna verzija je tek novembar. U njemu nema nama poznatih grešaka, odnosno dodavane su greške kako je projekat napredovao.
Jednom kada preuzmete WAL-G, možete pokrenuti jednostavnu naredbu “backup list” i proslijediti varijable okruženja. I on će se povezati na Object Storage i reći vam koje sigurnosne kopije imate. U početku, naravno, ne biste trebali imati rezervne kopije. Svrha ovog slajda je da pokaže da je sve prilično jednostavno. Ovo je naredba konzole koja prihvaća varijable okruženja i izvršava podnaredbe.
Nakon toga možete napraviti svoju prvu sigurnosnu kopiju. Recite “backup-push” u WAL-G i navedite u WAL-G lokaciju pgdata vašeg klastera. I najvjerovatnije, PostgreSQL će vam reći, ako već nemate backup sistem, da morate omogućiti "archive-mode".
To znači da trebate otići na postavke i uključiti “archive_mode = on” i dodati “archive_command”, koja je također podkomanda u WAL-G-u. Ali iz nekog razloga ljudi često koriste bar skripte na ovu temu i omotavaju je oko WAL-G. Molim te nemoj to raditi. Koristite funkcionalnost koja se nalazi u WAL-G. Ako vam nešto nedostaje, pišite . WAL-G pretpostavlja da je to jedini program koji se izvodi u archive_command.
Koristimo WAL-G uglavnom za kreiranje klastera visoke dostupnosti u upravljanju Yandex bazom podataka.
I obično se koristi u topologiji jednog Mastera i nekoliko replikacija. Istovremeno, pravi rezervnu kopiju u Yandex Object Storage.
Najčešći scenariji su kreiranje kopija klastera koristeći Point in time recovery. Ali u ovom slučaju, performanse rezervnog sistema za nas nisu toliko važne. Samo treba da učitamo novi klaster iz rezervne kopije.
Obično su nam potrebne performanse sistema rezervnih kopija kada dodajemo novi čvor. Zašto je to važno? Ljudi obično dodaju novi čvor u klaster jer postojeći klaster ne može podnijeti opterećenje čitanja. Trebaju dodati novu repliku. Ako dodamo opterećenje iz pg_basebackup na Master, onda se Master može srušiti. Stoga nam je bilo jako važno da možemo brzo učitati novi čvor iz arhive, stvarajući minimalno opterećenje na Masteru.
I još jedna slična situacija. Ovo je potreba da se ponovo pokrene stari Master nakon prebacivanja Cluster Master-a iz Data Centra s kojim je izgubljena veza.
- Kao rezultat toga, kada smo formulirali zahtjeve za sistem kopiranja, shvatili smo da pg_basebackup nije prikladan za nas kada radimo u oblaku.
- Htjeli smo biti u mogućnosti komprimirati naše podatke. Ali skoro svaki sistem rezervne kopije osim onog koji dolazi u kutiji obezbediće kompresiju podataka.
- Htjeli smo sve paralelizirati jer korisnik u oblaku kupuje veliki broj procesorskih jezgara. Ali ako nemamo paralelizam u nekoj operaciji, tada veliki broj jezgri postaje beskorisan.
- Potrebna nam je enkripcija jer često podaci nisu naši i ne mogu se pohraniti u čistom tekstu. Inače, naš doprinos WAL-G-u počeo je šifriranjem. Završili smo šifriranje u WAL-G, nakon čega smo upitani: „Možda će neko od nas razviti projekat?“ I od tada radim sa WAL-G više od godinu dana.
- Trebalo nam je i smanjenje resursa, jer smo tokom vremena koristeći oblak otkrili da ljudi ponekad imaju veliku količinu namirnica noću i to opterećenje se ne može ometati. Zato smo dodali smanjenje resursa.
- Kao i listing i upravljanje.
- I verifikacija.
Pogledali smo mnogo različitih alata. Srećom, imamo ogroman izbor u PostgreSQL-u. I svuda nam je nešto nedostajalo, neka mala funkcija, neko jedna mala karakteristika.
I nakon što smo ispitali postojeće sisteme, došli smo do zaključka da ćemo razviti WAL-G. Tada je to bio novi projekat. Bilo je prilično lako uticati na razvoj ka cloud infrastrukturi backup sistema.
Glavna ideologija koje se pridržavamo je da WAL-G bude jednostavan kao balalajka.
WAL-G ima 4 komande. Ovo:
WAL-PUSH – arhivirajte osovinu.
WAL-FETCH – dobiti osovinu.
BACKUP-PUSH – napravite rezervnu kopiju.
BACKUP-FETCH – dobijate rezervnu kopiju sa rezervnog sistema.
U stvari, WAL-G također ima upravljanje tim sigurnosnim kopijama, tj. listanje i brisanje zapisa i sigurnosnih kopija u povijesti koji više nisu potrebni u ovom trenutku.
Jedna od važnih funkcija za nas je funkcija kreiranja delta kopija.
Delta kopije znače da ne kreiramo potpunu sigurnosnu kopiju cijelog klastera, već samo promijenjene stranice promijenjenih datoteka u klasteru. Čini se da je to funkcionalno vrlo slično mogućnosti oporavka pomoću WAL-a. Ali možemo paralelno sakupiti WAL jednonitnu delta sigurnosnu kopiju. Shodno tome, kada imamo osnovnu rezervnu kopiju napravljenu u subotu, delta sigurnosne kopije dnevno, a u četvrtak ne uspemo, onda treba da napravimo 4 delta rezervne kopije i 10 sati WAL-a. Trebat će otprilike isto vrijeme jer se delta sigurnosne kopije kotrljaju paralelno.
Delte zasnovane na LSN-u - to znači da ćemo prilikom kreiranja sigurnosne kopije morati kombinirati svaku stranicu i provjeriti njen LSN sa LSN-om prethodne sigurnosne kopije kako bismo shvatili da se promijenila. Svaka stranica koja bi potencijalno mogla sadržavati izmijenjene podatke trebala bi biti prisutna u delta sigurnosnoj kopiji.
Kao što sam rekao, dosta pažnje je posvećeno paralelizmu.
Ali arhivski API u PostgreSQL-u je konzistentan. PostgreSQL arhivira jednu WAL datoteku i prilikom vraćanja zahtijeva jednu WAL datoteku. Ali kada baza podataka zatraži jednu WAL datoteku koristeći naredbu "WAL-FETCH", mi pozivamo naredbu "WAL-PREFETCH", koja priprema sljedećih 8 datoteka za paralelno preuzimanje podataka iz skladišta objekata.
A kada baza podataka traži od nas da arhiviramo jednu datoteku, gledamo archive_status i vidimo da li postoje drugi WAL fajlovi. Takođe pokušavamo paralelno preuzeti WAL. Ovo obezbeđuje značajno povećanje performansi i značajno smanjuje razdaljinu u broju nearhiviranih WAL-ova. Mnogi programeri sigurnosnog sistema vjeruju da je ovo tako rizičan sistem jer se oslanjamo na naše znanje o unutrašnjosti koda koji nije PostgreSQL API. PostgreSQL ne garantuje prisustvo fascikle archive_status za nas i ne garantuje semantiku, prisustvo signala spremnosti za WAL fajlove tamo. Ipak, proučavamo izvorni kod, vidimo da je to tako i pokušavamo ga iskoristiti. I mi kontroliramo smjer u kojem se PostgreSQL razvija; ako se ovaj mehanizam iznenada pokvari, prestat ćemo ga koristiti.
U svom čistom obliku, LSN-bazirana WAL delta zahtijeva čitanje bilo koje datoteke klastera čije se vrijeme moda u sistemu datoteka promijenilo od prethodne sigurnosne kopije. Živeli smo sa ovim dugo, skoro godinu dana. I na kraju smo došli do zaključka da imamo WAL delte.
To znači da svaki put kada arhiviramo WAL na Master-u, ne samo da ga komprimujemo, šifriramo i šaljemo na mrežu, već ga istovremeno čitamo. Analiziramo i čitamo zapise u njemu. Razumijemo koji su blokovi promijenjeni i prikupljamo delta fajlove.
Delta datoteka opisuje određeni raspon WAL datoteka, opisuje informacije o tome koji su blokovi promijenjeni u ovom rasponu WAL-a. I onda se ovi delta fajlovi takođe arhiviraju.
Ovdje smo suočeni s činjenicom da smo sve vrlo brzo paralelizirali, ali ne možemo paralelno čitati sekvencijalnu historiju, jer u određenom segmentu možemo naići na kraj prethodnog WAL zapisa, s kojim još nemamo ništa da povežemo, jer paralelno čitanje dovelo je do toga da prvo analiziramo budućnost, koja još nema prošlost.
Kao rezultat toga, morali smo da stavimo nerazumljive delove u _delta_partial fajlove. Kao rezultat toga, kada se vratimo u prošlost, spojit ćemo dijelove WAL zapisa u jedan, nakon toga ćemo ga raščlaniti i shvatiti šta se u njemu promijenilo.
Ako u istoriji našeg raščlanjivanja okna postoji bar jedna tačka u kojoj ne razumemo šta se dešava, onda ćemo, shodno tome, tokom sledeće sigurnosne kopije biti primorani da ponovo pročitamo ceo klaster, baš kao što smo uradili sa regularnim LSN-om -bazirana delta.
Kao rezultat, sva naša patnja dovela je do činjenice da smo otvorili biblioteku za raščlanjivanje WAL-G. Koliko ja znam, to još niko ne koristi, ali ako neko želi, napiše i koristi, to je u javnom vlasništvu. (Ažurirana veza )
Kao rezultat, svi tokovi informacija izgledaju prilično komplicirano. Naš Master arhivira osovinu i arhivira delta fajlove. A replika koja pravi rezervnu kopiju mora primiti delta fajlove tokom vremena koje je prošlo između pravljenja rezervnih kopija. U ovom slučaju, delovi istorije će morati da se dodaju na veliko i analiziraju, jer se čitava istorija ne uklapa u velike segmente. I tek nakon toga replika može arhivirati punu delta sigurnosnu kopiju.
Na grafikonima sve izgleda mnogo jednostavnije. Ovo je preuzimanje sa jednog od naših pravih klastera. Imamo LSN bazirane, napravljene u jednom danu. I vidimo da je delta backup baziran na LSN-u radio od tri ujutro do pet ujutro. Ovo je opterećenje u broju procesorskih jezgara. WAL-delta nam je ovdje trebao oko 20 minuta, odnosno postao je znatno brži, ali je u isto vrijeme došlo do intenzivnije razmjene preko mreže.
Pošto imamo informacije o tome koji su blokovi promenjeni i u koje vreme u istoriji baze podataka, otišli smo dalje i odlučili da integrišemo funkcionalnost - PostgreSQL ekstenziju pod nazivom “pg_prefaulter”
To znači da kada stand-by baza izvrši naredbu za vraćanje, ona govori WAL-G-u da dohvati sljedeću WAL datoteku. Razumijemo otprilike kojim blokovima podataka će pristupiti proces WAL oporavka u bliskoj budućnosti i pokrećemo operaciju čitanja na tim blokovima. Ovo je učinjeno kako bi se povećale performanse SSD kontrolera. Zato što će WAL rolna doći do stranice koju treba promijeniti. Ova stranica je na disku i nije u kešu stranice. I on će sinhrono čekati da ova stranica stigne. Ali u blizini je WAL-G, koji zna da će nam u sljedećih nekoliko stotina megabajta WAL-a trebati određene stranice i istovremeno ih počinje zagrijavati. Inicira višestruke pristupe disku tako da se izvršavaju paralelno. Ovo dobro radi na SSD diskovima, ali, nažalost, apsolutno nije primjenjivo za tvrdi disk, jer ga samo ometamo svojim upitima.
To je ono što je sada u kodu.
Postoje funkcije koje bismo željeli dodati.
Ova slika pokazuje da WAL-delta traje relativno kratko. A ovo je očitavanje promjena koje su se desile u bazi podataka tokom dana. WAL-delta bismo mogli raditi ne samo noću, jer više nije značajan izvor opterećenja. Možemo čitati WAL-delta svake minute jer je jeftino. U jednoj minuti možemo skenirati sve promjene koje su se dogodile na klasteru. A ovo bi se moglo nazvati "instant WAL-delta".
Poenta je da kada vratimo klaster, smanjujemo broj priča koje moramo uzastopno savijati. Odnosno, treba smanjiti količinu WAL-a koji PostgreSQL baca, jer je potrebno značajno vrijeme.
Ali to nije sve. Ako znamo da će neki blok biti promijenjen do točke konzistentnosti sigurnosne kopije, ne možemo ga promijeniti u prošlosti. Odnosno, sada imamo optimizaciju datoteka po fajl WAL-delta prosljeđivanja. To znači da ako je, na primjer, u utorak tablica potpuno obrisana ili su neke datoteke u potpunosti izbrisane iz tablice, onda kada se delta vrati u ponedjeljak i subotnji pg_basebackup se vrati, nećemo ni kreirati ove podatke.
Želimo proširiti ovu tehnologiju na nivo stranice. Odnosno, ako se neki dio datoteke promijeni u ponedjeljak, ali će biti prepisan u srijedu, onda kada se vraćamo na tačku u četvrtak, ne moramo pisati prvih nekoliko verzija stranica na disk.
Ali to je još uvijek ideja o kojoj se u nama aktivno raspravlja, ali još nije došla do kodeksa.
Želimo da napravimo još jednu funkciju u WAL-G. Želimo da ga učinimo proširivim jer moramo podržati različite baze podataka i želimo da možemo pristupiti upravljanju rezervnim kopijama na isti način. Ali problem je u tome što su MySQL API-ji radikalno različiti. U MySQL-u, PITR se ne zasniva na fizičkom WAL dnevniku, već na binlogu. A mi nemamo sistem arhiviranja u MySQL-u koji bi nekom vanjskom sistemu rekao da je ovaj binlog gotov i da ga treba arhivirati. Moramo stajati negdje u cron-u sa bazom podataka i provjeriti ima li nešto spremno?
I na isti način, tokom MySQL restauracije, ne postoji naredba za vraćanje koja bi mogla reći sistemu da mi trebaju takve i takve datoteke. Prije nego počnete obnavljati svoj klaster, morate znati koje datoteke će vam trebati. Vi sami trebate pogoditi koji će vam fajlovi biti potrebni. Ali ovi problemi se možda mogu nekako zaobići. (Pojašnjenje: MySQL je već podržan)
U izvještaju sam također želio govoriti o onim slučajevima kada WAL-G nije prikladan za vas.
Ako nemate sinkronu repliku, WAL-G ne garantuje da će posljednji segment biti sačuvan. A ako arhiviranje zaostaje za poslednjih nekoliko segmenata istorije, to je rizik. Ako ne postoji sinhrona replika, ne bih preporučio korištenje WAL-G. Ipak, uglavnom je dizajniran za instalaciju u oblaku, što podrazumijeva rješenje visoke dostupnosti sa sinhronom replikom, koja je odgovorna za sigurnost posljednjih predatih bajtova.
Često vidim ljude koji pokušavaju istovremeno pokrenuti i WAL-G i WAL-E. Podržavamo kompatibilnost unatrag u smislu da WAL-G može vratiti datoteku iz WAL-E i može vratiti sigurnosnu kopiju napravljenu u WAL-E. Ali pošto oba ova sistema koriste paralelni wal-push, počinju da kradu fajlove jedan od drugog. Ako ga popravimo u WAL-G, i dalje će ostati u WAL-E. U WAL-E-u, on gleda status arhive, vidi gotove datoteke i arhivira ih, dok drugi sistemi jednostavno neće znati da je ovaj WAL fajl postojao, jer PostgreSQL neće pokušati da ga arhivira drugi put.
Šta ćemo popraviti ovdje na WAL-G strani? Nećemo obavijestiti PostgreSQL da je ovaj fajl paralelno prenesen, a kada PostgreSQL zatraži da ga arhiviramo, već ćemo znati da je takav fajl sa ovim mod-time i sa ovim md5 već arhiviran i jednostavno ćemo reći PostgreSQL - OK, sve je spremno, a da se ništa ne radi.
Ali malo je vjerovatno da će ovaj problem biti riješen na strani WAL-E, tako da je trenutno nemoguće kreirati naredbu za arhiviranje koja će arhivirati datoteku u WAL-G i WAL-E.
Osim toga, postoje slučajevi u kojima WAL-G sada nije prikladan za vas, ali ćemo to definitivno popraviti.
Prvo, trenutno nemamo ugrađenu verifikaciju sigurnosne kopije. Nemamo verifikaciju ni tokom pravljenja rezervnih kopija ni prilikom oporavka. Naravno, ovo se implementira u oblaku. Ali ovo se implementira jednostavno prethodnom provjerom, jednostavnim vraćanjem klastera. Želio bih dati ovu funkcionalnost korisnicima. Ali verifikacijom, pretpostavljam da će u WAL-G-u biti moguće vratiti klaster i pokrenuti ga, te pokrenuti smoke testove: pg_dumpall u /dev/null i amcheck provjeru indeksa.
Trenutno u WAL-G ne postoji način da se odgodi jedna sigurnosna kopija iz WAL-a. To jest, podržavamo neki prozor. Na primjer, pohranjivanje posljednjih sedam dana, pohranjivanje posljednjih deset sigurnosnih kopija, pohranjivanje posljednje tri pune sigurnosne kopije. Često ljudi dođu i kažu: „Potrebna nam je rezervna kopija onoga što se dogodilo na Novu godinu i želimo to da zadržimo zauvek.“ WAL-G to još ne može učiniti. (Napomena - Ovo je već popravljeno. Pročitajte više - Opcija sigurnosne kopije u )
I nemamo kontrolne sume stranica i provjere integriteta za sve segmente osovine prilikom validacije PITR-a.
Iz svega ovoga sastavio sam projekat za Google Summer of Code. Ako znate pametne studente koji bi hteli da napišu nešto u Go i dobiju nekoliko hiljada dolara od jedne kompanije sa slovom „G“, onda im preporučite naš projekat. Ja ću biti mentor za ovaj projekat, oni to mogu. Ako nema učenika, onda ću to uzeti i uraditi sam na ljeto.
I imamo mnogo drugih malih problema na kojima postepeno radimo. I neke prilično čudne stvari se dešavaju.
Na primjer, ako WAL-G-u date praznu rezervnu kopiju, on će jednostavno pasti. Na primjer, ako mu kažete da mora napraviti sigurnosnu kopiju praznog foldera. Datoteka pg_control neće biti tamo. I pomisliće da nešto ne razume. U teoriji, u ovom slučaju morate napisati normalnu poruku korisniku da mu objasnite kako se koristi alat. Ali to čak nije odlika programiranja, već odlika dobrog, razumljivog jezika.
Ne znamo kako napraviti rezervnu kopiju van mreže. Ako baza podataka laže, ne možemo je napraviti sigurnosnu kopiju. Ali ovdje je sve vrlo jednostavno. Pozivamo rezervne kopije od strane LSN-a kada je počelo. LSN osnovne baze mora se pročitati iz kontrolne datoteke. A ovo je tako nerealizovana karakteristika. Mnogi backup sistemi mogu napraviti sigurnosnu kopiju osnovne baze podataka. I to je zgodno.
Trenutno se ne možemo pravilno nositi s nedostatkom sigurnosnog prostora. Zato što obično radimo sa velikim rezervnim kopijama kod kuće. I nisu stigli do toga. Ali ako neko želi da programira u Go upravo sada, dodajte rukovanje greškama izvan prostora u kantu. Definitivno ću razmotriti zahtjev za povlačenjem.
A glavna stvar koja nas brine je da želimo što više docker integracijskih testova koji provjeravaju različite scenarije. Trenutno testiramo samo osnovne scenarije. Prilikom svakog urezivanja, ali želimo provjeriti urezivanje po urezivanje svu funkcionalnost koju podržavamo. Konkretno, na primjer, imat ćemo dovoljno podrške za PostgreSQL 9.4-9.5. Podržavamo ih jer zajednica podržava PostgreSQL, ali ne provjeravamo urezivanje po urezivanje da bismo bili sigurni da sve nije pokvareno. I čini mi se da je to prilično ozbiljan rizik.
Imamo WAL-G koji radi na više od hiljadu klastera u upravljanju Yandex bazom podataka. I svaki dan pravi sigurnosnu kopiju nekoliko stotina terabajta podataka.
Imamo puno zadataka u našem kodu. Ako želite program, dođite, čekamo pull zahtjeve, čekamo pitanja.
Vaša pitanja
Dobro veče! Hvala ti! Pretpostavljam da ako koristite WAL-delta, vjerovatno se u velikoj mjeri oslanjate na pisanje cijele stranice. I ako jeste, jeste li radili testove? Pokazao si divan grafikon. Koliko ljepše postaje ako se FPW isključi?
Upisivanje cijele stranice nam je omogućeno, nismo pokušali da to onemogućimo. Odnosno, ja, kao programer, nisam pokušao da ga isključim. Sistem administratori koji su istraživali vjerovatno su istraživali ovaj problem. Ali trebamo FPW. Gotovo niko ga ne onemogućava, jer je inače nemoguće napraviti rezervnu kopiju sa replike.
Hvala na izvještaju! Imam dva pitanja. Prvo pitanje je šta će se dogoditi sa prostorima tablica?
Čekamo zahtjev za povlačenje. Naše baze podataka žive na SSD i NMVE diskovima i ova funkcija nam zapravo nije potrebna. Trenutno nisam spreman da trošim ozbiljno vreme na to da to uradim dobro. Ja se svim srcem zalažem da ovo podržimo. Ima ljudi koji su to podržali, ali su podržali na način koji njima odgovara. Napravili su viljušku, ali ne rade zahtjeve za povlačenjem. (Dodano u verziji 0.2.13)
I drugo pitanje. Rekli ste na samom početku da WAL-G pretpostavlja da radi sam i da nisu potrebni omoti. I sama koristim omote. Zašto ih ne bi trebalo koristiti?
Želimo da bude jednostavno kao balalajka. To znači da vam ne treba ništa osim balalajke. Želimo da sistem bude jednostavan. Ako imate funkcionalnost koju treba da uradite u skripti, dođite i recite nam – mi ćemo to uraditi u Go.
Dobro veče! Hvala na izvještaju! Nismo uspjeli natjerati WAL-G da radi s GPG dešifriranjem. Šifrira normalno, ali ne želi dešifrirati. Da li je to nešto što nam nije pošlo za rukom? Situacija je depresivna.
Napravite problem na GitHubu i hajde da ga riješimo.
Odnosno, niste se susreli sa ovim?
Postoji karakteristika izvještaja o grešci da kada WAL-G ne razumije o kakvoj se vrsti datoteke radi, pita: "Možda je šifrirana?" Možda problem uopće nije u enkripciji. Želim poboljšati logovanje na ovu temu. Mora ga dešifrovati. Trenutno radimo na ovoj temi u smislu da nam se baš i ne sviđa kako je organizovan sistem za dobijanje javnih i privatnih ključeva. Zato što eksterni GPG zovemo tako da nam on daje svoje ključeve. I onda uzimamo ove ključeve i prenosimo ih u interni GPG, a to je otvoreni PGP, koji je za nas kompajliran unutar WAL-G-a i tamo zovemo enkripciju. U tom smislu, želimo da poboljšamo sistem i želimo da podržimo Libsodium enkripciju (Dodato u verziji 0.2.15). Naravno, dekodiranje bi trebalo funkcionirati, hajde da to shvatimo - potreban vam je više simptom nego nekoliko riječi. Možete se ponekad okupiti u sobi za zvučnike i pogledati sistem. (PGP enkripcija bez eksternog GPG-a - v0.2.9)
Zdravo! Hvala na izvještaju! Imam dva pitanja. Imam čudnu želju da uradim pg_basebackup i WAL log u dva provajdera, tj. želim da radim jedan oblak i drugi. Postoji li neki način da se ovo uradi?
Ovo sada ne postoji, ali je zanimljiva ideja.
Jednostavno ne vjerujem jednom provajderu, želim isto imati i kod drugog, za svaki slučaj.
Ideja je zanimljiva. Tehnički, ovo nije nimalo teško implementirati. Da spriječim da se ideja izgubi, mogu li vas zamoliti da napravite problem na GitHubu?
Da, naravno.
A onda, kada studenti dođu na Google Summer of Code, mi ćemo ih dodati u projekat kako bi bilo više posla da se izvuče više od njih.
I drugo pitanje. Postoji problem na GitHubu. Mislim da je već zatvoreno. Prilikom restauracije dolazi do panike. I da biste ga porazili, napravili ste zasebnu skupštinu. To je tačno u pitanjima. I postoji opcija da se napravi promenljivo okruženje u jednoj niti. I zato radi veoma sporo. I mi smo naišli na ovaj problem, i on još nije riješen.
Problem je u tome što iz nekog razloga skladište (CEPH) resetuje vezu kada dođemo do nje sa velikom konkurentnošću. Šta se može učiniti povodom toga? Logika ponovnog pokušaja izgleda ovako. Pokušavamo ponovo preuzeti fajl. U jednom prolazu smo imali veliki broj fajlova koji nisu preuzeti, napravićemo drugi za sve one koji se nisu prijavili. I sve dok se barem jedan fajl učitava po iteraciji, ponavljamo i ponavljamo i ponavljamo. Poboljšali smo logiku ponovnog pokušaja - eksponencijalno povlačenje. Ali nije sasvim jasno što učiniti s činjenicom da se veza jednostavno prekida na strani sustava za pohranu. To jest, kada otpremamo na jedan stream, on ne prekida ove veze. Šta tu možemo poboljšati? Imamo ograničenje mreže, možemo ograničiti svaku vezu brojem bajtova koje šalje. Inače, ne znam kako da se nosim sa činjenicom da nam pohrana objekata ne dozvoljava paralelno preuzimanje ili preuzimanje sa njega.
Nema SLA? Zar im nije napisano kako dopuštaju da se muče?
Poenta je da ljudi koji se pomisle na ovo pitanje obično imaju svoj trezor. Odnosno, niko ne dolazi iz Amazona ili Google Cloud-a ili Yandex Object Storage-a.
Možda pitanje više nije za vas?
Pitanje ovdje u ovom slučaju nije važno kome. Ako ima bilo kakvih ideja kako se nositi s tim, uradimo to u WAL-G-u. Ali za sada nemam dobre ideje kako da se nosim sa ovim. Postoje neki objekti za pohranu objekata koji podržavaju drugačije ispisivanje rezervnih kopija. Tražite od njih da navedu objekte, a oni tamo dodaju folder. WAL-G se uplašio zbog ovoga - ovdje postoji neka stvar koja nije datoteka, ne mogu je vratiti, što znači da rezervna kopija nije vraćena. To jest, u stvari, imate potpuno vraćen klaster, ali vam vraća pogrešan status jer je Object Storage vratio neke čudne informacije koje nije u potpunosti razumio.
Ovo se dešava u oblaku pošte.
Ako možete da napravite reprodukciju...
Dosljedno se reprodukuje...
Ako postoji reprodukcija, onda mislim da ćemo eksperimentisati sa strategijama ponovnog pokušaja i smisliti kako da pokušamo ponovo i razumjeti šta oblak zahtijeva od nas. Možda će nam biti stabilno na tri veze i neće prekinuti vezu, onda ćemo pažljivo doći do tri. Jer sada vrlo brzo prekidamo vezu, tj. ako smo pokrenuli oporavak sa 16 niti, onda će nakon prvog ponovnog pokušaja biti 8 niti, 4 niti, 2 niti i jedna. A onda će povući datoteku u jedan tok. Ako postoje neke magične vrijednosti kao što su 7,5 niti su najbolje za pumpanje, onda ćemo se zadržati na njima i pokušati napraviti još 7,5 niti. Evo jedne ideje.
Hvala na izvještaju! Kako izgleda kompletan tok rada za rad sa WAL-G? Na primjer, u glupom slučaju kada nema delta na stranicama. I uzimamo i uklanjamo početnu rezervnu kopiju, a onda arhiviramo osovinu dok ne budemo plavi u licu. Ovdje, koliko sam shvatio, dolazi do kvara. U nekom trenutku morate napraviti delta backup stranica, tj. neki vanjski proces pokreće ovo ili kako se to događa?
Delta backup API je prilično jednostavan. Postoji broj - maksimalni delta koraci, tako se to zove. Zadana vrijednost je nula. To znači da svaki put kada napravite backup-push, on preuzima punu sigurnosnu kopiju. Ako ga promijenite u bilo koji pozitivan broj, na primjer, 3, onda kada sljedeći put napravite backup-push, on će pogledati istoriju prethodnih rezervnih kopija. On vidi da ne prelazite lanac od 3 delte i pravi deltu.
Odnosno, svaki put kada pokrenemo WAL-G, on pokušava napraviti potpunu sigurnosnu kopiju?
Ne, mi pokrećemo WAL-G i on pokušava napraviti deltu ako to dozvoljavaju vaša pravila.
Grubo govoreći, ako ga svaki put pokrenete sa nulom, hoće li se ponašati kao pg_basebackup?
Ne, i dalje će raditi brže jer koristi kompresiju i paralelizam. Pg_basebackup će staviti osovinu pored vas. WAL-G pretpostavlja da ste konfigurisali arhiviranje. I izdaće upozorenje ako nije konfigurisan.
Pg_basebackup se može pokrenuti bez osovina.
Da, onda će se ponašati skoro isto. Pg_basebackup kopira u sistem datoteka. Inače, imamo novu funkciju koju sam zaboravio spomenuti. Sada možemo napraviti rezervnu kopiju na sistem datoteka sa pg_basebackup. Ne znam zašto je ovo potrebno, ali postoji.
Na primjer, na CephFS. Ne žele svi konfigurirati pohranu objekata.
Da, vjerovatno su zato postavili pitanje o ovoj funkciji kako bismo to mogli učiniti. I uspjeli smo.
Hvala na izvještaju! Postoji samo pitanje o kopiranju u sistem datoteka. Izvan kutije, da li sada podržavate kopiranje u udaljenu pohranu, na primjer, ako postoji neka polica u data centru ili nešto drugo?
U ovoj formulaciji, ovo je teško pitanje. Da, podržavamo, ali ova funkcionalnost još nije uključena ni u jedno izdanje. Odnosno, sva prethodna izdanja to podržavaju, ali verzije izdanja ne. Ova funkcionalnost je dodana u verziji 0.2. Definitivno će uskoro biti objavljen, čim popravimo sve poznate greške. Ali trenutno se to može učiniti samo u prethodnom izdanju. Postoje dvije greške u predizdanju. Problem sa WAL-E oporavkom, nismo ga riješili. A u najnovijem pre-izdanju dodana je greška o delta-backup-u. Stoga preporučujemo svima da koriste verzije izdanja. Čim više nema grešaka u predizdanju, možemo reći da podržavamo Google Cloud, stvari kompatibilne sa S3 i pohranu datoteka.
Zdravo, hvala na izvještaju. Koliko sam ja shvatio, WAL-G nije neka vrsta centralizovanog sistema poput barmena? Planirate li krenuti u ovom pravcu?
Problem je što smo se udaljili od ovog pravca. WAL-G živi na osnovnom hostu, na hostu klastera i na svim hostovima u klasteru. Kada smo se preselili u nekoliko hiljada klastera, imali smo mnogo barmenskih instalacija. I svaki put kada se nešto u njima raspadne, to je veliki problem. Budući da ih treba popraviti, morate razumjeti koji klasteri sada nemaju rezervne kopije. Ne planiram da razvijam WAL-G u pravcu fizičkog hardvera za rezervne sisteme. Ako zajednica želi neku funkcionalnost ovdje, uopće mi ne smeta.
Imamo timove koji su odgovorni za skladištenje. I osećamo se tako dobro da to nismo mi, da postoje posebni ljudi koji stavljaju naše fajlove tamo gde su fajlovi sigurni. Tamo rade razne vrste pametnog kodiranja kako bi izdržali gubitak određenog broja datoteka. Oni su odgovorni za propusni opseg mreže. Kada imate barmena, možete iznenada otkriti da su se male baze podataka sa velikim prometom skupile na istom serveru. Čini se da imate puno prostora na njemu, ali iz nekog razloga sve ne štima kroz mrežu. Moglo bi ispasti i obrnuto. Tamo ima puno mreža, ima procesorskih jezgara, ali ovdje nema diskova. I mi smo se umorili od ove potrebe da nečim žongliramo i prešli smo na to da je skladištenje podataka posebna usluga, za koju su odgovorni posebni ljudi.
PS Objavljena je nova verzija , u kojem možete koristiti konfiguracijsku datoteku .walg.json, koja se po defaultu nalazi u početnom direktoriju postgresa. Možete napustiti bash skripte. Primjer .walg.json je u ovom izdanju
Video:
izvor: www.habr.com