Ég legg til að þú lesir afrit skýrslunnar frá byrjun árs 2019 eftir Andrey Borodin „Afrit með WAL-G. Hvað er þar árið 2019?“
Hæ allir! Ég heiti Andrey Borodin. Ég er verktaki hjá Yandex. Ég hef haft áhuga á PostgreSQL síðan 2016, eftir að ég talaði við þróunaraðilana og þeir sögðu að allt væri einfalt - þú tekur frumkóðann og smíðar hann og allt mun ganga upp. Og síðan þá get ég ekki hætt - ég skrifa alls kyns mismunandi hluti.
Eitt af því sem ég er að vinna í er varakerfi. . Almennt séð höfum við hjá Yandex unnið að öryggisafritunarkerfum í PostgreSQL í mjög langan tíma. Og þú getur fundið á netinu röð af sex skýrslum um hvernig við gerum öryggisafritunarkerfi. Og á hverju ári þróast þeir aðeins, þróast aðeins og verða áreiðanlegri.
En í dag snýst skýrslan ekki aðeins um það sem við höfum gert, heldur einnig um hversu einfalt það er og hvað er. Hversu mörg ykkar hafa þegar horft á skýrslur mínar um WAL-G? Það er gott að allmargir horfðu ekki því ég byrja á því einfaldasta.
Ef þú ert skyndilega með PostgreSQL þyrping, og ég held að allir séu með nokkra af þeim með sér, og allt í einu er ekkert varakerfi ennþá, þá þarftu að fá hvaða S3 geymslu eða Google Cloud samhæfða geymslu.
Til dæmis geturðu komið á básinn okkar og tekið kynningarkóða fyrir Yandex Object Storage, sem er S3 samhæft.
Búðu síðan til fötu. Það er bara gámur fyrir upplýsingar.
Búðu til þjónustunotanda.
Búðu til aðgangslykil fyrir þjónustunotandann: aws-s3-key.
Sæktu nýjustu stöðugu útgáfuna af WAL-G.
Hvernig eru forútgáfur okkar frábrugðnar útgáfum? Ég er oft beðin um að sleppa snemma. Og ef það er engin galla í útgáfunni í nægan tíma, til dæmis mánuð, þá gef ég hana út. Hér er þessi útgáfa frá nóvember. Og þetta þýðir að í hverjum mánuði fundum við einhvers konar villu, venjulega í ekki mikilvægum virkni, en við höfum ekki enn gefið út útgáfu. Fyrri útgáfan er aðeins í nóvember. Það eru engar villur þekktar fyrir okkur í henni, þ.e. villum var bætt við eftir því sem leið á verkefnið.
Þegar þú hefur hlaðið niður WAL-G geturðu keyrt einfalda „afritalista“ skipun og sent inn umhverfisbreyturnar. Og það mun tengjast Object Storage og segja þér hvaða afrit þú hefur. Í fyrstu ættirðu auðvitað ekki að hafa öryggisafrit. Tilgangurinn með þessari glæru er að sýna að allt er frekar einfalt. Þetta er stjórnborðsskipun sem tekur við umhverfisbreytum og framkvæmir undirskipanir.
Eftir þetta geturðu gert fyrsta öryggisafritið þitt. Segðu „backup-push“ í WAL-G og tilgreindu í WAL-G pgdata staðsetningu þyrpingarinnar. Og líklega mun PostgreSQL segja þér, ef þú ert ekki þegar með öryggisafritunarkerfi, að þú þurfir að virkja "skjalasafnsstillingu".
Þetta þýðir að þú þarft að fara í stillingar og kveikja á “archive_mode = on” og bæta við “archive_command”, sem er líka undirskipun í WAL-G. En af einhverjum ástæðum notar fólk oft strikaskriftir um þetta efni og vefur því utan um WAL-G. Vinsamlegast ekki gera þetta. Notaðu virknina sem er að finna í WAL-G. Ef þig vantar eitthvað skaltu skrifa til . WAL-G gerir ráð fyrir að það sé eina forritið sem keyrir í archive_command.
Við notum WAL-G aðallega til að búa til háa framboðsklasa í Yandex gagnagrunnsstjórnun.
Og það er venjulega notað í staðfræði eins meistara og nokkrum afritunum. Á sama tíma gerir það öryggisafrit í Yandex Object Storage.
Algengustu aðstæðurnar eru að búa til afrit af klasa með því að nota Point in time recovery. En í þessu tilviki er árangur öryggisafritunarkerfisins ekki svo mikilvægt fyrir okkur. Við þurfum bara að hlaða upp nýjum klasa úr öryggisafritinu.
Venjulega þurfum við afköst öryggisafritunarkerfisins þegar við bætum við nýjum hnút. Hvers vegna er það mikilvægt? Venjulega bætir fólk nýjum hnút við klasa vegna þess að núverandi klasi ræður ekki við lestrarálagið. Þeir þurfa að bæta við nýrri eftirmynd. Ef við bætum álaginu frá pg_basebackup við Master, þá gæti Masterinn hrunið. Þess vegna var það mjög mikilvægt fyrir okkur að við gætum fljótt hlaðið upp nýjum hnút úr skjalasafninu og skapað lágmarks álag á Master.
Og annað svipað ástand. Þetta er nauðsyn þess að endurræsa gamla Master eftir að skipt var um Cluster Master úr gagnaverinu sem tengingin rofnaði við.
- Þar af leiðandi, þegar við mótuðum kröfurnar fyrir afritunarkerfið, áttuðum við okkur á því að pg_basebackup hentar okkur ekki þegar unnið er í skýinu.
- Við vildum geta þjappað gögnunum okkar saman. En næstum öll öryggisafritunarkerfi annað en það sem kemur í kassanum mun veita gagnaþjöppun.
- Við vildum samhliða öllu því notandi í skýinu kaupir mikinn fjölda örgjörvakjarna. En ef við höfum ekki samsvörun í einhverri aðgerð, þá verður mikill fjöldi kjarna gagnslaus.
- Við þurfum dulkóðun því oft eru gögnin ekki okkar og ekki er hægt að geyma þau í skýrum texta. Við the vegur, framlag okkar til WAL-G byrjaði með dulkóðun. Við kláruðum dulkóðunina í WAL-G, eftir það vorum við spurð: „Kannski mun einn okkar þróa verkefnið? Og síðan þá hef ég unnið með WAL-G í meira en ár.
- Okkur vantaði líka inngjöf á auðlindum, vegna þess að með tímanum með því að nota skýið komumst við að því að stundum er fólk með mikilvægan matvöruálag á nóttunni og ekki er hægt að trufla þetta álag. Þess vegna bættum við við inngjöf auðlinda.
- Sem og skráningu og stjórnun.
- Og sannprófun.
Við skoðuðum mikið af mismunandi verkfærum. Sem betur fer höfum við mikið úrval í PostgreSQL. Og alls staðar vantaði eitthvað, einhverja litla eiginleika, einhverja litla eiginleika.
Og eftir að hafa skoðað núverandi kerfi komumst við að þeirri niðurstöðu að við munum þróa WAL-G. Þá var þetta nýtt verkefni. Það var frekar auðvelt að hafa áhrif á þróunina í átt að skýjainnviðum afritunarkerfisins.
Helsta hugmyndafræðin sem við fylgjumst með er að WAL-G ætti að vera eins einfalt og balalaika.
WAL-G hefur 4 skipanir. Þetta:
WAL-PUSH – geymdu skaftið.
WAL-FETCH – fáðu þér skaft.
BACKUP-PUSH – gerðu öryggisafrit.
BACKUP-FETCH – fáðu öryggisafrit úr afritunarkerfinu.
Reyndar hefur WAL-G einnig umsjón með þessum afritum, þ.e.a.s. skrá og eyða skrám og afritum í sögu sem ekki er lengur þörf á í augnablikinu.
Eitt af mikilvægu hlutverkunum fyrir okkur er hlutverkið að búa til delta afrit.
Delta afrit þýða að við búum ekki til fullt öryggisafrit af öllum klasanum, heldur aðeins breyttum síðum breyttra skráa í klasanum. Það virðist sem virknilega sé þetta mjög svipað og getu til að endurheimta með WAL. En við getum rúllað upp WAL einþráðum delta öryggisafriti samhliða. Í samræmi við það, þegar við erum með grunnafrit á laugardögum, afrit af delta daglega og á fimmtudegi mistekst okkur, þá þurfum við að taka upp 4 afrit af delta og 10 klukkustundum af WAL. Það mun taka um það bil sama tíma vegna þess að delta öryggisafritin rúlla samhliða.
LSN-undirstaða deltas - þetta þýðir að þegar öryggisafrit er búið til þurfum við að sameina hverja síðu og athuga LSN hennar við LSN fyrri öryggisafritsins til að skilja að hún hefur breyst. Sérhver síða sem gæti innihaldið breytt gögn ætti að vera til staðar í delta öryggisafritinu.
Eins og ég sagði var töluvert mikið um samsvörun.
En skjalasafn API í PostgreSQL er í samræmi. PostgreSQL geymir eina WAL skrá og biður um eina WAL skrá þegar hún er endurheimt. En þegar gagnagrunnurinn biður um eina WAL skrá með því að nota „WAL-FETCH“ skipunina, köllum við „WAL-PREFETCH“ skipunina, sem undirbýr næstu 8 skrár til að sækja gögn úr hlutageymslunni samhliða.
Og þegar gagnagrunnurinn biður okkur um að geyma eina skrá, skoðum við archive_status og sjáum hvort það eru aðrar WAL skrár. Og við erum líka að reyna að hlaða niður WAL samhliða. Þetta veitir umtalsverðan árangur og dregur verulega úr fjarlægð í fjölda ógeymdra WALs. Margir hönnuðir varakerfis telja að þetta sé svo áhættusamt kerfi vegna þess að við treystum á þekkingu okkar á innra hluta kóðans sem er ekki PostgreSQL API. PostgreSQL ábyrgist ekki tilvist archive_status möppunnar fyrir okkur og ábyrgist ekki merkingarfræði, tilvist reiðumerkja fyrir WAL skrár þar. Engu að síður erum við að rannsaka frumkóðann, við sjáum að svo er og við erum að reyna að nýta hann. Og við stjórnum í hvaða átt PostgreSQL er að þróast; ef skyndilega er þetta kerfi bilað, munum við hætta að nota það.
Í hreinu formi krefst LSN-undirstaða WAL delta að lesa allar klasaskrár þar sem hamtími í skráarkerfinu hefur breyst frá fyrri öryggisafriti. Við bjuggum við þetta í langan tíma, tæpt ár. Og á endanum komumst við að þeirri niðurstöðu að við höfum WAL deltas.
Þetta þýðir að í hvert skipti sem við setjum WAL í geymslu á Master, þjöppum við því ekki aðeins, dulkóðum það og sendum það á netið, heldur lesum við það líka á sama tíma. Við greinum og lesum skrárnar í henni. Við skiljum hvaða blokkir hafa breyst og söfnum delta skrám.
Delta skrá lýsir ákveðnu úrvali WAL skráa, lýsir upplýsingum um hvaða kubbum var breytt á þessu sviði WAL. Og svo eru þessar delta skrár líka í geymslu.
Hér stöndum við frammi fyrir þeirri staðreynd að við samsvöruðum allt nokkuð hratt, en við getum ekki lesið raðsögu samhliða, því í ákveðnum hluta gætum við lent í lok fyrri WAL metsins, sem við höfum ekkert að tengja við enn, vegna Samhliða lestur leiddi til þess að við greinum fyrst framtíðina sem á sér ekki fortíð enn.
Þar af leiðandi þurftum við að setja óskiljanlega hluti í _delta_partial skrár. Þar af leiðandi, þegar við snúum aftur til fortíðar, munum við líma stykkin af WAL færslunni í einn, eftir það munum við flokka hana og skilja hvað breyttist í henni.
Ef í sögu skaftgreiningarinnar okkar er að minnsta kosti einn punktur þar sem við skiljum ekki hvað var að gerast, þá neyðumst við til að lesa allan þyrpinguna aftur í næsta öryggisafriti, rétt eins og við gerðum með venjulegu LSN -undirstaða delta.
Þess vegna leiddu allar þjáningar okkar til þess að við höfum opið WAL-G þáttunarsafnið. Eftir því sem ég best veit er enginn að nota það ennþá, en ef einhver vill, skrifa og nota það er það í almenningseigu. (Uppfærður hlekkur )
Þess vegna lítur allt upplýsingaflæði út fyrir að vera nokkuð flókið. Meistari okkar geymir skaftið og geymir delta skrár. Og eftirmyndin sem gerir öryggisafritið verður að fá delta skrár á þeim tíma sem hefur liðið á milli afrita. Í þessu tilviki þarf að bæta við hluta sögunnar í lausu og flokka, vegna þess að öll sagan passar ekki í stóra hluta. Og aðeins eftir þetta getur eftirmyndin geymt fullt delta öryggisafrit.
Á línuritunum lítur allt miklu einfaldara út. Þetta er niðurhal frá einum af okkar raunverulegu klösum. Við höfum LSN byggt, gert á einum degi. Og við sjáum að LSN-undirstaða delta öryggisafrit var í gangi frá þrjú á morgnana til fimm á morgnana. Þetta er álagið á fjölda örgjörvakjarna. WAL-delta tók okkur um það bil 20 mínútur hér, það er að segja að það varð verulega hraðari, en á sama tíma urðu meiri samskipti yfir netið.
Þar sem við höfum upplýsingar um hvaða blokkir breyttust og á hvaða tíma í sögu gagnagrunnsins, gengum við lengra og ákváðum að samþætta virkni - PostgreSQL viðbót sem kallast „pg_prefaulter“
Þetta þýðir að þegar biðstöðin framkvæmir endurheimtunarskipunina segir hann WAL-G að sækja næstu WAL skrá. Við skiljum um það bil hvaða gagnablokkir WAL endurheimtarferlið mun fá aðgang að í náinni framtíð og hefja lestraraðgerð á þessum blokkum. Þetta var gert til að auka afköst SSD stýringa. Vegna þess að WAL rúllan kemst á síðuna sem þarf að breyta. Þessi síða er á diski og er ekki í skyndiminni síðunnar. Og hann mun bíða samstilltur eftir að þessi síða berist. En í nágrenninu er WAL-G, sem veit að á næstu hundruð megabætum af WAL munum við þurfa ákveðnar síður og um leið að byrja að hita þær upp. Hefja marga diskaaðganga þannig að þeir eru keyrðir samhliða. Þetta virkar vel á SSD drifum, en því miður á það alls ekki við um harða diskinn, vegna þess að við truflum hann aðeins með leiðbeiningunum okkar.
Þetta er það sem er í kóðanum núna.
Það eru eiginleikar sem við viljum bæta við.
Þessi mynd sýnir að WAL-delta tekur tiltölulega stuttan tíma. Og þetta er að lesa breytingarnar sem urðu á gagnagrunninum um daginn. Við gætum gert WAL-delta ekki aðeins á nóttunni, vegna þess að það er ekki lengur veruleg uppspretta álags. Við getum lesið WAL-delta á hverri mínútu vegna þess að það er ódýrt. Á einni mínútu getum við skannað allar breytingar sem hafa orðið á klasanum. Og þetta mætti kalla "instant WAL-delta".
Aðalatriðið er að þegar við endurheimtum þyrpinguna fækkum við þeim sögum sem við þurfum að rúlla upp í röð. Það er að segja að það ætti að minnka magn WAL sem PostgreSQL rúllar, því það tekur verulegan tíma.
En það er ekki allt. Ef við vitum að einhver kubb verður breytt í það að öryggisafrit sé samkvæmt, getum við ekki breytt því í fortíðinni. Það er, nú höfum við fínstillingu skrá fyrir skrá á WAL-delta áframsendingu. Þetta þýðir að ef, til dæmis, á þriðjudag var töflu algjörlega eytt eða einhverjum skrám var eytt að öllu leyti úr töflunni, þá munum við ekki einu sinni búa til þessi gögn þegar delta fer yfir á mánudaginn og pg_basebackup laugardagsins er endurheimt.
Við viljum færa þessa tækni út á síðustigið. Það er að segja, ef einhver hluti af skránni breytist á mánudaginn, en verður yfirskrifaður á miðvikudaginn, þá þurfum við ekki að skrifa fyrstu útgáfurnar af síðum á diskinn þegar endurheimt er að stað á fimmtudaginn.
En þetta er enn hugmynd sem er í virkri umræðu innan okkar, en hún hefur ekki enn náð kóðanum.
Við viljum búa til einn eiginleika í viðbót í WAL-G. Við viljum gera það stækkanlegt vegna þess að við þurfum að styðja mismunandi gagnagrunna og viljum gjarnan geta nálgast öryggisafritunarstjórnun á sama hátt. En vandamálið er að MySQL API eru gjörólík. Í MySQL er PITR ekki byggt á efnislegum WAL log, heldur á binlog. Og við erum ekki með geymslukerfi í MySQL sem myndi segja einhverju utanaðkomandi kerfi að þetta binlog sé búið og þarf að geyma það. Við þurfum að standa einhvers staðar í cron með gagnagrunninn og athuga hvort það sé eitthvað tilbúið?
Og á sama hátt, meðan á MySQL endurheimt stendur, er engin endurheimtaskipun sem gæti sagt kerfinu að ég þurfi svona og slíkar skrár. Áður en þú byrjar að endurbyggja þyrpinguna þína þarftu að vita hvaða skrár þú þarft. Þú þarft sjálfur að giska á hvaða skrár þú þarft. En kannski er hægt að sniðganga þessi vandamál einhvern veginn. (Skýring: MySQL er nú þegar stutt)
Í skýrslunni vildi ég líka tala um þau tilvik þegar WAL-G hentar þér ekki.
Ef þú ert ekki með samstillta eftirmynd, ábyrgist WAL-G ekki að síðasti hluti verði varðveittur. Og ef skjalavörslan er á eftir síðustu hlutum sögunnar, þá er það áhætta. Ef það er engin samstillt eftirmynd myndi ég ekki mæla með því að nota WAL-G. Samt er það aðallega hannað fyrir skýjauppsetningu, sem felur í sér High Availability lausn með samstilltri eftirmynd, sem er ábyrgur fyrir öryggi síðustu bæti sem framið var.
Ég sé oft fólk reyna að keyra bæði WAL-G og WAL-E á sama tíma. Við styðjum afturábak eindrægni í þeim skilningi að WAL-G getur endurheimt skrá frá WAL-E og getur endurheimt öryggisafrit sem er gert í WAL-E. En þar sem bæði þessi kerfi nota samhliða wal-push byrja þau að stela skrám frá hvort öðru. Ef við lagum það í WAL-G verður það áfram í WAL-E. Í WAL-E skoðar það skjalastöðu, sér fullunnar skrár og setur þær í geymslu, á meðan önnur kerfi munu einfaldlega ekki vita að þessi WAL skrá hafi verið til, því PostgreSQL mun ekki reyna að geyma hana í annað sinn.
Hvað ætlum við að laga hér á WAL-G hliðinni? Við munum ekki upplýsa PostgreSQL um að þessi skrá hafi verið flutt samhliða, og þegar PostgreSQL biður okkur um að geyma hana, munum við nú þegar vita að slík skrá með þessum ham-tíma og með þessum md5 hefur þegar verið sett í geymslu og við munum einfaldlega segja PostgreSQL - Allt í lagi, allt er tilbúið án þess að gera neitt í rauninni.
En ólíklegt er að þetta vandamál verði lagað á WAL-E hliðinni, svo það er sem stendur ómögulegt að búa til skjalasafnsskipun sem geymir skrána í bæði WAL-G og WAL-E.
Að auki eru dæmi um að WAL-G hentar þér ekki núna, en við munum örugglega laga það.
Í fyrsta lagi erum við ekki með innbyggða öryggisafritunarstaðfestingu eins og er. Við höfum ekki staðfestingu hvorki meðan á öryggisafriti né endurheimt stendur. Auðvitað er þetta útfært í skýinu. En þetta er útfært einfaldlega með því að athuga fyrirfram, einfaldlega með því að endurheimta klasann. Mig langar að gefa notendum þessa virkni. En með sannprófun geri ég ráð fyrir að í WAL-G verði hægt að endurheimta klasann og ræsa hann og keyra reykpróf: pg_dumpall til /dev/null og amcheck index verification.
Eins og er í WAL-G er engin leið að fresta einu öryggisafriti frá WAL. Það er, við styðjum einhvern glugga. Til dæmis að geyma síðustu sjö daga, geyma síðustu tíu afritin, geyma síðustu þrjú fullu afritin. Oft kemur fólk og segir: „Við þurfum öryggisafrit af því sem gerðist um áramótin og við viljum halda því að eilífu. WAL-G veit ekki enn hvernig á að gera þetta. (Athugið - Þetta hefur þegar verið lagað. Lesa meira - Backup-mark valkostur í )
Og við erum ekki með síðuathugunarsummur og heilleikaathuganir fyrir alla skafthluta þegar PITR er staðfest.
Úr öllu þessu setti ég saman verkefni fyrir Google Summer of Code. Ef þú þekkir snjalla nemendur sem vilja skrifa eitthvað í Go og fá nokkur þúsund dollara frá einu fyrirtæki með bókstafnum „G“, þá mælið með verkefninu okkar við þá. Ég mun vera leiðbeinandi fyrir þetta verkefni, þeir geta það. Ef það eru engir nemendur þá tek ég það og geri það sjálfur í sumar.
Og við erum með mörg önnur smá vandamál sem við erum smám saman að vinna í. Og nokkuð undarlegir hlutir gerast.
Til dæmis, ef þú gefur WAL-G tómt öryggisafrit, mun það einfaldlega falla. Til dæmis, ef þú segir honum að hann þurfi að taka öryggisafrit af tómri möppu. pg_control skráin verður ekki þar. Og hann mun halda að hann skilji ekki eitthvað. Í orði, í þessu tilfelli þarftu að skrifa venjuleg skilaboð til notandans til að útskýra fyrir honum hvernig á að nota tólið. En þetta er ekki einu sinni eiginleiki forritunar, heldur eiginleiki góðs, skiljanlegs tungumáls.
Við vitum ekki hvernig á að gera öryggisafrit án nettengingar. Ef gagnagrunnurinn er að ljúga getum við ekki tekið öryggisafrit af honum. En hér er allt mjög einfalt. Við köllum öryggisafrit af LSN þegar það byrjaði. Lesa verður LSN undirliggjandi grunns úr stjórnskránni. Og þetta er svo óverjandi eiginleiki. Mörg varakerfi geta tekið afrit af undirliggjandi gagnagrunni. Og það er þægilegt.
Sem stendur getum við ekki séð almennilega um skort á öryggisafritunarrými. Vegna þess að við vinnum venjulega með stór afrit heima. Og þeir komust ekki að því. En ef einhver vill forrita í Go núna, bætið þá meðhöndlun fyrir villur utan pláss í fötuna. Ég mun örugglega skoða dráttarbeiðnina.
Og það helsta sem veldur okkur áhyggjum er að við viljum hafa eins mörg samþættingarpróf fyrir bryggju og mögulegt er sem athuga mismunandi aðstæður. Núna erum við aðeins að prófa grunnatburðarás. Við hverja skuldbindingu, en við viljum athuga skuldbindingu fyrir skuldbindingu alla þá virkni sem við styðjum. Sérstaklega munum við til dæmis hafa nægan stuðning fyrir PostgreSQL 9.4-9.5. Við styðjum þá vegna þess að samfélagið styður PostgreSQL, en við athugum ekki skuldbindingu fyrir skuldbindingu til að tryggja að allt sé ekki bilað. Og mér sýnist þetta vera frekar alvarleg hætta.
Við erum með WAL-G í gangi á meira en þúsund þyrpingum í Yandex gagnagrunnsstjórnun. Og það tekur afrit af nokkur hundruð terabætum af gögnum á hverjum degi.
Við höfum mikið af TODO í kóðanum okkar. Ef þú vilt forrita, komdu, við bíðum eftir dráttarbeiðnum, við bíðum eftir spurningum.
spurningar
Gott kvöld! Þakka þér fyrir! Ég giska á að ef þú ert að nota WAL-delta, þá ertu líklega að treysta mjög á heilsíðuskrif. Og ef svo er, fórstu í próf? Þú sýndir fallegt graf. Hversu miklu fallegra verður það ef slökkt er á FPW?
Heilsíðuskrif er virkt fyrir okkur, við höfum ekki reynt að slökkva á því. Það er, ég sem verktaki hef ekki reynt að slökkva á því. Kerfisstjórar sem hafa rannsakað hafa líklega rannsakað þetta mál. En við þurfum FPW. Næstum enginn gerir það óvirkt, því annars er ómögulegt að taka öryggisafrit af eftirmynd.
Takk fyrir skýrsluna! Ég er með tvær spurningar. Fyrsta spurningin er hvað verður um borðrými?
Við bíðum eftir dráttarbeiðni. Gagnagrunnar okkar búa á SSD og NMVE diskum og við þurfum í raun ekki þennan eiginleika. Ég er ekki tilbúin til að eyða alvarlegum tíma núna í að gera það vel. Ég mæli heilshugar fyrir því að við styðjum þetta. Það er fólk sem studdi það, en studdi það á þann hátt sem þeim hentar. Þeir bjuggu til gaffal, en þeir gera ekki dráttarbeiðnir. (Bætt við í útgáfu 0.2.13)
Og seinni spurningin. Þú sagðir strax í upphafi að WAL-G geri ráð fyrir að það virki eitt og sér og engar umbúðir séu nauðsynlegar. Ég nota sjálf umbúðir. Af hverju ætti ekki að nota þær?
Við viljum að það sé eins einfalt og balalaika. Þetta þýðir að þú þarft alls ekki neitt nema balalaika. Við viljum að kerfið sé einfalt. Ef þú ert með virkni sem þú þarft að gera í handriti, komdu og segðu okkur - við gerum það í Go.
Gott kvöld! Takk fyrir skýrsluna! Okkur tókst ekki að fá WAL-G til að vinna með GPG afkóðun. Það dulkóðar venjulega, en vill ekki afkóða. Er það eitthvað sem virkaði ekki fyrir okkur? Ástandið er niðurdrepandi.
Búðu til mál á GitHub og við skulum reikna út það.
Semsagt, þú hefur ekki lent í þessu?
Það er eiginleiki villuskýrslunnar að þegar WAL-G skilur ekki hvers konar skrá það er, þá spyr það: "Kannski er hún dulkóðuð?" Kannski er vandamálið alls ekki dulkóðun. Ég vil bæta skráningu á þessu efni. Hann verður að ráða það. Við erum núna að vinna að þessu efni í þeim skilningi að okkur líkar ekki hvernig kerfið til að fá opinbera og einkalykla er skipulagt. Vegna þess að við köllum ytri GPG þannig að það gefur okkur lyklana sína. Og svo tökum við þessa lykla og flytjum þá yfir á innri GPG, sem er opinn PGP, sem er settur saman fyrir okkur inni í WAL-G og þar köllum við dulkóðun. Í þessu sambandi viljum við bæta kerfið og viljum styðja Libsodium dulkóðun (Bætt við í útgáfu 0.2.15). Auðvitað ætti afkóðun að virka, við skulum reikna það út - þú þarft meira einkenni en nokkur orð. Þú getur safnast saman í herbergi ræðumannsins einhvern tíma og skoðað kerfið. (PGP dulkóðun án ytri GPG - v0.2.9)
Halló! Takk fyrir skýrsluna! Ég er með tvær spurningar. Ég hef undarlega löngun til að gera pg_basebackup og WAL innskráningu á tveimur veitum, þ.e.a.s. ég vil gera eitt ský og annað. Er einhver leið til að gera þetta?
Þetta er ekki til núna, en þetta er áhugaverð hugmynd.
Ég bara treysti ekki einum þjónustuaðila, ég vil hafa það sama hjá öðrum, bara ef það er til staðar.
Hugmyndin er áhugaverð. Tæknilega séð er þetta alls ekki erfitt í framkvæmd. Til að koma í veg fyrir að hugmyndin glatist, get ég beðið þig um að gera mál á GitHub?
Já auðvitað.
Og svo, þegar nemendur koma á Google Summer of Code, munum við bæta þeim við verkefnið þannig að það sé meiri vinna við að fá meira út úr þeim.
Og seinni spurningin. Það er vandamál á GitHub. Ég held að það sé þegar lokað. Það eru læti við endurreisn. Og til að sigra það, gerðir þú sérstakt þing. Það er rétt í málum. Og það er möguleiki að gera breytilegt umhverfi í einum þræði. Og þess vegna virkar þetta mjög hægt. Og við lentum í þessu vandamáli og það hefur ekki verið lagað ennþá.
Vandamálið er að af einhverjum ástæðum endurstillir geymslan (CEPH) tenginguna þegar við komum að henni með mikilli samhliða. Hvað er hægt að gera í þessu? Rökfræðin til að reyna aftur lítur svona út. Við erum að reyna að hlaða niður skránni aftur. Í einni umferð var fjöldi skráa ekki hlaðinn niður, við munum búa til aðra fyrir alla þá sem ekki skráðu sig inn. Og svo lengi sem að minnsta kosti ein skrá er hlaðin í hverri endurtekningu, endurtökum við og endurtökum og endurtökum. Við bættum rökfræði endurreynslu - veldisvísis bakslags. En það er ekki alveg ljóst hvað á að gera við þá staðreynd að tengingin rofnar einfaldlega á hlið geymslukerfisins. Það er að segja að þegar við hlaðum upp í einn straum, þá rjúfa það ekki þessar tengingar. Hvað getum við bætt hér? Við erum með netinngjöf, við getum takmarkað hverja tengingu við fjölda bæta sem hún sendir. Annars veit ég ekki hvernig ég á að takast á við þá staðreynd að hlutgeymsla leyfir okkur ekki að hlaða niður eða hlaða niður af henni samhliða.
Ekkert SLA? Er ekki skrifað fyrir þá hvernig þeir leyfa sér að kveljast?
Málið er að fólk sem kemur með þessa spurningu hefur yfirleitt sína eigin hvelfingu. Það er, enginn kemur frá Amazon eða Google Cloud eða Yandex Object Storage.
Kannski er spurningin ekki lengur fyrir þig?
Spurningin hér í þessu máli skiptir ekki máli fyrir hvern. Ef það eru einhverjar hugmyndir um hvernig eigi að bregðast við þessu, þá skulum við gera það í WAL-G. En enn sem komið er hef ég engar góðar hugmyndir um hvernig eigi að bregðast við þessu. Það eru nokkur Object Storage sem styðja skráningu afrita á annan hátt. Þú biður þá um að skrá hluti og þeir bæta við möppu þar. WAL-G verður hræddur við þetta - það er einhvers konar hlutur hér sem er ekki skrá, ég get ekki endurheimt hana, sem þýðir að öryggisafritið var ekki endurheimt. Það er í raun, þú ert með algjörlega endurheimtan þyrping, en það skilar þér rangri stöðu vegna þess að Object Storage skilaði einhverjum undarlegum upplýsingum sem það skildi ekki til fulls.
Þetta er hlutur sem gerist í póstskýinu.
Ef þú getur byggt upp endurgerð...
Það er stöðugt endurskapað ...
Ef það er endurgerð, þá held ég að við munum gera tilraunir með aðferðir til að reyna aftur og finna út hvernig á að reyna aftur og skilja hvað skýið krefst af okkur. Kannski verður það stöðugt fyrir okkur á þremur tengingum og mun ekki rjúfa tenginguna, þá náum við varlega þremur. Vegna þess að núna sleppum við tengingunni mjög fljótt, þ.e.a.s. ef við settum af stað endurheimt með 16 þræði, þá verða eftir fyrstu tilraunina 8 þræðir, 4 þræðir, 2 þræðir og einn. Og þá mun það draga skrána í einn straum. Ef það eru einhver töfragildi eins og 7,5 þræðir eru bestir til að dæla, þá munum við dvelja við þau og reyna að búa til aðra 7,5 þræði. Hér er hugmynd.
Takk fyrir skýrsluna! Hvernig lítur fullkomið verkflæði út til að vinna með WAL-G? Til dæmis, í því heimskulega tilfelli þegar það er engin delta yfir síður. Og við tökum og fjarlægjum upphaflega öryggisafritið, geymum síðan skaftið þar til við erum blá í andlitinu. Hér er, eins og ég skil það, bilun. Á einhverjum tímapunkti þarftu að gera delta öryggisafrit af síðum, þ.e.a.s. eitthvað utanaðkomandi ferli rekur þetta eða hvernig gerist þetta?
Delta öryggisafrit API er frekar einfalt. Það er númer þarna - max delta skref, það er það sem það er kallað. Það er sjálfgefið núll. Þetta þýðir að í hvert skipti sem þú gerir öryggisafrit, hleður það niður fullu afriti. Ef þú breytir því í einhverja jákvæða tölu, til dæmis 3, þá skoðar það sögu fyrri afrita næst þegar þú gerir öryggisafrit. Hann sér að þú ferð ekki yfir keðjuna af 3 deltas og gerir delta.
Það er, í hvert skipti sem við ræsum WAL-G, reynir það að gera fullt öryggisafrit?
Nei, við keyrum WAL-G og það reynir að búa til delta ef reglur þínar leyfa það.
Í grófum dráttum, ef þú keyrir það með núll í hvert skipti, mun það haga sér eins og pg_basebackup?
Nei, það mun samt keyra hraðar vegna þess að það notar þjöppun og samsíða. Pg_basebackup mun setja skaftið við hliðina á þér. WAL-G gerir ráð fyrir að þú hafir stillt geymslu. Og það mun gefa út viðvörun ef það er ekki stillt.
Pg_basebackup er hægt að keyra án skafta.
Já, þá munu þeir haga sér nánast eins. Pg_basebackup afritar í skráarkerfið. Við the vegur, við erum með nýja eiginleika sem ég gleymdi að nefna. Við getum nú afritað í skráarkerfið frá pg_basebackup. Ég veit ekki hvers vegna þetta er þörf, en það er til staðar.
Til dæmis á CephFS. Ekki vilja allir stilla Object Storage.
Já, það er líklega ástæðan fyrir því að þeir spurðu spurningar um þennan eiginleika svo að við gætum gert það. Og við gerðum það.
Takk fyrir skýrsluna! Það er bara spurning um að afrita í skráarkerfið. Upp úr kassanum, styður þú núna afritun í fjargeymslu, til dæmis ef það er einhver hilla í gagnaverinu eða eitthvað annað?
Í þessari samsetningu er þetta erfið spurning. Já, við styðjum, en þessi virkni er ekki innifalin í neinni útgáfu ennþá. Það er að segja allar forútgáfur styðja þetta, en útgáfuútgáfurnar gera það ekki. Þessari virkni var bætt við í útgáfu 0.2. Það mun örugglega koma út fljótlega, um leið og við lagfærum allar þekktar villur. En núna er þetta aðeins hægt að gera í forútgáfu. Það eru tvær villur í forútgáfunni. Vandamál með WAL-E endurheimt, við höfum ekki lagað það. Og í nýjustu forútgáfu var villu um delta-afritun bætt við. Þess vegna mælum við með því að allir noti útgáfuútgáfurnar. Um leið og það eru engar fleiri villur í forútgáfunni getum við sagt að við styðjum Google Cloud, S3-samhæfða hluti og skráageymslu.
Halló, takk fyrir skýrsluna. Eins og ég skil það er WAL-G ekki einhvers konar miðstýrt kerfi eins og barmenn? Ætlar þú að fara í þessa átt?
Vandamálið er að við höfum fjarlægst þessa átt. WAL-G lifir á grunnhýsilnum, á klasahýsilnum og á öllum hýslum í klasanum. Þegar við fluttum í nokkur þúsund klasa vorum við með margar barþjónauppsetningar. Og í hvert sinn sem eitthvað dettur í sundur í þeim er það mikið vandamál. Vegna þess að það þarf að gera við þá þarftu að skilja hvaða klasar eru nú ekki með afrit. Ég ætla ekki að þróa WAL-G í átt að líkamlegum vélbúnaði fyrir varakerfi. Ef samfélagið vill einhverja virkni hérna þá er mér alveg sama.
Við erum með teymi sem sjá um geymslu. Og okkur líður svo vel að það erum ekki við, að það er sérstakt fólk sem setur skrárnar okkar þar sem skrárnar eru öruggar. Þeir gera alls kyns snjalla kóða þar til að standast tap á tilteknum fjölda skráa. Þeir bera ábyrgð á netbandbreidd. Þegar þú ert með barþjón geturðu allt í einu komist að því að litlir gagnagrunnar með mikla umferð hafa safnast saman á sama netþjóninum. Þú virðist hafa mikið pláss á því, en af einhverjum ástæðum passar allt ekki í gegnum netið. Það gæti farið á hinn veginn. Það er fullt af netum þarna, það eru örgjörvakjarna, en það eru engir diskar hér. Og við urðum þreytt á þessari þörf fyrir að laga eitthvað, og við færðum okkur yfir í þá staðreynd að gagnageymsla er sérstök þjónusta, sem sérstakir einstaklingar bera ábyrgð á.
PS Ný útgáfa hefur verið gefin út , þar sem þú getur notað .walg.json stillingarskrána, sem er sjálfgefið staðsett í postgres heimamöppunni. Þú getur yfirgefið bash forskriftir. Dæmi .walg.json er í þessu tölublaði
Video:
Heimild: www.habr.com