Soovitan teil lugeda Andrei Borodini 2019. aasta alguse raporti "Varukoopiad WAL-G-ga. Mis on 2019. aastal?"
Tere kõigile! Minu nimi on Andrei Borodin. Olen Yandexi arendaja. Olen PostgreSQL-i vastu huvi tundnud alates 2016. aastast, pärast seda, kui rääkisin arendajatega ja nad ütlesid, et kõik on lihtne – võtad lähtekoodi ja koostad selle ning kõik läheb korda. Ja sellest ajast peale ei saa ma peatuda – kirjutan igasuguseid erinevaid asju.
Üks asi, mille kallal ma töötan, on varusüsteem. . Üldiselt oleme Yandexis PostgreSQL-i varundussüsteemide kallal töötanud väga pikka aega. Ja Internetist leiate kuuest aruandest koosneva seeria selle kohta, kuidas me varusüsteeme valmistame. Ja igal aastal nad arenevad veidi, arenevad veidi ja muutuvad usaldusväärsemaks.
Kuid täna ei käsitle raport mitte ainult seda, mida oleme teinud, vaid ka seda, kui lihtne see on ja mis on. Kui paljud teist on juba vaadanud minu aruandeid WAL-G kohta? Hea, et päris paljud ei vaadanud, sest alustan kõige lihtsamast.
Kui teil on ootamatult PostgreSQL-klaster ja ma arvan, et kõigil on neid paar kaasas ja äkki pole veel varusüsteemi, peate hankima S3-mäluseadme või Google Cloudiga ühilduva salvestusruumi.
Näiteks võite tulla meie stendile ja võtta S3-ga ühilduva Yandex Object Storage sooduskoodi.
Seejärel looge ämber. See on lihtsalt teabemahuti.
Looge teenuse kasutaja.
Looge teenuse kasutajale juurdepääsuvõti: aws-s3-key.
Laadige alla WAL-G uusim stabiilne väljalase.
Mille poolest erinevad meie eelväljaanded väljalasetest? Mind palutakse sageli ennetähtaegselt vabastada. Ja kui versioonis pole viga piisavalt kaua, näiteks kuu aega, siis annan selle välja. Siin on see novembrikuu väljaanne. Ja see tähendab, et iga kuu avastasime mingi vea, tavaliselt mittekriitilistes funktsioonides, kuid me pole veel väljaannet välja andnud. Eelmine versioon on alles novembris. Meile teadaolevaid vigu selles pole, st vigu lisandus projekti edenedes.
Kui olete WAL-G alla laadinud, saate käivitada lihtsa "varukoopialoendi" käsu, edastades keskkonnamuutujad. Ja see loob ühenduse objektisalvestusega ja ütleb teile, millised varukoopiad teil on. Alguses ei tohiks teil muidugi varukoopiaid olla. Selle slaidi eesmärk on näidata, et kõik on üsna lihtne. See on konsoolikäsk, mis aktsepteerib keskkonnamuutujaid ja täidab alamkäske.
Pärast seda saate teha oma esimese varukoopia. Öelge WAL-G-s "backup-push" ja määrake WAL-G-s oma klastri pgdata asukoht. Ja tõenäoliselt ütleb PostgreSQL teile, kui teil pole veel varusüsteemi, et peate lubama "archive-mode".
See tähendab, et peate minema seadete juurde ja lülitama sisse "archive_mode = on" ja lisama "archive_command", mis on ka WAL-G alamkäsk. Kuid millegipärast kasutavad inimesed sellel teemal sageli ribaskripte ja mähivad selle ümber WAL-G. Palun ära tee seda. Kasutage WAL-G-s leiduvaid funktsioone. Kui sul on midagi puudu, kirjuta . WAL-G eeldab, et see on ainus programm, mis töötab failis archive_command.
Kasutame WAL-G-d peamiselt kõrge saadavuse klastri loomiseks Yandexi andmebaasihalduses.
Ja seda kasutatakse tavaliselt ühe Masteri ja mitme replikatsiooni topoloogias. Samal ajal teeb see Yandex Object Storage'is varukoopia.
Kõige levinumad stsenaariumid on klastri koopiate loomine ajakohase taastamise abil. Kuid sel juhul pole varusüsteemi jõudlus meie jaoks nii oluline. Peame lihtsalt varukoopiast üles laadima uue klastri.
Tavaliselt vajame uue sõlme lisamisel varusüsteemi jõudlust. Miks see oluline on? Tavaliselt lisavad inimesed klastrisse uue sõlme, kuna olemasolev klaster ei saa lugemiskoormusega hakkama. Nad peavad lisama uue koopia. Kui lisame pg_basebackupi koormuse põhiseadmele, võib Master kokku kukkuda. Seetõttu oli meie jaoks väga oluline, et saaksime kiiresti arhiivist uue sõlme üles laadida, tekitades Masterile minimaalse koormuse.
Ja veel üks sarnane olukord. See on vajadus vana Masteri taaskäivitamiseks pärast klastri juhtseadme vahetamist andmekeskusest, millega ühendus katkes.
- Sellest tulenevalt saime koopiasüsteemile nõuete sõnastamisel aru, et pg_basebackup meile pilves tegutsedes ei sobi.
- Tahtsime oma andmeid tihendada. Kuid peaaegu iga varundussüsteem, välja arvatud karbis sisalduv, pakub andmete tihendamist.
- Tahtsime kõike paralleelida, sest pilves olev kasutaja ostab suure hulga protsessorituumasid. Aga kui meil pole mõnes operatsioonis paralleelsust, muutub suur hulk südamikke kasutuks.
- Me vajame krüptimist, sest sageli pole andmed meie omad ja neid ei saa selgetekstiks salvestada. Muide, meie panus WAL-G-sse sai alguse krüpteerimisest. Lõpetasime krüptimise WAL-G-s, misjärel küsiti meilt: "Võib-olla arendab keegi meist projekti?" Ja sellest ajast alates olen WAL-G-ga töötanud rohkem kui aasta.
- Vajasime ka ressursside piiramist, sest ajapikku pilvi kasutades saime teada, et vahel on inimestel öösel oluline toidukoorem ja seda koormust ei saa segada. Seetõttu lisasime ressursside piiramise.
- Nagu ka noteerimine ja haldamine.
- Ja kontrollimine.
Vaatasime palju erinevaid tööriistu. Õnneks on meil PostgreSQL-is tohutu valik. Ja igal pool oli meil midagi puudu, mõni üks väike funktsioon, mõni väike funktsioon.
Ja olles uurinud olemasolevaid süsteeme, jõudsime järeldusele, et töötame välja WAL-G. See oli siis uus projekt. Arengut varusüsteemi pilvetaristu suunas oli üsna lihtne mõjutada.
Peamine ideoloogia, millest me kinni peame, on see, et WAL-G peaks olema lihtne kui balalaika.
WAL-G-l on 4 käsku. See:
WAL-PUSH – arhiveeri võll.
WAL-FETCH – hankige võll.
BACKUP-PUSH – varukoopia tegemine.
BACKUP-FETCH – hankige varundussüsteemist varukoopia.
Tegelikult on WAL-G-l ka nende varukoopiate haldamine, st hetkel mittevajalike kirjete ja varukoopiate loetlemine ja kustutamine ajaloos.
Üks meie jaoks olulisi funktsioone on deltakoopiate loomise funktsioon.
Delta koopiad tähendavad, et me ei loo kogu klastri täielikku varukoopiat, vaid ainult muudetud failide muudetud lehekülgi klastris. Näib, et funktsionaalselt on see väga sarnane WAL-i abil taastamise võimalusega. Kuid me saame paralleelselt kokku panna WAL-i ühe keermega delta-varukoopia. Seega, kui meil on laupäeval tehtud põhivarukoopia, iga päev deltavarukoopia ja neljapäeval see ebaõnnestub, peame kokku võtma 4 deltavarukoopiat ja 10 tundi WAL-i. See võtab umbes sama kaua aega, kuna delta-varukoopiad veerevad paralleelselt.
LSN-põhised deltad – see tähendab, et varukoopia loomisel peame iga lehe kombineerima ja kontrollima selle LSN-i eelmise varukoopia LSN-iga, et mõista, et see on muutunud. Delta varukoopias peaksid olema kõik lehed, mis võivad potentsiaalselt sisaldada muutunud andmeid.
Nagu öeldud, siis paralleelsusele pöörati päris palju tähelepanu.
Kuid PostgreSQL-i arhiivi API on järjepidev. PostgreSQL arhiveerib ühe WAL-faili ja taastamisel küsib ühte WAL-faili. Kuid kui andmebaas nõuab käsku "WAL-FETCH" kasutades ühte WAL-faili, kutsume välja käsu "WAL-PREFETCH", mis valmistab ette järgmised 8 faili, et paralleelselt objektipoest andmeid tuua.
Ja kui andmebaas palub meil arhiivida ühe faili, vaatame archive_status ja vaatame, kas seal on teisi WAL-faile. Ja paralleelselt proovime ka WAL-i alla laadida. See suurendab oluliselt jõudlust ja vähendab oluliselt arhiveerimata WAL-ide arvu kaugust. Paljud varusüsteemide arendajad usuvad, et see on nii riskantne süsteem, kuna tugineme oma teadmistele koodi sisemiste kohta, mis ei ole PostgreSQL API. PostgreSQL ei garanteeri meie jaoks kausta archive_status olemasolu ega garanteeri semantikat, WAL-failide valmisolekusignaalide olemasolu seal. Sellegipoolest uurime lähtekoodi, näeme, et see nii on, ja proovime seda ära kasutada. Ja me kontrollime PostgreSQL-i arengusuunda; kui see mehhanism äkki katki läheb, lõpetame selle kasutamise.
Puhtal kujul nõuab LSN-põhine WAL-delta kõigi klastrifailide lugemist, mille režiimiaeg failisüsteemis on pärast eelmist varundust muutunud. Me elasime sellega pikka aega, peaaegu aasta. Ja lõpuks jõudsime järeldusele, et meil on WAL-i deltad.
See tähendab, et iga kord, kui WAL-i Masteris arhiveerime, me mitte ainult ei tihenda seda, krüpteerime ja saadame võrku, vaid loeme seda ka samal ajal. Analüüsime ja loeme selles olevaid kirjeid. Mõistame, millised plokid on muutunud, ja kogume deltafaile.
Delta-fail kirjeldab teatud WAL-failide vahemikku, kirjeldab teavet selle kohta, milliseid plokke selles WAL-i vahemikus muudeti. Ja siis need delta failid ka arhiveeritakse.
Siin seisame silmitsi tõsiasjaga, et paralleeliseerisime kõik üsna kiiresti, kuid paralleelselt järjestikust ajalugu lugeda ei saa, sest teatud segmendis võime kohata eelmise WAL-i kirje lõppu, millega meil pole veel midagi siduda, sest paralleellugemine viis selleni, et kõigepealt analüüsime tulevikku, millel pole veel minevikku.
Selle tulemusena pidime arusaamatud tükid _delta_partial failidesse panema. Selle tulemusena liimime minevikku naastes WAL-i plaadi tükid üheks, pärast seda sõelume selle ja mõistame, mis selles muutus.
Kui meie võlli parsimise ajaloos on vähemalt üks punkt, kus me ei saa aru, mis juhtus, siis vastavalt sellele oleme järgmise varundamise ajal sunnitud kogu klastri uuesti lugema, täpselt nagu tavalise LSN-i puhul. -põhine delta.
Selle tulemusel viisid kõik meie kannatused selleni, et kasutasime WAL-G parsimise teegi avatud lähtekoodiga. Minu teada keegi seda veel ei kasuta, aga kui keegi tahab, siis kirjutage ja kasutage, siis see on avalikus omandis. (Uuendatud link )
Seetõttu tunduvad kõik infovood üsna keerulised. Meie meister arhiveerib võlli ja arhiveerib deltafailid. Ja koopia, mis teeb varukoopia, peab varukoopiate vahel möödunud aja jooksul deltafaile vastu võtma. Sel juhul tuleb ajaloo osad hulgi lisada ja sõeluda, kuna kogu ajalugu ei mahu suurteks osadeks. Ja alles pärast seda saab koopia arhiveerida täieliku delta-varukoopia.
Graafikutel tundub kõik palju lihtsam. See on allalaadimine ühest meie pärisklastrist. Meil on LSN-põhine, tehtud ühe päevaga. Ja me näeme, et LSN-põhine deltavarukoopia töötas kella kolmest hommikul viieni hommikul. See on protsessori tuumade arvu koormus. WAL-deltaga kulus meil siin umbes 20 minutit ehk muutus oluliselt kiiremaks, aga samas toimus üle võrgu intensiivsem vahetus.
Kuna meil on teavet selle kohta, millised plokid ja mis ajal andmebaasi ajaloos muutusid, läksime kaugemale ja otsustasime integreerida funktsioonid - PostgreSQL-i laienduse nimega “pg_prefaulter”
See tähendab, et kui ootebaas täidab taastamiskäsu, käsib see WAL-G-l tõmmata järgmine WAL-fail. Me mõistame ligikaudu, millistele andmeplokkidele WAL-i taastamise protsess lähitulevikus juurde pääseb, ja käivitame nende plokkide lugemistoimingu. Seda tehti SSD-kontrollerite jõudluse suurendamiseks. Sest WAL-rull jõuab lehele, mida tuleb muuta. See leht on kettal ja ei ole lehe vahemälus. Ja ta ootab sünkroonselt selle lehe saabumist. Kuid läheduses on WAL-G, mis teab, et järgmise paarisaja megabaidi WAL-i jooksul vajame teatud lehti ja samal ajal hakkab neid soojendama. Käivitab mitu kettale juurdepääsu, nii et neid täidetakse paralleelselt. See töötab SSD-draividel hästi, kuid kahjuks pole see kõvaketta jaoks absoluutselt rakendatav, sest me segame seda ainult oma viipadega.
See on nüüd koodis sees.
On funktsioone, mida tahaksime lisada.
Sellel pildil on näha, et WAL-delta võtab suhteliselt vähe aega. Ja see on päeva jooksul andmebaasis toimunud muudatuste lugemine. WAL-deltat võiksime teha mitte ainult öösiti, sest see pole enam oluline koormusallikas. Võime lugeda WAL-deltat iga minut, sest see on odav. Ühe minutiga saame skannida kõik klastris toimunud muudatused. Ja seda võiks nimetada "instant WAL-deltaks".
Asi on selles, et klastri taastamisel vähendame lugude arvu, mida peame järjestikku kokku kerima. See tähendab, et PostgreSQL-i veeretava WAL-i kogust tuleks vähendada, kuna see võtab palju aega.
Kuid see pole veel kõik. Kui me teame, et mõnda plokki muudetakse kuni varukoopia järjepidevuse punktini, ei saa me seda varem muuta. See tähendab, et nüüd on meil WAL-delta edastamise optimeerimine failide kaupa. See tähendab, et kui näiteks teisipäeval kustutati tabel täielikult või mõned failid kustutati tabelist täielikult, siis kui esmaspäeval delta läheb üle ja laupäevane pg_basebackup taastatakse, siis me neid andmeid isegi ei loo.
Soovime seda tehnoloogiat laiendada lehe tasemele. See tähendab, et kui mõni osa failist muutub esmaspäeval, kuid kirjutatakse üle kolmapäeval, siis neljapäeval punkti taastades ei pea me lehtede paari esimest versiooni kettale kirjutama.
Kuid see on endiselt idee, mida meie sees aktiivselt arutatakse, kuid see pole veel jõudnud koodini.
Tahame WAL-G-sse teha veel ühe funktsiooni. Tahame muuta selle laiendatavaks, kuna peame toetama erinevaid andmebaase ja soovime läheneda varukoopiahaldusele samamoodi. Kuid probleem on selles, et MySQL API-d on radikaalselt erinevad. MySQL-is ei põhine PITR füüsilisel WAL-logil, vaid binlogil. Ja meil pole MySQL-is arhiveerimissüsteemi, mis teataks mõnele välisele süsteemile, et see binlog on lõppenud ja seda tuleb arhiveerida. Peame andmebaasiga kuskil cronis seisma ja kontrollima, kas midagi on valmis?
Ja samamoodi ei ole MySQL-i taastamise ajal ühtegi taastamiskäsku, mis võiks süsteemile öelda, et mul on vaja selliseid ja selliseid faile. Enne klastri taastamise alustamist peate teadma, milliseid faile vajate. Peate ise ära arvama, milliseid faile vajate. Kuid neist probleemidest saab kuidagi mööda hiilida. (Selgitus: MySQL on juba toetatud)
Raportis tahtsin rääkida ka nendest juhtumitest, kui WAL-G teile ei sobi.
Kui teil pole sünkroonset koopiat, ei garanteeri WAL-G viimase segmendi säilimist. Ja kui arhiveerimine jääb viimase paari ajaloolõigu taha, on see oht. Kui sünkroonset koopiat pole, ei soovita ma WAL-G-d kasutada. Sellegipoolest on see mõeldud peamiselt pilvinstallimiseks, mis tähendab kõrge saadavuse lahendust koos sünkroonse koopiaga, mis vastutab viimaste tehtud baitide ohutuse eest.
Näen sageli inimesi, kes üritavad korraga käivitada nii WAL-G-d kui ka WAL-E-d. Toetame tagasiühilduvust selles mõttes, et WAL-G saab taastada faili WAL-E-st ja taastada WAL-E-s tehtud varukoopia. Kuid kuna mõlemad süsteemid kasutavad paralleelset wal-pushi, hakkavad nad üksteiselt faile varastama. Kui parandame selle WAL-G-s, jääb see endiselt WAL-E-sse. WAL-E-s vaatab see arhiivi olekut, näeb valmis faile ja arhiveerib need, samas kui teised süsteemid lihtsalt ei tea, et see WAL-fail eksisteeris, sest PostgreSQL ei proovi seda teist korda arhiveerida.
Mida me siin WAL-G poolel parandame? Me ei teavita PostgreSQL-i, et see fail edastati paralleelselt ja kui PostgreSQL palub meil see arhiveerida, teame juba, et selline fail selle režiimi-aja ja selle md5-ga on juba arhiveeritud ja ütleme lihtsalt PostgreSQL-i: OK, kõik on valmis ilma sisuliselt midagi tegemata.
Kuid seda probleemi WAL-E poolel tõenäoliselt ei lahendata, seega on praegu võimatu luua arhiivikäsku, mis arhiveerib faili nii WAL-G-s kui ka WAL-E-s.
Lisaks on juhtumeid, kus WAL-G teile praegu ei sobi, kuid kindlasti teeme selle korda.
Esiteks ei ole meil praegu sisseehitatud varukoopia kinnitamist. Meil ei ole kinnitust ei varundamise ega taastamise ajal. Loomulikult rakendatakse seda pilves. Kuid seda rakendatakse lihtsalt eelkontrolliga, lihtsalt klastri taastamisega. Tahaksin anda selle funktsiooni kasutajatele. Kuid kinnitades eeldan, et WAL-G-s on võimalik klastrit taastada ja käivitada ning käivitada suitsutestid: pg_dumpall kuni /dev/null ja amcheck indeksi verifitseerimine.
Praegu ei saa WAL-G-s ühte varundamist WAL-ist edasi lükata. See tähendab, et me toetame mõnda akent. Näiteks viimase seitsme päeva salvestamine, viimase kümne varukoopia salvestamine, viimase kolme täieliku varukoopia salvestamine. Üsna sageli tullakse ja öeldakse: "Meil on vaja varukoopiat sellest, mis uusaastal juhtus, ja tahame seda igavesti säilitada." WAL-G ei saa seda veel teha. (Märkus – see on juba parandatud. Loe lähemalt – Varukoopia märgistamise valik sisse )
Ja meil ei ole PITR-i valideerimisel kõigi võlli segmentide lehtede kontrollsummasid ja terviklikkuse kontrolle.
Sellest kõigest panin kokku projekti Google Summer of Code jaoks. Kui tead nutikaid tudengeid, kes tahaksid Go-sse midagi kirjutada ja ühest “G”-tähega ettevõttest mitu tuhat dollarit saada, siis soovita neile meie projekti. Tegutsen selle projekti mentorina, nad saavad sellega hakkama. Kui õpilasi pole, siis võtan ja teen suvel ise.
Ja meil on palju muid väikeseid probleeme, mille kallal tasapisi tegeleme. Ja päris kummalisi asju juhtub.
Näiteks kui annate WAL-G-le tühja varukoopia, kukub see lihtsalt maha. Näiteks kui ütlete talle, et ta peab varundama tühja kausta. Pg_control faili seal ei ole. Ja ta arvab, et ta ei saa millestki aru. Teoreetiliselt peate sel juhul kasutajale kirjutama tavalise sõnumi, et selgitada talle, kuidas tööriista kasutada. Kuid see pole isegi programmeerimise, vaid hea, arusaadava keele omadus.
Me ei tea, kuidas võrguühenduseta varundada. Kui andmebaas valetab, ei saa me seda varundada. Kuid siin on kõik väga lihtne. Helistame LSN-i varundustele, kui see algas. Juhtfailist tuleb lugeda aluseks oleva baasi LSN. Ja see on nii realiseerimata funktsioon. Paljud varundussüsteemid saavad varundada aluseks oleva andmebaasi. Ja see on mugav.
Praegu ei saa me varuruumi puudumisega korralikult hakkama. Sest tavaliselt töötame kodus suurte varukoopiatega. Ja nad ei jõudnud selleni. Aga kui keegi soovib Go-s praegu programmeerida, lisage ämbrisse ruumi puudumise vigade käsitlemine. Uurin kindlasti tõmbetaotlust.
Ja peamine, mis meile muret teeb, on see, et me tahame võimalikult palju dokkerite integratsiooniteste, mis kontrollivad erinevaid stsenaariume. Praegu katsetame ainult põhistsenaariume. Igal sissekandmisel, kuid me tahame kontrollida kinnistamise haaval kõiki toetatavaid funktsioone. Eelkõige on meil näiteks piisavalt tuge PostgreSQL 9.4-9.5 jaoks. Toetame neid, kuna kogukond toetab PostgreSQL-i, kuid me ei kontrolli kohustuste kaupa, et veenduda, et kõik pole katki. Ja mulle tundub, et see on üsna tõsine risk.
Meil töötab WAL-G rohkem kui tuhandes Yandexi andmebaasi haldamise klastris. Ja see varundab iga päev mitusada terabaiti andmeid.
Meie koodis on palju TODO-d. Kui soovid programmeerida, tule kohale, ootame tõmbesoove, ootame küsimusi.
küsimused
Tere õhtust! Aitäh! Ma arvan, et kui kasutate WAL-deltat, toetute tõenäoliselt suuresti terve lehe kirjutistele. Ja kui jah, siis kas tegite teste? Sa näitasid ilusat graafikut. Kui palju ilusamaks see muutub, kui FPW välja lülitada?
Täisleheline kirjutamine on meil lubatud, me pole proovinud seda keelata. See tähendab, et mina kui arendaja pole proovinud seda välja lülitada. Uurinud süsteemiadministraatorid on seda probleemi ilmselt uurinud. Kuid me vajame FPW-d. Peaaegu keegi ei keela seda, sest muidu on võimatu koopiast varukoopiat teha.
Täname raporti eest! Mul on kaks küsimust. Esimene küsimus on, mis saab lauapindadest?
Ootame tõmbetaotlust. Meie andmebaasid asuvad SSD- ja NMVE-ketastel ning me ei vaja seda funktsiooni tegelikult. Ma ei ole praegu valmis kulutama tõsist aega, et seda hästi teha. Ma toetan kogu südamest seda, et me seda toetame. On inimesi, kes toetasid, kuid toetasid seda neile sobival viisil. Nad tegid kahvli, kuid nad ei täida tõmbetaotlusi. (Lisati versioonis 0.2.13)
Ja teine küsimus. Ütlesite kohe alguses, et WAL-G eeldab, et see töötab üksi ja ümbriseid pole vaja. Ise kasutan ümbriseid. Miks ei võiks neid kasutada?
Tahame, et see oleks sama lihtne kui balalaika. See tähendab, et te ei vaja midagi peale balalaika. Soovime, et süsteem oleks lihtne. Kui teil on funktsioone, mida peate skriptis tegema, siis tule ja ütle meile – me teeme seda Go-s.
Tere õhtust! Täname raporti eest! Meil ei õnnestunud WAL-G-d GPG dekrüpteerimisega tööle panna. See krüpteerib tavaliselt, kuid ei taha dekrüpteerida. Kas see on midagi, mis meie jaoks ei õnnestunud? Olukord on masendav.
Looge GitHubis probleem ja mõtleme selle välja.
See tähendab, et te pole sellega kokku puutunud?
Veateatel on funktsioon, et kui WAL-G ei saa aru, mis failiga on tegu, küsib ta: "Võib-olla on see krüptitud?" Võib-olla pole probleem üldse krüpteerimises. Soovin selle teema logimist parandada. Ta peab selle dešifreerima. Praegu töötame selle teemaga selles mõttes, et meile ei meeldi eriti see, kuidas avalike ja privaatvõtmete hankimise süsteem on korraldatud. Sest me kutsume välist GPG-d, et see annab meile oma võtmed. Ja siis me võtame need võtmed ja edastame need sisemisse GPG-sse, mis on avatud PGP, mis on meie jaoks WAL-G sees kompileeritud, ja seal me nimetame krüptimist. Sellega seoses tahame süsteemi täiustada ja toetada Libsodium krüptimist (lisatud versioonis 0.2.15). Muidugi peaks dekodeerimine toimima, mõtleme selle välja – vaja on rohkem sümptomit kui paari sõna. Võite mõnikord koguneda kõnelejatuppa ja vaadata süsteemi. (PGP-krüptimine ilma välise GPG-ta – v0.2.9)
Tere! Täname raporti eest! Mul on kaks küsimust. Mul on kummaline soov teha pg_basebackup ja WAL sisse logida kaks pakkujat, st tahan teha ühte pilve ja teist. Kas seda saab kuidagi teha?
Seda pole praegu olemas, kuid see on huvitav idee.
Ma lihtsalt ei usalda ühte teenusepakkujat, tahan, et igaks juhuks oleks sama ka teisel.
Idee on huvitav. Tehniliselt pole selle rakendamine sugugi keeruline. Kas ma võin teil paluda teil GitHubis probleemi tekitada, et idee kaotsi ei läheks?
Jah, muidugi.
Ja siis, kui õpilased tulevad Google Summer of Code'i, lisame nad projekti, et oleks rohkem tööd, et neist rohkem kasu saada.
Ja teine küsimus. GitHubis on probleem. Ma arvan, et see on juba suletud. Taastamise ajal on paanika. Ja selle võitmiseks tegite eraldi koostu. Küsimustes on see õige. Ja seal on võimalus teha muutuv keskkond ühes lõimes. Ja seetõttu töötab see väga aeglaselt. Ja me puutusime selle probleemiga kokku ja seda pole veel lahendatud.
Probleem on selles, et mingil põhjusel lähtestab salvestusruum (CEPH) ühenduse, kui jõuame selleni suure samaaegsusega. Mida saab selle vastu ette võtta? Uuesti proovimise loogika näeb välja selline. Proovime faili uuesti alla laadida. Ühe käiguga jäi meil hulk faile alla laadimata, teeme teise kõigile neile, kes sisse ei loginud. Ja seni, kuni iga iteratsiooni kohta on laaditud vähemalt üks fail, kordame ja kordame ja kordame. Täiendasime uuesti proovimise loogikat – eksponentsiaalne taganemine. Kuid pole täiesti selge, mida teha, kui ühendus lihtsalt katkeb salvestussüsteemi poolel. See tähendab, et kui laadime üles ühte voogu, siis see neid ühendusi ei katkesta. Mida saame siin parandada? Meil on võrgu drossel, saame piirata iga ühendust saadetavate baitide arvuga. Muidu ma ei tea, kuidas tulla toime asjaoluga, et objektide salvestusruum ei võimalda meil sellest paralleelselt alla laadida ega alla laadida.
Kas SLA-d pole? Kas pole neile kirjutatud, kuidas nad lasevad end piinata?
Asi on selles, et inimestel, kes selle küsimuse välja tulevad, on tavaliselt oma varahoidla. See tähendab, et keegi ei pärine Amazonist või Google Cloudist või Yandex Object Storage'ist.
Võib-olla pole see küsimus enam sinu jaoks?
Küsimus siin antud juhul ei oma tähtsust kellele. Kui on ideid, kuidas sellega toime tulla, siis teeme seda WAL-G-s. Kuid siiani pole mul häid ideid, kuidas sellega toime tulla. Mõned objektide salvestusruumid toetavad varukoopiate loendit erinevalt. Te palute neil objekte loetleda ja nad lisavad sinna kausta. WAL-G kardab selle peale – siin on mingi asi, mis ei ole fail, ma ei saa seda taastada, mis tähendab, et varukoopiat ei taastatud. See tähendab, et teil on täielikult taastatud klaster, kuid see tagastab teile vigase oleku, kuna Object Storage tagastas kummalise teabe, millest ta täielikult aru ei saanud.
See on asi, mis juhtub meilipilves.
Kui suudate reprodutseerida...
Seda reprodutseeritakse järjepidevalt...
Kui on reprodutseerimine, siis ma arvan, et katsetame uuesti proovimise strateegiaid ja mõtleme välja, kuidas uuesti proovida, ja mõistame, mida pilv meilt nõuab. Võib-olla on see meie jaoks stabiilne kolmel ühendusel ja ei katkesta ühendust, siis jõuame ettevaatlikult kolmeni. Sest nüüd katkestame ühenduse väga kiiresti, st kui käivitasime taastamise 16 lõimega, siis pärast esimest uuesti proovimist on 8 lõime, 4 lõime, 2 lõime ja üks. Ja siis tõmbab see faili ühte voogu. Kui on mõned maagilised väärtused, näiteks 7,5 lõime on pumpamiseks parimad, siis peatume nendel ja proovime teha veel 7,5 niiti. Siin on idee.
Täname raporti eest! Kuidas näeb välja täielik töövoog WAL-G-ga töötamiseks? Näiteks lollil juhul, kui lehtede vahelt deltat pole. Ja me võtame ja eemaldame esialgse varukoopia, seejärel arhiveerime võlli, kuni oleme näost sinised. Siin, nagu ma aru saan, on rike. Mingil hetkel tuleb teha lehtedest delta-varukoopia, st kas mingi väline protsess juhib seda või kuidas see juhtub?
Delta varunduse API on üsna lihtne. Seal on number – max delta sammud, nii seda nimetatakse. Vaikimisi on see null. See tähendab, et iga kord, kui teete varukoopia, laadib see alla täieliku varukoopia. Kui muudate selle suvaliseks positiivseks arvuks, näiteks 3, siis järgmine kord, kui teete varundustõuke, vaatab see eelmiste varukoopiate ajalugu. Ta näeb, et sa ei ületa 3 delta ahelat ja teeb delta.
See tähendab, et iga kord, kui käivitame WAL-G, proovib see teha täielikku varukoopiat?
Ei, me käitame WAL-G-d ja see proovib teha deltat, kui teie eeskirjad seda lubavad.
Jämedalt öeldes, kui käivitate selle iga kord nulliga, kas see käitub nagu pg_basebackup?
Ei, see töötab ikkagi kiiremini, kuna see kasutab tihendamist ja paralleelsust. Pg_basebackup paneb võlli teie kõrvale. WAL-G eeldab, et arhiveerimine on konfigureeritud. Ja see annab hoiatuse, kui see pole konfigureeritud.
Pg_basebackupi saab käivitada ilma võllideta.
Jah, siis käituvad nad peaaegu samamoodi. Pg_basebackup kopeerib failisüsteemi. Muide, meil on uus funktsioon, mille unustasin mainida. Nüüd saame pg_basebackupist failisüsteemi varundada. Ma ei tea, miks seda vaja on, aga see on olemas.
Näiteks CephFS-is. Mitte igaüks ei taha objektide salvestusruumi konfigureerida.
Jah, ilmselt seepärast küsisid nad selle funktsiooni kohta küsimuse, et saaksime seda teha. Ja me tegime seda.
Täname raporti eest! Küsimus on lihtsalt failisüsteemi kopeerimise kohta. Kas karbist väljas toetate nüüd kaugmällu kopeerimist, kui andmekeskuses on mõni riiul või midagi muud?
Selles sõnastuses on see keeruline küsimus. Jah, me toetame, kuid see funktsioon pole veel üheski versioonis sisaldunud. See tähendab, et kõik eelversioonid toetavad seda, kuid väljalaskeversioonid mitte. See funktsioon lisati versioonis 0.2. See avaldatakse kindlasti varsti, niipea kui kõik teadaolevad vead parandame. Kuid praegu saab seda teha ainult eelväljaandes. Eelväljaandes on kaks viga. Probleem WAL-E taastamisega, me pole seda parandanud. Ja viimases eelväljaandes lisati delta-varunduse viga. Seetõttu soovitame kõigil kasutada väljalaskeversioone. Niipea, kui eelväljaandes pole enam vigu, võime öelda, et toetame Google Cloudi, S3-ga ühilduvaid asju ja failide salvestamist.
Tere, täname aruande eest. Nagu ma aru saan, pole WAL-G mingi tsentraliseeritud süsteem nagu baarimehed? Kas plaanite selles suunas liikuda?
Probleem on selles, et oleme sellest suunast eemaldunud. WAL-G elab baashostis, klastri hostis ja kõigis klastri hostides. Kui kolisime mitmesse tuhandesse klastrisse, oli meil palju baarmenite sisseseadeid. Ja iga kord, kui neis midagi laguneb, on see suur probleem. Kuna neid tuleb parandada, peate mõistma, millistel klastritel pole nüüd varukoopiaid. Ma ei plaani arendada WAL-G-d varusüsteemide füüsilise riistvara suunas. Kui kogukond soovib siin mingit funktsionaalsust, pole mul selle vastu midagi.
Meil on meeskonnad, kes vastutavad ladustamise eest. Ja me tunneme end nii hästi, et see pole meie, et on spetsiaalsed inimesed, kes panevad meie failid sinna, kus failid on turvalised. Nad teevad seal kõikvõimalikku nutikat kodeerimist, et teatud arvu failide kadumist vastu pidada. Nad vastutavad võrgu ribalaiuse eest. Kui teil on baarmen, võite äkki avastada, et samasse serverisse on kogunenud väikesed suure liiklusega andmebaasid. Tundub, et teil on sellel palju ruumi, kuid mingil põhjusel ei mahu kõik võrku. See võib osutuda vastupidiseks. Seal on palju võrke, on protsessori tuumad, kuid siin pole kettaid. Ja me tüdinesime sellest vajadusest millegagi žongleerida ja liikusime selleni, et andmesalvestus on eraldi teenus, mille eest vastutavad eraldi eriinimesed.
PS Uus versioon on välja antud , milles saab kasutada konfiguratsioonifaili .walg.json, mis asub vaikimisi postgresi kodukataloogis. Võite bash-skriptidest loobuda. Selles väljaandes on näide .walg.json
Video:
Allikas: www.habr.com