Predlagam, da preberete prepis poročila Andreja Borodina z začetka leta 2019 "Varnostne kopije z WAL-G. Kaj je tam v 2019?"
Pozdravljeni vsi skupaj! Moje ime je Andrej Borodin. Sem razvijalec pri Yandexu. PostgreSQL me zanima od leta 2016, potem ko sem govoril z razvijalci in so rekli, da je vse preprosto - vzameš izvorno kodo in jo sestaviš, pa bo vse šlo. In od takrat ne morem nehati - pišem najrazličnejše stvari.
Ena od stvari, na kateri delam, je varnostni sistem. . Na splošno v Yandexu že zelo dolgo delamo na sistemih za varnostno kopiranje v PostgreSQL. In na internetu lahko najdete serijo šestih poročil o tem, kako izdelujemo varnostne sisteme. In vsako leto se malo razvijajo, malo razvijajo in postajajo bolj zanesljivi.
Toda današnje poročilo ne govori samo o tem, kaj smo storili, ampak tudi o tem, kako preprosto je in kaj je. Koliko vas je že gledalo moja poročila o WAL-G? Še dobro, da kar nekaj ljudi ni gledalo, ker bom začel z najenostavnejšim.
Če nenadoma imate gručo PostgreSQL in mislim, da jih ima vsak nekaj s seboj, in nenadoma še ni sistema za varnostno kopiranje, potem morate dobiti katero koli shrambo S3 ali shrambo, združljivo z Google Cloud.
Na primer, lahko pridete na našo stojnico in prevzamete promocijsko kodo za Yandex Object Storage, ki je združljiva s S3.
Nato ustvarite Bucket. To je le vsebnik za informacije.
Ustvari uporabnika storitve.
Ustvarite ključ za dostop za uporabnika storitve: aws-s3-key.
Prenesite najnovejšo stabilno izdajo WAL-G.
Kako se naše predizdaje razlikujejo od izdaj? Pogosto me prosijo, naj predčasno odpustim. In če v različici dovolj časa, na primer en mesec, ni napake, jo izdam. Tukaj je ta izdaja iz novembra. In to pomeni, da smo vsak mesec našli kakšno napako, običajno v nekritični funkcionalnosti, vendar še nismo izdali izdaje. Prejšnja različica je šele novembra. V njem ni nobenih nam znanih hroščev, tj. hrošči so bili dodani med napredovanjem projekta.
Ko prenesete WAL-G, lahko zaženete preprost ukaz »seznam varnostnih kopij« in posredujete spremenljivke okolja. In povezal se bo z Object Storage in vam povedal, katere varnostne kopije imate. Sprva seveda ne bi smeli imeti varnostnih kopij. Bistvo tega diapozitiva je pokazati, da je vse zelo preprosto. To je ukaz konzole, ki sprejema spremenljivke okolja in izvaja podukaze.
Po tem lahko naredite prvo varnostno kopijo. V WAL-G izgovorite »backup-push« in v WAL-G določite lokacijo pgdata vaše gruče. Najverjetneje vam bo PostgreSQL povedal, če še nimate sistema za varnostno kopiranje, da morate omogočiti "arhivski način".
To pomeni, da morate iti v nastavitve in vklopiti »archive_mode = on« ter dodati »archive_command«, ki je tudi podukaz v WAL-G. Toda iz nekega razloga ljudje pogosto uporabljajo vrstične skripte na to temo in jih ovijajo okoli WAL-G. Prosim, ne počni tega. Uporabite funkcionalnost, ki jo najdete v WAL-G. Če vam kaj manjka, pišite na . WAL-G predvideva, da je to edini program, ki se izvaja v archive_command.
WAL-G uporabljamo predvsem za ustvarjanje gruče visoke razpoložljivosti v upravljanju zbirke podatkov Yandex.
Običajno se uporablja v topologiji enega masterja in več replikacij. Hkrati naredi varnostno kopijo v Yandex Object Storage.
Najpogostejši scenariji so ustvarjanje kopij gruče z uporabo obnovitve točke v času. Toda v tem primeru nam zmogljivost varnostnega sistema ni tako pomembna. Samo naložiti moramo novo gručo iz varnostne kopije.
Običajno potrebujemo rezervno zmogljivost sistema, ko dodajamo novo vozlišče. Zakaj je pomembno? Običajno ljudje dodajo novo vozlišče v gručo, ker obstoječa gruča ne prenese bremena branja. Dodati morajo novo repliko. Če na Master dodamo obremenitev iz pg_basebackup, se Master lahko zruši. Zato je bilo za nas zelo pomembno, da smo lahko hitro naložili novo vozlišče iz arhiva, kar je minimalno obremenilo Master.
In še ena podobna situacija. To je potreba po ponovnem zagonu starega Master-a po preklopu Cluster Master-a iz podatkovnega centra, s katerim je bila povezljivost izgubljena.
- Posledično smo pri oblikovanju zahtev za kopirni sistem ugotovili, da pg_basebackup ni primeren za nas pri delovanju v oblaku.
- Želeli smo imeti možnost stiskanja naših podatkov. Toda skoraj vsak sistem za varnostno kopiranje, razen tistega, ki je priložen, bo zagotovil stiskanje podatkov.
- Vse smo želeli vzporediti, ker uporabnik v oblaku kupi veliko število procesorskih jeder. Če pa v neki operaciji nimamo vzporednosti, potem veliko število jeder postane neuporabno.
- Potrebujemo šifriranje, ker podatki pogosto niso naši in jih ni mogoče shraniti v čistem besedilu. Mimogrede, naš prispevek k WAL-G se je začel s šifriranjem. Zaključili smo šifriranje v WAL-G, nakar so nas vprašali: "Mogoče bo kdo od nas razvil projekt?" In od takrat že več kot eno leto delam z WAL-G.
- Potrebovali smo tudi dušenje virov, saj smo sčasoma z uporabo oblaka ugotovili, da imajo ljudje včasih ponoči pomembno nakupovanje živil in v to obremenitev ni mogoče posegati. Zato smo dodali omejevanje virov.
- Kot tudi kotacija in upravljanje.
- In preverjanje.
Ogledali smo si veliko različnih orodij. Na srečo imamo v PostgreSQL veliko izbiro. In povsod nam je nekaj manjkalo, nekomu ena majhna funkcija, nekomu ena malenkost.
In po pregledu obstoječih sistemov smo prišli do zaključka, da bomo razvili WAL-G. Takrat je bil nov projekt. Preprosto je bilo vplivati na razvoj oblačne infrastrukture varnostnega sistema.
Glavna ideologija, ki se je držimo, je, da mora biti WAL-G preprost kot balalajka.
WAL-G ima 4 ukaze. to:
WAL-PUSH – arhiviranje jaška.
WAL-FETCH – dobite gred.
BACKUP-PUSH – narediti varnostno kopijo.
BACKUP-FETCH – pridobite varnostno kopijo iz varnostnega sistema.
Pravzaprav ima WAL-G tudi upravljanje teh varnostnih kopij, to je seznam in brisanje zapisov in varnostnih kopij v zgodovini, ki trenutno niso več potrebni.
Ena od pomembnih funkcij za nas je funkcija ustvarjanja delta kopij.
Delta kopije pomenijo, da ne izdelamo popolne varnostne kopije celotne gruče, temveč samo spremenjene strani spremenjenih datotek v gruči. Zdi se, da je funkcionalno to zelo podobno zmožnosti obnovitve z WAL. Vendar pa lahko vzporedno zvijemo varnostno kopijo WAL z eno nitjo delta. V skladu s tem, ko imamo osnovno varnostno kopijo narejeno v soboto, delta varnostne kopije dnevno, in v četrtek nam ne uspe, potem moramo naviti 4 delta varnostne kopije in 10 ur WAL. Trajalo bo približno enako časa, ker se delta varnostne kopije izvajajo vzporedno.
Delte, ki temeljijo na LSN - to pomeni, da bomo morali pri ustvarjanju varnostne kopije združiti vsako stran in preveriti njen LSN z LSN prejšnje varnostne kopije, da bomo razumeli, da se je spremenila. Vsaka stran, ki bi lahko vsebovala spremenjene podatke, mora biti prisotna v delta varnostni kopiji.
Kot sem rekel, je bilo vzporednosti namenjene precej pozornosti.
Toda arhivski API v PostgreSQL je dosleden. PostgreSQL arhivira eno datoteko WAL in pri obnovitvi zahteva eno datoteko WAL. Toda ko zbirka podatkov zahteva eno datoteko WAL z ukazom "WAL-FETCH", pokličemo ukaz "WAL-PREFETCH", ki pripravi naslednjih 8 datotek za vzporedno pridobivanje podatkov iz shrambe objektov.
In ko nas baza podatkov prosi, da arhiviramo eno datoteko, pogledamo archive_status in preverimo, ali obstajajo druge datoteke WAL. In vzporedno poskušamo prenesti tudi WAL. To zagotavlja znatno povečanje zmogljivosti in znatno zmanjša razdaljo v številu nearhiviranih WAL. Številni razvijalci sistemov za varnostno kopiranje menijo, da je to tako tvegan sistem, ker se zanašamo na svoje znanje o notranjosti kode, ki ni API PostgreSQL. PostgreSQL nam ne zagotavlja prisotnosti mape archive_status in ne jamči semantike, prisotnosti signalov pripravljenosti za datoteke WAL tam. Kljub temu proučujemo izvorno kodo, vidimo, da je temu tako in jo poskušamo izkoristiti. In nadzorujemo smer, v kateri se razvija PostgreSQL; če se ta mehanizem nenadoma pokvari, ga bomo prenehali uporabljati.
V svoji čisti obliki delta WAL, ki temelji na LSN, zahteva branje katere koli datoteke gruče, katere čas načina v datotečnem sistemu se je spremenil od prejšnje varnostne kopije. S tem smo živeli dolgo, skoraj eno leto. In na koncu smo prišli do zaključka, da imamo delte WAL.
To pomeni, da vsakič, ko arhiviramo WAL na Master, ga ne samo stisnemo, šifriramo in pošljemo v omrežje, ampak ga hkrati tudi preberemo. Analiziramo in beremo zapise v njej. Razumemo, kateri bloki so se spremenili, in zbiramo delta datoteke.
Datoteka delta opisuje določen obseg datotek WAL, opisuje informacije o tem, kateri bloki so bili spremenjeni v tem obsegu WAL. In potem se te delta datoteke tudi arhivirajo.
Tu se soočimo s tem, da smo vse vzporedili precej hitro, ne moremo pa vzporedno brati sekvenčne zgodovine, saj lahko v določenem segmentu naletimo na konec prejšnjega zapisa WAL, s katerim še nimamo kaj povezati, ker vzporedno branje je privedlo do tega, da najprej analiziramo prihodnost, ki še nima preteklosti.
Posledično smo morali nerazumljive dele vstaviti v _delta_partial datoteke. Kot rezultat, ko se vrnemo v preteklost, bomo koščke zapisa WAL zlepili v enega, nato ga bomo razčlenili in razumeli, kaj se je v njem spremenilo.
Če v zgodovini našega razčlenjevanja gredi obstaja vsaj ena točka, kjer ne razumemo, kaj se je dogajalo, potem bomo v skladu s tem med naslednjim varnostnim kopiranjem prisiljeni ponovno prebrati celotno gručo, tako kot smo storili z običajnim LSN delta na osnovi.
Posledično je vse naše trpljenje vodilo k dejstvu, da smo odprli knjižnico za razčlenjevanje WAL-G. Kolikor vem ga še nihče ne uporablja, če pa kdo želi naj napiše in uporabi, je v javni domeni. (Posodobljena povezava )
Posledično so vsi informacijski tokovi videti precej zapleteni. Naš Mojster arhivira shaft in arhivira delta datoteke. In replika, ki naredi varnostno kopijo, mora prejeti delta datoteke v času, ki je pretekel med varnostnimi kopijami. V tem primeru bo treba dele zgodovine dodati v velikem obsegu in razčleniti, ker se celotna zgodovina ne prilega velikim segmentom. In šele po tem lahko replika arhivira celotno delta varnostno kopijo.
Na grafih je vse videti veliko bolj preprosto. To je prenos iz enega od naših resničnih grozdov. Imamo na osnovi LSN, narejeno v enem dnevu. In vidimo, da je delta varnostno kopiranje na osnovi LSN delovalo od treh zjutraj do petih zjutraj. To je obremenitev v številu procesorskih jeder. WAL-delta nam je tukaj vzela približno 20 minut, torej je postala bistveno hitrejša, hkrati pa je prišlo do intenzivnejše izmenjave po omrežju.
Ker imamo informacije o tem, kateri bloki so se spremenili in kdaj v zgodovini baze podatkov, smo šli dlje in se odločili integrirati funkcionalnost - razširitev PostgreSQL, imenovano “pg_prefaulter”
To pomeni, da ko baza v pripravljenosti izvede ukaz za obnovitev, sporoči WAL-G, naj pridobi naslednjo datoteko WAL. Približno razumemo, do katerih podatkovnih blokov bo proces obnovitve WAL dostopal v bližnji prihodnosti, in sprožimo operacijo branja teh blokov. To je bilo storjeno, da bi povečali zmogljivost krmilnikov SSD. Ker bo zvitek WAL dosegel stran, ki jo je treba spremeniti. Ta stran je na disku in ni v predpomnilniku strani. In hkrati bo čakal, da pride ta stran. A v bližini je WAL-G, ki ve, da bomo v naslednjih nekaj sto megabajtih WAL-a potrebovali določene strani in jih hkrati začne segrevati. Sproži več dostopov do diska, tako da se izvajajo vzporedno. To dobro deluje na SSD diskih, žal pa nikakor ni uporabno za trdi disk, saj vanj le posegamo z našimi pozivi.
To je zdaj v kodi.
Obstajajo funkcije, ki bi jih radi dodali.
Ta slika prikazuje, da WAL-delta traja relativno kratek čas. In to je branje sprememb, ki so se čez dan zgodile v bazi podatkov. WAL-delta bi lahko delali ne samo ponoči, ker ni več pomemben vir obremenitve. WAL-delta lahko beremo vsako minuto, ker je poceni. V eni minuti lahko pregledamo vse spremembe, ki so se zgodile v gruči. In temu bi lahko rekli "takojšnja WAL-delta".
Bistvo je, da ko obnovimo gručo, zmanjšamo število zgodb, ki jih moramo zaporedno zviti. To pomeni, da je treba količino WAL, ki jo zvije PostgreSQL, zmanjšati, ker vzame veliko časa.
A to še ni vse. Če vemo, da bo nek blok spremenjen do stopnje skladnosti varnostne kopije, ga ne moremo spremeniti v preteklosti. Se pravi, zdaj imamo optimizacijo posredovanja WAL-delta od datoteke do datoteke. To pomeni, da če je bila na primer v torek tabela v celoti izbrisana ali so bile nekatere datoteke v celoti izbrisane iz tabele, potem ko se delta prevrne v ponedeljek in se obnovi pg_basebackup v soboto, teh podatkov sploh ne bomo ustvarili.
To tehnologijo želimo razširiti na raven strani. To pomeni, da če se del datoteke spremeni v ponedeljek, vendar bo prepisan v sredo, nam pri obnavljanju na točko v četrtek ni treba zapisati prvih nekaj različic strani na disk.
A to je še vedno ideja, o kateri se pri nas aktivno razpravlja, a še ni prišla do kode.
V WAL-G želimo narediti še eno funkcijo. Želimo ga narediti razširljivega, ker moramo podpirati različne baze podatkov in bi radi imeli enak pristop k upravljanju varnostnih kopij. Toda težava je v tem, da so API-ji MySQL radikalno drugačni. V MySQL PITR ne temelji na fizičnem dnevniku WAL, temveč na binlogu. In v MySQL nimamo sistema za arhiviranje, ki bi nekemu zunanjemu sistemu povedal, da je ta binlog končan in ga je treba arhivirati. Moramo stati nekje v cronu z bazo podatkov in preveriti, ali je kaj pripravljenega?
In na enak način med obnovitvijo MySQL ni ukaza za obnovitev, ki bi lahko sistemu povedal, da potrebujem takšne in drugačne datoteke. Preden začnete obnavljati svojo gručo, morate vedeti, katere datoteke boste potrebovali. Sami morate uganiti, katere datoteke boste potrebovali. Toda tem težavam bi se morda dalo nekako zaobiti. (Pojasnilo: MySQL je že podprt)
V poročilu sem želel govoriti tudi o tistih primerih, ko WAL-G za vas ni primeren.
Če nimate sinhrone replike, WAL-G ne jamči, da bo ohranjen zadnji segment. In če arhiviranje zaostaja za zadnjimi segmenti zgodovine, je to tveganje. Če ni sinhrone replike, ne priporočam uporabe WAL-G. Kljub temu je zasnovan predvsem za namestitev v oblaku, kar pomeni rešitev visoke razpoložljivosti s sinhrono repliko, ki skrbi za varnost zadnjih predanih bajtov.
Pogosto vidim ljudi, ki poskušajo zagnati WAL-G in WAL-E hkrati. Podpiramo združljivost za nazaj v smislu, da lahko WAL-G obnovi datoteko iz WAL-E in lahko obnovi varnostno kopijo, narejeno v WAL-E. Ker pa oba sistema uporabljata vzporedni wal-push, začneta drug drugemu krasti datoteke. Če ga popravimo v WAL-G, bo še vedno ostal v WAL-E. V WAL-E pogleda status arhiva, vidi končane datoteke in jih arhivira, medtem ko drugi sistemi preprosto ne bodo vedeli, da je ta datoteka WAL obstajala, ker je PostgreSQL ne bo poskušal drugič arhivirati.
Kaj bomo popravili tukaj na strani WAL-G? PostgreSQL ne bomo obvestili, da je bila ta datoteka prenesena vzporedno, in ko nas bo PostgreSQL prosil, da jo arhiviramo, bomo že vedeli, da je bila taka datoteka s tem načinom-časom in s tem md5 že arhivirana in bomo preprosto rekli PostgreSQL - V redu, vse je pripravljeno, ne da bi v bistvu karkoli naredili.
Vendar je malo verjetno, da bo ta težava odpravljena na strani WAL-E, zato trenutno ni mogoče ustvariti ukaza za arhiviranje, ki bo arhiviral datoteko tako v WAL-G kot WAL-E.
Poleg tega obstajajo primeri, ko WAL-G zdaj ni primeren za vas, vendar bomo to zagotovo popravili.
Prvič, trenutno nimamo vgrajenega varnostnega preverjanja. Niti med varnostnim kopiranjem niti med obnovitvijo nimamo preverjanja. Seveda je to implementirano v oblaku. Toda to se izvede preprosto s predhodnim preverjanjem, preprosto z obnovitvijo gruče. To funkcionalnost bi rad dal uporabnikom. Toda glede na preverjanje predvidevam, da bo v WAL-G možno obnoviti gručo in jo zagnati ter zagnati dimne teste: pg_dumpall v /dev/null in preverjanje indeksa amcheck.
Trenutno v WAL-G ni mogoče odložiti ene varnostne kopije iz WAL. To pomeni, da podpiramo neko okno. Na primer, shranjevanje zadnjih sedmih dni, shranjevanje zadnjih desetih varnostnih kopij, shranjevanje zadnjih treh polnih varnostnih kopij. Pogosto ljudje pridejo in rečejo: "Potrebujemo varnostno kopijo tega, kar se je zgodilo za novo leto, in to želimo ohraniti za vedno." WAL-G še ne ve, kako to narediti. (Opomba – To je že popravljeno. Preberite več – Možnost varnostne oznake v )
Pri preverjanju PITR nimamo kontrolnih vsot strani in preverjanj celovitosti za vse segmente gredi.
Iz vsega tega sem sestavil projekt za Google Summer of Code. Če poznate pametne študente, ki bi radi nekaj napisali v Go in dobili več tisoč dolarjev od enega podjetja na črko G, potem jim priporočite naš projekt. Pri tem projektu bom deloval kot mentor, oni to zmorejo. Če ne bo študentov, bom poleti vzel in naredil sam.
In imamo veliko drugih majhnih težav, ki jih postopoma rešujemo. In dogajajo se precej nenavadne stvari.
Na primer, če WAL-G daste prazno varnostno kopijo, bo preprosto padla. Na primer, če mu poveste, da mora varnostno kopirati prazno mapo. Datoteke pg_control ne bo tam. In mislil bo, da nečesa ne razume. Teoretično morate v tem primeru uporabniku napisati običajno sporočilo, da mu razložite, kako uporabljati orodje. A to niti ni lastnost programiranja, ampak lastnost dobrega, razumljivega jezika.
Ne vemo, kako narediti varnostno kopijo brez povezave. Če baza podatkov laže, je ne moremo varnostno kopirati. Toda tukaj je vse zelo preprosto. Pokličemo varnostne kopije z LSN, ko se je začelo. LSN osnovne baze je treba prebrati iz nadzorne datoteke. In to je tako nerealizirana funkcija. Mnogi sistemi za varnostno kopiranje lahko varnostno kopirajo osnovno bazo podatkov. In to je priročno.
Trenutno ne moremo pravilno obravnavati pomanjkanja prostora za varnostno kopiranje. Ker običajno delamo z velikimi varnostnimi kopijami doma. In niso prišli do tega. Če pa želi nekdo zdaj programirati v Go, v vedro dodajte obravnavo napak zaradi pomanjkanja prostora. Vsekakor bom preučil zahtevo za poteg.
In glavna stvar, ki nas skrbi, je, da želimo čim več docker integracijskih testov, ki preverjajo različne scenarije. Trenutno preizkušamo samo osnovne scenarije. Pri vsaki objavi, vendar želimo preveriti vse funkcije, ki jih podpiramo, od objave do objave. Zlasti bomo na primer imeli dovolj podpore za PostgreSQL 9.4-9.5. Podpiramo jih, ker skupnost podpira PostgreSQL, vendar ne preverjamo posamezne objave, da bi se prepričali, da ni vse pokvarjeno. In zdi se mi, da je to precej resno tveganje.
WAL-G deluje v več kot tisoč gručih v upravljanju zbirke podatkov Yandex. In vsak dan varnostno kopira več sto terabajtov podatkov.
V naši kodi imamo veliko TODO. Če želite programirati, pridite, čakamo na vlečne zahteve, čakamo na vprašanja.
vprašanja
Dober večer! Hvala vam! Predvidevam, da če uporabljate WAL-delta, se verjetno močno zanašate na celostransko pisanje. In če je tako, ste opravili teste? Krasen graf si pokazal. Koliko lepše postane, če FPW izklopimo?
Celostransko pisanje je pri nas omogočeno, nismo ga poskušali onemogočiti. To pomeni, da ga kot razvijalec nisem poskušal izklopiti. Sistemski skrbniki, ki so raziskovali, so verjetno raziskovali to težavo. Ampak potrebujemo FPW. Skoraj nihče ga ne onemogoči, ker drugače ni mogoče narediti varnostne kopije iz replike.
Hvala za poročilo! Imam dve vprašanji. Prvo vprašanje je, kaj se bo zgodilo s prostori tabel?
Čakamo na zahtevo za vleko. Naše zbirke podatkov živijo na diskih SSD in NMVE in te funkcije pravzaprav ne potrebujemo. Trenutno nisem pripravljen porabiti veliko časa za to, da bi to naredil dobro. Z vsem srcem se zavzemam, da to podpremo. So ljudje, ki so to podprli, a podprli tako, kot jim ustreza. Naredili so fork, vendar ne postavljajo zahtev za vlečenje. (Dodano v različici 0.2.13)
In drugo vprašanje. Na samem začetku ste rekli, da WAL-G predvideva, da deluje sam in da niso potrebni nobeni ovoji. Sama uporabljam ovoje. Zakaj jih ne bi smeli uporabljati?
Želimo, da je preprosto kot balalajka. To pomeni, da ne potrebujete ničesar razen balalajke. Želimo, da je sistem enostaven. Če imate funkcionalnost, ki jo morate narediti v skriptu, nam pridite in nam povejte - naredili bomo to v Go.
Dober večer! Hvala za poročilo! WAL-G nam ni uspelo omogočiti delovanja z dešifriranjem GPG. Šifrira normalno, noče pa dešifrirati. Je to nekaj, kar nam ni uspelo? Stanje je depresivno.
Ustvarite težavo na GitHubu in jo poglejmo.
Se pravi, s tem se še niste srečali?
Obstaja značilnost poročila o napaki, da ko WAL-G ne razume, za kakšno datoteko gre, vpraša: "Mogoče je šifrirana?" Morda težava sploh ni v šifriranju. Želim izboljšati beleženje te teme. Mora ga dešifrirati. Trenutno delamo na tej temi v smislu, da nam ni najbolj všeč, kako je organiziran sistem pridobivanja javnih in zasebnih ključev. Ker pokličemo zunanji GPG, da nam da svoje ključe. In potem vzamemo te ključe in jih prenesemo v notranji GPG, ki je odprt PGP, ki je za nas sestavljen znotraj WAL-G, in tam imenujemo šifriranje. V zvezi s tem želimo izboljšati sistem in želimo podpreti šifriranje Libsodium (Dodano v različici 0.2.15). Seveda bi moralo dekodiranje delovati, ugotovimo - potrebujete več simptoma kot nekaj besed. Lahko se kdaj zberete v govorniški sobi in pogledate sistem. (PGP šifriranje brez zunanjega GPG - v0.2.9)
Zdravo! Hvala za poročilo! Imam dve vprašanji. Imam čudno željo narediti pg_basebackup in WAL log pri dveh ponudnikih, torej želim narediti en oblak in drugega. Ali obstaja kakšen način za to?
To zdaj ne obstaja, je pa zanimiva ideja.
Samo enemu ponudniku ne zaupam, za vsak slučaj želim imeti isto pri drugem.
Ideja je zanimiva. Tehnično tega sploh ni težko izvesti. Da preprečim, da bi se ideja izgubila, vas lahko prosim, da objavite izdajo na GitHubu?
Ja, seveda.
In potem, ko bodo študenti prišli na Google Summer of Code, jih bomo dodali k projektu, tako da bo več dela, da bomo iz njih izkoristili več.
In drugo vprašanje. Na GitHubu je težava. Mislim, da je že zaprto. Med obnovitvijo je panika. In da bi ga premagali, ste naredili ločen sklop. V zadevah je prav. In obstaja možnost, da naredite spremenljivo okolje v eni niti. In zato deluje zelo počasi. In naleteli smo na to težavo, ki še ni bila odpravljena.
Težava je v tem, da iz nekega razloga shramba (CEPH) ponastavi povezavo, ko pridemo do nje z visoko sočasnostjo. Kaj se lahko glede tega naredi? Logika ponovnega poskusa izgleda takole. Ponovno poskušamo prenesti datoteko. V enem prehodu nam ni bilo naloženih kar nekaj datotek, naredili bomo drugega za vse tiste, ki se niso prijavili. In dokler se na iteracijo naloži vsaj ena datoteka, ponavljamo in ponavljamo in ponavljamo. Izboljšali smo logiko ponovnega poskusa - eksponentni odmik. Vendar ni povsem jasno, kaj storiti z dejstvom, da se povezava preprosto prekine na strani sistema za shranjevanje. Se pravi, ko naložimo v en tok, ne prekine teh povezav. Kaj lahko tukaj izboljšamo? Imamo dušenje omrežja, vsako povezavo lahko omejimo s številom bajtov, ki jih pošlje. Sicer pa ne vem, kako naj se spoprimem s tem, da objektni shramba ne omogoča vzporednega prenosa oz.
Brez SLA? Ali jim ni pisano, kako se pustijo mučiti?
Bistvo je, da imajo ljudje, ki pridejo s tem vprašanjem, običajno svoj trezor. To pomeni, da nihče ne prihaja iz Amazona ali Google Clouda ali Yandex Object Storage.
Morda vprašanje ni več za vas?
Vprašanje tukaj v tem primeru ni pomembno komu. Če obstajajo ideje, kako se tega lotiti, naredimo to v WAL-G. Ampak zaenkrat nimam dobrih idej, kako se tega lotiti. Obstaja nekaj Object Storage, ki podpirajo drugačen seznam varnostnih kopij. Prosite jih, naj navedejo predmete, in tja dodajo mapo. WAL-G se tega prestraši - tukaj je neka stvar, ki ni datoteka, je ne morem obnoviti, kar pomeni, da varnostna kopija ni bila obnovljena. To pomeni, da imate dejansko popolnoma obnovljeno gručo, vendar vam vrne napačen status, ker je Object Storage vrnil nekaj nenavadnih informacij, ki jih ni popolnoma razumel.
To se zgodi v poštnem oblaku.
Če lahko ustvarite reprodukcijo ...
Je dosledno reproducirano ...
Če pride do reprodukcije, mislim, da bomo poskusili s strategijami ponovnega poskusa in ugotovili, kako znova poskusiti ter razumeli, kaj oblak zahteva od nas. Mogoče nam bo na treh povezavah stabilen in ne bo prekinil povezave, potem bomo previdno dosegli tri. Ker zdaj zelo hitro prekinemo povezavo, tj. če smo zagnali obnovitev s 16 nitmi, bo po prvem ponovnem poskusu 8 niti, 4 niti, 2 niti in ena. In potem bo datoteko potegnil v en tok. Če obstaja nekaj čarobnih vrednosti, kot je 7,5 niti, ki so najboljše za črpanje, se bomo o njih zadržali in poskusili narediti še 7,5 niti. Tukaj je ideja.
Hvala za poročilo! Kako izgleda celoten potek dela za delo z WAL-G? Na primer v neumnem primeru, ko na straneh ni delte. In vzamemo in odstranimo začetno varnostno kopijo, nato arhiviramo jašek, dokler ne pomodrimo. Tukaj, kot razumem, pride do okvare. Na neki točki morate narediti delta varnostno kopijo strani, tj. to poganja nek zunanji proces ali kako se to zgodi?
API za varnostno kopiranje delta je precej preprost. Tam je številka – največji delta koraki, tako se imenuje. Privzeto je nič. To pomeni, da vsakič, ko naredite backup-push, prenese celotno varnostno kopijo. Če ga spremenite v katero koli pozitivno število, na primer 3, potem naslednjič, ko izvedete varnostno kopiranje, pogleda zgodovino prejšnjih varnostnih kopiranj. On vidi, da ne presežete verige 3 delt in naredi delto.
To pomeni, da vsakič, ko zaženemo WAL-G, poskuša narediti popolno varnostno kopijo?
Ne, izvajamo WAL-G in poskuša narediti delto, če to dopuščajo vaši pravilniki.
Grobo rečeno, če ga vsakič zaženete z ničlo, ali se bo obnašal kot pg_basebackup?
Ne, še vedno bo deloval hitreje, ker uporablja stiskanje in vzporednost. Pg_basebackup bo postavil gred poleg vas. WAL-G predvideva, da imate konfigurirano arhiviranje. In izdal bo opozorilo, če ni konfiguriran.
Pg_basebackup je mogoče izvajati brez gredi.
Da, potem se bodo obnašali skoraj enako. Pg_basebackup kopira v datotečni sistem. Mimogrede, imamo novo funkcijo, ki sem jo pozabil omeniti. Zdaj lahko varnostno kopiramo v datotečni sistem iz pg_basebackup. Ne vem, zakaj je to potrebno, vendar je tam.
Na primer na CephFS. Vsi ne želijo konfigurirati Object Storage.
Da, verjetno so zato postavili vprašanje o tej funkciji, da bi to lahko storili. In uspelo nam je.
Hvala za poročilo! Obstaja samo vprašanje o kopiranju v datotečni sistem. Izven škatle, ali zdaj podpirate kopiranje v oddaljeno shrambo, če je na primer kakšna polica v podatkovnem centru ali kaj drugega?
V tej formulaciji je to težko vprašanje. Da, podpiramo, vendar ta funkcionalnost še ni vključena v nobeno izdajo. To pomeni, da vse predizdaje to podpirajo, izdajne različice pa ne. Ta funkcionalnost je bila dodana v različici 0.2. Zagotovo bo izdan kmalu, takoj ko bomo odpravili vse znane napake. Toda trenutno je to mogoče storiti samo v predizdaji. V predizdaji sta dve napaki. Težava z obnovitvijo WAL-E, nismo je odpravili. In v najnovejši predizdaji je bila dodana napaka glede varnostnega kopiranja delta. Zato vsem priporočamo uporabo izdanih različic. Takoj ko v predizdaji ne bo več napak, lahko rečemo, da podpiramo Google Cloud, stvari, združljive s S3, in shranjevanje datotek.
Pozdravljeni, hvala za poročilo. Kolikor razumem, WAL-G ni nekakšen centraliziran sistem, kot so natakarji? Se nameravate premakniti v to smer?
Problem je, da smo se oddaljili od te smeri. WAL-G živi na osnovnem gostitelju, na gostitelju gruče in na vseh gostiteljih v gruči. Ko smo se preselili v več tisoč grozdov, smo imeli veliko namestitev barmanov. In vsakič, ko se jim kaj podre, je to velik problem. Ker jih je treba popraviti, morate razumeti, kateri grozdi zdaj nimajo varnostnih kopij. WAL-G ne nameravam razvijati v smeri fizične strojne opreme za rezervne sisteme. Če skupnost želi nekaj funkcionalnosti tukaj, me sploh ne moti.
Imamo ekipe, ki so odgovorne za skladiščenje. In počutimo se tako dobro, da nismo mi, da obstajajo posebni ljudje, ki naše datoteke hranijo tam, kjer so datoteke na varnem. Tam izvajajo vse vrste pametnega kodiranja, da prenesejo izgubo določenega števila datotek. Odgovorni so za pasovno širino omrežja. Ko imate natakarja, lahko nenadoma ugotovite, da so se na istem strežniku zbrale majhne baze podatkov z veliko prometa. Zdi se, da imate na njem veliko prostora, vendar iz neznanega razloga vse ne ustreza prek omrežja. Lahko se izkaže obratno. Tam je veliko omrežij, so procesorska jedra, tukaj pa ni diskov. In smo se naveličali te potrebe po žongliranju in smo prešli na dejstvo, da je shranjevanje podatkov ločena storitev, za katero so odgovorni posebni ljudje.
PS Izšla je nova različica , v katerem lahko uporabite konfiguracijsko datoteko .walg.json, ki se privzeto nahaja v domačem imeniku postgres. Skripte bash lahko opustite. Primer .walg.json je v tej številki
Video:
Vir: www.habr.com