Predlažem da pročitate transkript izvješća s početka 2019. godine Andreja Borodina "Sigurnosne kopije s WAL-G. Što je tamo u 2019.?"
Bok svima! Moje ime je Andrej Borodin. Ja sam programer u Yandexu. PostgreSQL me zanima od 2016. godine, nakon što sam razgovarao s programerima i rekli su da je sve jednostavno - uzmeš izvorni kod i izgradiš ga, i sve će ispasti. I od tada ne mogu prestati - pišem razne stvari.
Jedna od stvari na kojoj radim je rezervni sustav. . Općenito, u Yandexu već jako dugo radimo na sustavima za sigurnosno kopiranje u PostgreSQL-u. Na Internetu možete pronaći niz od šest izvješća o tome kako izrađujemo sigurnosne sustave. I svake godine se malo razvijaju, malo razvijaju i postaju pouzdaniji.
Ali današnje izvješće nije samo o tome što smo učinili, već io tome koliko je jednostavno i što jest. Koliko vas je već gledalo moje reportaže o WAL-G-u? Dobro je da dosta ljudi nije gledalo, jer krenut ću od najjednostavnije stvari.
Ako odjednom imate PostgreSQL klaster, a mislim da ih svatko ima nekoliko sa sobom, i odjednom još nema sustava za sigurnosno kopiranje, tada morate nabaviti bilo koju S3 pohranu ili pohranu kompatibilnu 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 izradite kantu. To je samo spremnik za informacije.
Stvorite korisnika usluge.
Kreirajte pristupni ključ za korisnika usluge: aws-s3-key.
Preuzmite najnovije stabilno izdanje WAL-G-a.
Po čemu se naša izdanja prije izdanja razlikuju od izdanja? Često me traže da prijevremeno otpustim. A ako nema greške u verziji dovoljno vremena, na primjer, mjesec dana, onda je izdam. Evo ovog izdanja iz studenog. A to znači da smo svaki mjesec pronašli neku grešku, obično u nekritičnoj funkcionalnosti, ali još nismo izdali izdanje. Prethodna verzija je tek u studenom. U njemu nema nama poznatih grešaka, tj. greške su dodavane kako je projekt napredovao.
Nakon što ste preuzeli WAL-G, možete pokrenuti jednostavnu naredbu "popis pričuvnih kopija", prosljeđujući varijable okruženja. I spojit će se na Object Storage i reći vam koje sigurnosne kopije imate. U početku, naravno, ne biste trebali imati sigurnosne kopije. Poanta ovog slajda je pokazati da je sve vrlo 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 pgdata lokaciju vašeg klastera. I najvjerojatnije će vam PostgreSQL reći, ako već nemate sustav za sigurnosno kopiranje, da morate omogućiti "arhivski način".
To znači da morate otići u postavke i uključiti “archive_mode = on” i dodati “archive_command”, što je također podnaredba u WAL-G-u. Ali iz nekog razloga ljudi često koriste bar skripte na ovu temu i omotaju ih oko WAL-G-a. Molim te, nemoj to raditi. Koristite funkcionalnost koja se nalazi u WAL-G. Ako vam nešto nedostaje, pišite na . WAL-G pretpostavlja da je to jedini program koji radi u archive_command.
WAL-G koristimo uglavnom za stvaranje klastera visoke dostupnosti u upravljanju bazom podataka Yandex.
I obično se koristi u topologiji jednog Mastera i nekoliko replikacija. Istodobno izrađuje sigurnosnu kopiju u Yandex Object Storageu.
Najčešći scenariji su stvaranje kopija klastera pomoću oporavka točke u vremenu. Ali u ovom slučaju performanse sigurnosnog sustava za nas nisu toliko važne. Samo trebamo učitati novi klaster iz sigurnosne kopije.
Obično nam je potrebna sigurnosna izvedba sustava 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. Moraju dodati novu repliku. Ako dodamo opterećenje iz pg_basebackup u Master, tada bi se Master mogao srušiti. Stoga nam je bilo vrlo 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 za ponovnim pokretanjem starog Mastera nakon prebacivanja Cluster Mastera iz podatkovnog centra s kojim je izgubljena povezanost.
- Kao rezultat toga, kada smo formulirali zahtjeve za sustav kopiranja, shvatili smo da pg_basebackup nije prikladan za nas kada radimo u oblaku.
- Htjeli smo moći komprimirati naše podatke. Ali gotovo svaki sustav sigurnosnog kopiranja osim onoga koji dolazi u kutiji omogućit će kompresiju podataka.
- Htjeli smo sve paralelizirati jer korisnik u oblaku kupuje velik broj procesorskih jezgri. Ali ako nemamo paralelizam u nekoj operaciji, onda veliki broj jezgri postaje beskoristan.
- Potrebna nam je enkripcija jer podaci često nisu naši i ne mogu se pohraniti u čistom tekstu. Usput, naš doprinos WAL-G-u započeo je enkripcijom. Završili smo enkripciju u WAL-G-u, nakon čega smo upitani: “Možda će netko od nas razvijati projekt?” I od tada radim s WAL-G-om više od godinu dana.
- Trebalo nam je i prigušivanje resursa, jer smo tijekom vremena koristeći oblak otkrili da ponekad ljudi noću imaju važno opterećenje namirnicama i da se u to opterećenje ne može ometati. Zato smo dodali prigušivanje resursa.
- Kao i popis i upravljanje.
- I provjera.
Pogledali smo mnogo različitih alata. Srećom, imamo veliki izbor u PostgreSQL-u. I svugdje nam je nešto nedostajalo, nekome jedna mala funkcija, nekome jedna mala značajka.
Nakon što smo ispitali postojeće sustave, došli smo do zaključka da ćemo razviti WAL-G. Tada je to bio novi projekt. Bilo je prilično lako utjecati na razvoj prema cloud infrastrukturi backup sustava.
Glavna ideologija koje se držimo je da WAL-G treba biti jednostavan kao balalajka.
WAL-G ima 4 naredbe. Ovaj:
WAL-PUSH – arhivirajte osovinu.
WAL-FETCH – dobiti osovinu.
BACKUP-PUSH – napravite sigurnosnu kopiju.
BACKUP-FETCH – dobiti sigurnosnu kopiju iz sigurnosnog sustava.
Zapravo, WAL-G ima i upravljanje ovim sigurnosnim kopijama, tj. ispisivanje i brisanje zapisa i sigurnosnih kopija u povijesti koje trenutno više nisu potrebne.
Jedna od važnih funkcija za nas je funkcija izrade delta kopija.
Delta kopije znače da ne stvaramo punu sigurnosnu kopiju cijelog klastera, već samo promijenjene stranice promijenjenih datoteka u klasteru. Čini se da je funkcionalno ovo vrlo slično mogućnosti oporavka pomoću WAL-a. Ali možemo usporedno skupiti WAL jednonitnu delta sigurnosnu kopiju. Sukladno tome, kada imamo osnovni backup napravljen u subotu, delta sigurnosne kopije dnevno, au četvrtak ne uspijemo, tada trebamo roll up 4 delta sigurnosne kopije i 10 sati WAL-a. Bit će potrebno otprilike isto vrijeme jer se delta sigurnosne kopije vrte paralelno.
Delte temeljene na LSN-u - to znači da ćemo prilikom izrade sigurnosne kopije morati kombinirati svaku stranicu i provjeriti njen LSN s LSN-om prethodne sigurnosne kopije kako bismo shvatili da se promijenila. Svaka stranica koja bi potencijalno mogla sadržavati promijenjene 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 dosljedan. PostgreSQL arhivira jednu WAL datoteku i prilikom vraćanja zahtijeva jednu WAL datoteku. Ali kada baza podataka zatraži jednu WAL datoteku pomoću naredbe "WAL-FETCH", pozivamo naredbu "WAL-PREFETCH", koja priprema sljedećih 8 datoteka za paralelno dohvaćanje podataka iz pohrane objekata.
A kada nas baza podataka zatraži da arhiviramo jednu datoteku, gledamo archive_status i vidimo postoje li druge WAL datoteke. I također pokušavamo paralelno preuzeti WAL. To osigurava značajno povećanje performansi i značajno smanjuje udaljenost u broju nearhiviranih WAL-ova. Mnogi programeri sustava za sigurnosno kopiranje vjeruju da je ovo tako rizičan sustav jer se oslanjamo na svoje znanje o unutrašnjosti koda koji nije PostgreSQL API. PostgreSQL ne jamči prisutnost mape archive_status za nas i ne jamči semantiku, prisutnost signala spremnosti za WAL datoteke tamo. Ipak, proučavamo izvorni kod, vidimo da je to tako i pokušavamo to iskoristiti. I mi kontroliramo smjer u kojem se PostgreSQL razvija; ako se ovaj mehanizam iznenada pokvari, prestat ćemo ga koristiti.
U svom čistom obliku, WAL delta temeljena na LSN-u zahtijeva čitanje bilo koje datoteke klastera čije se vrijeme u načinu rada u datotečnom sustavu promijenilo od prethodne sigurnosne kopije. S tim smo živjeli 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 Masteru, ne samo da ga komprimiramo, šifriramo i šaljemo na mrežu, već ga istovremeno i čitamo. Analiziramo i čitamo zapise u njemu. Razumijemo koji su se blokovi promijenili i prikupljamo delta datoteke.
Delta datoteka opisuje određeni raspon WAL datoteka, opisuje informacije o tome koji su blokovi promijenjeni u ovom rasponu WAL-a. I onda se te delta datoteke također arhiviraju.
Ovdje se suočavamo s činjenicom da smo sve prilično brzo paralelizirali, ali ne možemo paralelno čitati sekvencijalnu povijest, jer u nekom segmentu možemo naići na kraj prethodnog WAL zapisa, s kojim još nemamo što povezati, jer paralelno čitanje dovelo je do toga da prvo analiziramo budućnost, koja još nema prošlost.
Kao rezultat toga, morali smo staviti nerazumljive dijelove u _delta_partial datoteke. Kao rezultat toga, kada se vratimo u prošlost, zalijepit ćemo dijelove WAL zapisa u jedan, nakon toga ćemo ga analizirati i shvatiti što se u njemu promijenilo.
Ako u povijesti našeg shaft parsiranja postoji barem jedna točka u kojoj ne razumijemo što se događa, tada ćemo, sukladno tome, tijekom sljedeće sigurnosne kopije biti prisiljeni ponovo pročitati cijeli klaster, baš kao što smo učinili s običnim LSN-om temeljena delta.
Kao rezultat toga, sva naša patnja dovela je do činjenice da smo otvorili knjižnicu za raščlanjivanje WAL-G. Koliko ja znam još ga nitko ne koristi, ali ako ga netko želi neka napiše i koristi, u javnoj je domeni. (Ažurirana poveznica )
Kao rezultat toga, svi tokovi informacija izgledaju prilično komplicirano. Naš Majstor arhivira osovinu i arhivira delta turpije. A replika koja pravi sigurnosnu kopiju mora primiti delta datoteke tijekom vremena koje je proteklo između sigurnosnih kopija. U ovom slučaju, dijelove povijesti trebat će skupno dodati i raščlaniti jer cijela povijest ne stane u velike segmente. I tek nakon toga replika može arhivirati punu delta sigurnosnu kopiju.
Na grafikonima sve izgleda puno jednostavnije. Ovo je preuzimanje s jednog od naših pravih klastera. Imamo LSN-based, napravljen u jednom danu. I vidimo da je delta backup temeljen na LSN-u radio od tri ujutro do pet ujutro. Ovo je opterećenje u broju procesorskih jezgri. WAL-delta nam je ovdje oduzela 20-ak minuta, odnosno postala je značajno brža, ali je u isto vrijeme došlo do intenzivnije razmjene preko mreže.
Budući da imamo informacije o tome koji su se blokovi promijenili i u koje vrijeme u povijesti baze podataka, otišli smo dalje i odlučili integrirati funkcionalnost - PostgreSQL proširenje pod nazivom “pg_prefaulter”
To znači da kada rezervna baza izvrši naredbu vraćanja, govori WAL-G-u da dohvati sljedeću WAL datoteku. Razumijemo kojim će blokovima podataka otprilike pristupiti proces oporavka WAL-a u bliskoj budućnosti i pokrenuti operaciju čitanja tih blokova. To je učinjeno kako bi se povećala izvedba SSD kontrolera. Zato što će WAL rola doći do stranice koju treba promijeniti. Ova je stranica na disku i nije u predmemoriji stranice. I on će istovremeno č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. Pokreće više pristupa disku tako da se izvršavaju paralelno. Ovo dobro funkcionira na SSD diskovima, ali, nažalost, apsolutno nije primjenjivo za tvrdi disk, jer ga samo ometamo svojim upitima.
Ovo je sada u kodu.
Postoje značajke koje bismo željeli dodati.
Ova slika pokazuje da WAL-delta traje relativno kratko vrijeme. A ovo je očitavanje promjena koje su se dogodile u bazi podataka tijekom dana. WAL-deltu bismo mogli raditi ne samo noću, jer to 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. I to bi se moglo nazvati "instant WAL-delta".
Poanta je da kada obnovimo klaster, smanjujemo broj priča koje moramo sekvencijalno smotati. Odnosno, količinu WAL-a koju PostgreSQL kotrlja treba smanjiti jer oduzima dosta vremena.
Ali to nije sve. Ako znamo da će neki blok biti promijenjen do točke dosljednosti sigurnosne kopije, ne možemo ga promijeniti u prošlosti. Odnosno, sada imamo optimizaciju WAL-delta prosljeđivanja po datotekama. To znači da ako je, na primjer, u utorak tablica u potpunosti izbrisana ili su neke datoteke u potpunosti izbrisane iz tablice, tada kada se delta prebaci u ponedjeljak i vrati se pg_basebackup u subotu, nećemo niti stvoriti te podatke.
Želimo proširiti ovu tehnologiju na razinu stranice. Odnosno, ako se neki dio datoteke promijeni u ponedjeljak, ali će biti prebrisan u srijedu, tada prilikom vraćanja na točku u četvrtak, ne moramo pisati prvih nekoliko verzija stranica na disk.
Ali to je još uvijek ideja o kojoj se kod nas aktivno raspravlja, ali još nije došla do koda.
Želimo napraviti još jednu značajku u WAL-G-u. Želimo ga učiniti proširivim jer trebamo podržavati različite baze podataka i željeli bismo moći pristupiti upravljanju sigurnosnom kopijom na isti način. Ali problem je u tome što su MySQL API-ji radikalno različiti. U MySQL-u, PITR se ne temelji na fizičkom WAL dnevniku, već na binlogu. I nemamo sustav arhiviranja u MySQL-u koji bi rekao nekom vanjskom sustavu da je ovaj binlog gotov i da ga treba arhivirati. Trebamo stati negdje u cron s bazom i provjeriti ima li nešto spremno?
I na isti način, tijekom vraćanja MySQL-a, ne postoji naredba vraćanja koja bi mogla reći sustavu da trebam te i te datoteke. Prije nego počnete ponovno graditi svoj klaster, morate znati koje će vam datoteke trebati. Vi sami trebate pogoditi koje će vam datoteke trebati. Ali ti se problemi možda mogu nekako zaobići. (Pojašnjenje: MySQL je već podržan)
U izvješću sam također želio govoriti o onim slučajevima kada WAL-G nije prikladan za vas.
Ako nemate sinkronu repliku, WAL-G ne jamči da će posljednji segment biti sačuvan. A ako arhiviranje zaostaje za posljednjih nekoliko segmenata povijesti, to je rizik. Ako nema sinkrone replike, ne bih preporučio korištenje WAL-G-a. Ipak, uglavnom je dizajniran za instalaciju u oblaku, što podrazumijeva High Availability rješenje sa sinkronom replikom, koja je odgovorna za sigurnost zadnjih angažiranih bajtova.
Često vidim ljude koji pokušavaju pokrenuti i WAL-G i WAL-E u isto vrijeme. 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 budući da oba ova sustava koriste paralelni wal-push, počinju krasti datoteke jedni drugima. Ako to popravimo u WAL-G-u, i dalje će ostati u WAL-E-u. U WAL-E-u gleda archive-status, vidi gotove datoteke i arhivira ih, dok drugi sustavi jednostavno neće znati da je ova WAL datoteka postojala, jer je PostgreSQL neće pokušati drugi put arhivirati.
Što ćemo popraviti ovdje na WAL-G strani? Nećemo obavijestiti PostgreSQL da je ova datoteka paralelno prenesena, a kada PostgreSQL zatraži da je arhiviramo, mi ćemo već znati da je takva datoteka sa ovim načinom vremena i sa ovim md5 već arhivirana i jednostavno ćemo reći PostgreSQL - OK, sve je spremno, a da se zapravo ništa ne radi.
Ali ovaj problem vjerojatno neće biti riješen na strani WAL-E, tako da je trenutno nemoguće stvoriti naredbu arhiviranja koja će arhivirati datoteku iu WAL-G i WAL-E.
Osim toga, postoje slučajevi u kojima vam WAL-G trenutno nije prikladan, ali mi ćemo to svakako popraviti.
Prvo, trenutno nemamo ugrađenu sigurnosnu provjeru. Nemamo potvrdu ni tijekom sigurnosnog kopiranja ni tijekom oporavka. Naravno, ovo je implementirano u oblaku. Ali to se provodi jednostavno prethodnom provjerom, jednostavnim vraćanjem klastera. Želio bih ovu funkciju dati korisnicima. Ali provjerom pretpostavljam da će u WAL-G-u biti moguće obnoviti klaster i pokrenuti ga, te pokrenuti dimne testove: pg_dumpall u /dev/null i amcheck provjeru indeksa.
Trenutno u WAL-G-u ne postoji način za odgodu jedne sigurnosne kopije iz WAL-a. Odnosno, podržavamo neki prozor. Na primjer, pohranjivanje zadnjih sedam dana, pohranjivanje zadnjih deset sigurnosnih kopija, pohranjivanje posljednje tri pune sigurnosne kopije. Često ljudi dođu i kažu: "Trebamo sigurnosnu kopiju onoga što se dogodilo na Novu godinu i želimo je zadržati zauvijek." WAL-G još ne zna kako to učiniti. (Napomena - ovo je već popravljeno. Pročitajte više - opcija označavanja sigurnosne kopije u )
I nemamo kontrolne zbrojeve stranica i provjere integriteta za sve segmente vratila prilikom provjere PITR-a.
Iz svega toga sastavio sam projekt za Google Summer of Code. Ako poznajete pametne studente koji bi željeli nešto napisati u Go-u i dobiti nekoliko tisuća dolara od jedne tvrtke na slovo G, preporučite im naš projekt. Ja ću biti mentor za ovaj projekt, oni to mogu. Ako nema učenika, onda ću uzeti i napraviti sam na ljeto.
A imamo i mnogo drugih malih problema na kojima postupno radimo. I događaju se neke prilično čudne stvari.
Na primjer, ako WAL-G-u date praznu sigurnosnu kopiju, ona će jednostavno pasti. Na primjer, ako mu kažete da mora sigurnosno kopirati praznu mapu. Datoteka pg_control neće biti tamo. I mislit će da nešto ne razumije. U teoriji, u ovom slučaju morate napisati normalnu poruku korisniku da mu objasnite kako koristiti alat. Ali to nije čak ni značajka programiranja, već značajka dobrog, razumljivog jezika.
Ne znamo kako napraviti izvanmrežnu sigurnosnu kopiju. Ako baza podataka laže, ne možemo je sigurnosno kopirati. Ali ovdje je sve vrlo jednostavno. Pozivamo sigurnosne kopije pomoću LSN-a kada je počelo. LSN temeljne baze mora se pročitati iz kontrolne datoteke. A ovo je tako nerealizirana značajka. Mnogi sustavi za sigurnosno kopiranje mogu sigurnosno kopirati temeljnu bazu podataka. I prikladno je.
Trenutačno ne možemo pravilno riješiti nedostatak rezervnog prostora. Budući da obično radimo s velikim sigurnosnim kopijama kod kuće. I nisu stigli do toga. Ali ako netko sada želi programirati u Go-u, u spremnik dodajte rukovanje pogreškama zbog nedostatka prostora. Svakako ću razmotriti zahtjev za povlačenje.
A glavna stvar koja nas brine je da želimo što više docker integracijskih testova koji provjeravaju razne scenarije. Trenutno testiramo samo osnovne scenarije. Na svakom predanju, ali želimo provjeriti preuzimanje po predavanju sve funkcije koje 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 predaju po predaju kako 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 tisuću klastera u upravljanju bazom podataka Yandex. Svaki dan stvara sigurnosnu kopiju nekoliko stotina terabajta podataka.
Imamo puno TODO u našem kodu. Ako želite programirati, dođite, čekamo pull requests, čekamo pitanja.
pitanja
Dobra večer! Hvala vam! Pretpostavljam da ako koristite WAL-delta, vjerojatno se uvelike oslanjate na pisanje preko cijele stranice. I ako jeste, jeste li proveli testove? Pokazao si prekrasan grafikon. Koliko ljepše postaje ako se FPW isključi?
Pisanje preko cijele stranice nam je omogućeno, nismo ga pokušali onemogućiti. Odnosno, ja ga kao programer nisam pokušao isključiti. Administratori sustava koji su istraživali vjerojatno su istražili ovo pitanje. Ali trebamo FPW. Gotovo ga nitko ne onemogućuje, jer je inače nemoguće napraviti backup s replike.
Hvala na izvješću! Imam dva pitanja. Prvo pitanje je što će se dogoditi s tabličnim prostorima?
Čekamo zahtjev za povlačenjem. Naše baze podataka žive na SSD i NMVE diskovima i ova značajka nam zapravo nije potrebna. Trenutno nisam spreman trošiti ozbiljno vrijeme na to da to učinim dobro. Ja se svim srcem zalažem da to podržimo. Ima ljudi koji su to podržali, ali podržali na način kako njima odgovara. Napravili su fork, ali ne postavljaju 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 nikakvi omoti. I sama koristim omote. Zašto ih ne bi trebalo koristiti?
Želimo da bude jednostavno poput balalajke. To znači da vam ne treba ništa osim balalajke. Želimo da sustav bude jednostavan. Ako imate funkcionalnost koju trebate napraviti u skripti, dođite i recite nam - mi ćemo to učiniti u Go.
Dobra večer! Hvala na izvješću! Nismo uspjeli natjerati WAL-G da radi s GPG dešifriranjem. Šifrira normalno, ali ne želi dešifrirati. Je li to nešto što nam nije uspjelo? Situacija je depresivna.
Napravite problem na GitHubu i idemo to riješiti.
Odnosno, niste se susreli s ovim?
Postoji značajka izvješća o pogrešci da kada WAL-G ne razumije o kojoj je vrsti datoteke riječ, pita: "Možda je šifrirana?" Možda problem uopće nije enkripcija. Želim poboljšati bilježenje ove teme. Mora ga dešifrirati. Trenutno radimo na ovoj temi u smislu da nam se baš i ne sviđa kako je organiziran sustav dobivanja javnih i privatnih ključeva. Zato što zovemo vanjski GPG tako da nam daje svoje ključeve. I onda uzmemo te ključeve i prenesemo ih u interni GPG, koji je otvoreni PGP, koji je kompiliran za nas unutar WAL-G-a, i tamo zovemo šifriranje. U tom pogledu želimo poboljšati sustav i želimo podržati Libsodium enkripciju (Dodano u verziji 0.2.15). Naravno, dekodiranje bi trebalo funkcionirati, idemo shvatiti - treba vam više simptoma nego nekoliko riječi. Možete se ponekad okupiti u govornici i pogledati sustav. (PGP enkripcija bez vanjskog GPG-a - v0.2.9)
Zdravo! Hvala na izvješću! Imam dva pitanja. Imam čudnu želju napraviti pg_basebackup i WAL log u dva providera, tj. želim napraviti jedan cloud i drugi. Postoji li neki način da se to učini?
Ovo sada ne postoji, ali je zanimljiva ideja.
Jednostavno ne vjerujem jednom pružatelju, želim imati isto kod drugog, za svaki slučaj.
Ideja je zanimljiva. Tehnički, to uopće nije teško provesti. Da spriječim da se ideja izgubi, mogu li vas zamoliti da napravite izdanje na GitHubu?
Da, naravno.
A onda, kada studenti dođu na Google Summer of Code, mi ćemo ih dodati u projekt kako bi bilo više posla da izvučemo više od njih.
I drugo pitanje. Postoji problem na GitHubu. Mislim da je već zatvoreno. Postoji panika tijekom vraćanja. A da biste ga porazili, napravili ste zasebnu skupštinu. Točno je u pitanjima. A postoji i opcija da se napravi varijabilno okruženje u jednoj niti. I zato radi jako sporo. I naišli smo na ovaj problem, koji još nije riješen.
Problem je što iz nekog razloga pohrana (CEPH) resetira vezu kada dođemo do nje s visokom konkurentnošću. Što se može učiniti po tom pitanju? Logika ponovnog pokušaja izgleda ovako. Pokušavamo ponovno preuzeti datoteku. U jednom prolazu nam nije skinut niz datoteka, napravit ćemo drugi za sve one koji se nisu ulogirali. I sve dok se barem jedna datoteka učitava po iteraciji, ponavljamo i ponavljamo i ponavljamo. Poboljšali smo logiku ponovnog pokušaja - eksponencijalni backoff. Ali nije sasvim jasno što učiniti s činjenicom da se veza jednostavno prekida na strani sustava za pohranu. Odnosno, kada postavljamo na jedan stream, on ne prekida ove veze. Što tu možemo poboljšati? Imamo prigušivanje mreže, možemo ograničiti svaku vezu brojem bajtova koje šalje. Inače, ne znam kako se nositi s činjenicom da nam pohrana objekata ne dopušta paralelno preuzimanje ili preuzimanje s nje.
Nema SLA? Nije li za njih pisano kako se daju mučiti?
Poanta je da ljudi koji postavljaju ovo pitanje obično imaju svoj trezor. Odnosno, nitko ne dolazi iz Amazona ili Google Clouda ili Yandex Object Storagea.
Možda pitanje više nije za vas?
Pitanje ovdje u ovom slučaju nije bitno kome. Ako ima ikakvih ideja kako to riješiti, učinimo to u WAL-G-u. Ali zasad nemam dobrih ideja kako se nositi s tim. Postoje neki Object Storage koji podržavaju drugačije ispisivanje sigurnosnih kopija. Tražite od njih da navedu objekte, a oni tamo dodaju mapu. WAL-G se toga uplaši - ovdje postoji nešto što nije datoteka, ne mogu je vratiti, što znači da sigurnosna kopija nije vraćena. To jest, zapravo, imate potpuno obnovljeni klaster, ali vam vraća pogrešan status jer je Object Storage vratio neke čudne informacije koje nije u potpunosti razumio.
To je stvar koja se događa u oblaku pošte.
Ako možete izgraditi reprodukciju...
Dosljedno se reproducira...
Ako dođe do reprodukcije, mislim da ćemo eksperimentirati sa strategijama ponovnog pokušaja i smisliti kako ponovno pokušati i razumjeti što oblak od nas traži. Možda će nam biti stabilan na tri veze i neće prekinuti vezu, onda ćemo pažljivo doći do tri. Zato što sada vrlo brzo prekidamo vezu, tj. ako smo pokrenuli oporavak sa 16 niti, tada će nakon prvog ponovnog pokušaja biti 8 niti, 4 niti, 2 niti i jedna. Zatim će povući datoteku u jedan tok. Ako postoje neke magične vrijednosti poput 7,5 niti koje su najbolje za pumpanje, tada ćemo se zadržati na njima i pokušati napraviti još 7,5 niti. Evo jedne ideje.
Hvala na izvješću! Kako izgleda kompletan tijek rada za WAL-G? Na primjer, u glupom slučaju kada nema delte na stranicama. I mi uzmemo i uklonimo početni backup, pa arhiviramo šaht dok ne pomodrimo. Ovdje, koliko sam shvatio, postoji kvar. U nekom trenutku morate napraviti delta sigurnosnu kopiju stranica, tj. neki vanjski proces to pokreće ili kako se to događa?
Delta backup API je prilično jednostavan. Tamo postoji broj - maksimalni delta koraci, tako se to zove. Zadana je nula. To znači da svaki put kada napravite backup-push, preuzima se potpuna sigurnosna kopija. Ako ga promijenite u bilo koji pozitivni broj, na primjer, 3, sljedeći put kada napravite backup-push, pregledat će se povijest prethodnih sigurnosnih kopija. On pazi da ne prijeđete lanac od 3 delte i napravi deltu.
Odnosno, svaki put kada pokrenemo WAL-G, on pokušava napraviti punu sigurnosnu kopiju?
Ne, mi pokrećemo WAL-G i on pokušava napraviti deltu ako vaša pravila to dopuštaju.
Grubo govoreći, ako ga svaki put pokrenete s 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 imate konfigurirano arhiviranje. I izdat će upozorenje ako nije konfiguriran.
Pg_basebackup se može pokrenuti bez osovina.
Da, tada će se ponašati gotovo isto. Pg_basebackup kopira u datotečni sustav. Usput, imamo novu značajku koju sam zaboravio spomenuti. Sada možemo sigurnosno kopirati u datotečni sustav iz pg_basebackup. Ne znam zašto je ovo potrebno, ali postoji.
Na primjer, na CephFS. Ne želi svatko konfigurirati Object Storage.
Da, vjerojatno su zato postavili pitanje o ovoj značajci kako bismo mi to mogli učiniti. I uspjeli smo.
Hvala na izvješću! Postoji samo pitanje o kopiranju u datotečni sustav. Iz kutije, podržavate li sada kopiranje na udaljenu pohranu, npr. ako postoji neka polica u podatkovnom 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. To jest, sva izdanja prije izdanja to podržavaju, ali verzije izdanja ne. Ova je funkcionalnost dodana u verziji 0.2. Definitivno će uskoro biti objavljen, čim ispravimo sve poznate greške. Ali trenutno se to može učiniti samo u fazi prije izdavanja. Postoje dvije greške u pret-izdanju. Problem s oporavkom WAL-E, nismo ga riješili. A u najnovijem izdanju prije izdanja dodan je bug o delta-sigurnosnom kopiranju. Stoga svima preporučamo korištenje izdanih verzija. Čim više ne bude grešaka u predizdanju, možemo reći da podržavamo Google Cloud, stvari kompatibilne sa S3 i pohranu datoteka.
Pozdrav, hvala na izvješću. Koliko sam shvatio, WAL-G nije neka vrsta centraliziranog sustava poput barmena? Planirate li krenuti u ovom smjeru?
Problem je što smo se odmaknuli od ovog smjera. WAL-G živi na osnovnom hostu, na hostu klastera i na svim hostovima u klasteru. Kad smo se preselili u nekoliko tisuća klastera, imali smo mnogo instalacija barmena. I svaki put kad im se nešto raspadne, to je veliki problem. Budući da ih je potrebno popraviti, morate razumjeti koji klasteri sada nemaju sigurnosne kopije. Ne planiram razvijati WAL-G u smjeru fizičkog hardvera za backup sustave. Ako zajednica želi neku funkcionalnost ovdje, nemam ništa protiv.
Imamo timove koji su odgovorni za skladištenje. I osjećamo se tako dobro da to nismo mi, da postoje posebni ljudi koji stavljaju naše datoteke tamo gdje su datoteke sigurne. Tamo rade razne vrste pametnog kodiranja kako bi izdržali gubitak određenog broja datoteka. Oni su odgovorni za propusnost mreže. Kad imate barmena, možete iznenada saznati da su se male baze podataka s puno prometa okupile na istom poslužitelju. Čini se da imate puno prostora na njemu, ali iz nekog razloga sve ne stane kroz mrežu. Može ispasti i obrnuto. Tamo ima puno mreža, ima procesorskih jezgri, ali ovdje nema diskova. I umorili smo se od te potrebe da nečim žongliramo i prešli smo na činjenicu da je pohrana podataka zasebna usluga, za koju su odgovorni posebni ljudi.
PS Objavljena je nova verzija , u kojem možete koristiti konfiguracijsku datoteku .walg.json, koja se prema zadanim postavkama nalazi u postgresovom početnom direktoriju. Možete napustiti bash skripte. Primjer .walg.json je u ovom broju
Video:
Izvor: www.habr.com