Ek stel voor jy lees die transkripsie van die verslag van die begin van 2019 deur Andrey Borodin "Rugsteune met WAL-G. Wat is daar in 2019?"
Hi almal! My naam is Andrey Borodin. Ek is 'n ontwikkelaar by Yandex. Ek stel al sedert 2016 belang in PostgreSQL, nadat ek met die ontwikkelaars gepraat het en hulle gesê het dat alles eenvoudig is – jy neem die bronkode en bou dit, en alles sal uitwerk. En sedertdien kan ek nie ophou nie - ek skryf allerhande verskillende dinge.
Een van die dinge waaraan ek werk, is 'n rugsteunstelsel. . Oor die algemeen werk ons by Yandex al baie lank aan rugsteunstelsels in PostgreSQL. En jy kan op die internet 'n reeks van ses verslae kry oor hoe ons rugsteunstelsels maak. En elke jaar ontwikkel hulle 'n bietjie, ontwikkel 'n bietjie en word meer betroubaar.
Maar vandag gaan die verslag nie net oor wat ons gedoen het nie, maar ook oor hoe eenvoudig dit is en wat is. Hoeveel van julle het al na my verslae oor WAL-G gekyk? Dit is goed dat 'n hele paar mense nie gekyk het nie, want ek begin met die eenvoudigste ding.
As jy skielik 'n PostgreSQL-kluster het, en ek dink almal het 'n paar van hulle by hulle, en daar is skielik nog geen rugsteunstelsel nie, dan moet jy enige S3-berging of Google Cloud-versoenbare berging kry.
U kan byvoorbeeld na ons staanplek kom en 'n promosiekode neem vir Yandex Object Storage, wat S3-versoenbaar is.
Skep dan 'n emmer. Dit is net 'n houer vir inligting.
Skep 'n diensgebruiker.
Skep 'n toegangsleutel vir die diensgebruiker: aws-s3-key.
Laai die nuutste stabiele weergawe van WAL-G af.
Hoe verskil ons voorvrystellings van vrystellings? Ek word dikwels gevra om vroeg vry te laat. En as daar geen fout in die weergawe is vir 'n voldoende tyd nie, byvoorbeeld 'n maand, dan stel ek dit vry. Hier is hierdie vrystelling van November. En dit beteken dat ons elke maand 'n soort fout gevind het, gewoonlik in nie-kritiese funksionaliteit, maar ons het nog nie 'n vrystelling vrygestel nie. Die vorige weergawe is eers November. Daar is geen foute aan ons bekend daarin nie, dit wil sê foute is bygevoeg soos die projek gevorder het.
Sodra jy WAL-G afgelaai het, kan jy 'n eenvoudige "rugsteunlys"-opdrag uitvoer deur die omgewingsveranderlikes deur te gee. En dit sal aan Object Storage koppel en jou vertel watter rugsteun jy het. Aanvanklik moet jy natuurlik nie rugsteun hê nie. Die punt van hierdie skyfie is om te wys dat alles redelik eenvoudig is. Dit is 'n konsole-opdrag wat omgewingsveranderlikes aanvaar en subopdragte uitvoer.
Hierna kan jy jou eerste rugsteun maak. Sê "backup-push" in WAL-G en spesifiseer in WAL-G die pgdata-ligging van jou groepering. En heel waarskynlik, PostgreSQL sal jou vertel, as jy nie reeds 'n rugsteunstelsel het nie, dat jy "argiefmodus" moet aktiveer.
Dit beteken dat jy na instellings moet gaan en "archive_mode = on" moet aanskakel en "archive_command" moet byvoeg, wat ook 'n subopdrag in WAL-G is. Maar om een of ander rede gebruik mense dikwels staafskrifte oor hierdie onderwerp en draai dit om WAL-G. Moet asseblief nie dit doen nie. Gebruik die funksionaliteit wat in WAL-G gevind word. As jy iets mis, skryf aan . WAL-G neem aan dat dit die enigste program is wat in archive_command loop.
Ons gebruik WAL-G hoofsaaklik om 'n Hoë Beskikbaarheid-kluster in Yandex-databasisbestuur te skep.
En dit word gewoonlik gebruik in 'n topologie van een Meester en verskeie replikasies. Terselfdertyd maak dit 'n rugsteunkopie in Yandex Object Storage.
Die mees algemene scenario's is om kopieë van 'n groepering te skep met behulp van punt-in-tyd-herstel. Maar in hierdie geval is die werkverrigting van die rugsteunstelsel nie so belangrik vir ons nie. Ons moet net 'n nuwe groepie vanaf die rugsteun oplaai.
Tipies het ons rugsteunstelselwerkverrigting nodig wanneer 'n nuwe nodus bygevoeg word. Hoekom is dit belangrik? Tipies voeg mense 'n nuwe nodus by 'n groepering omdat die bestaande groep nie die leeslading kan hanteer nie. Hulle moet 'n nuwe replika byvoeg. As ons die las vanaf pg_basebackup by die Meester voeg, kan die Meester ineenstort. Daarom was dit vir ons baie belangrik dat ons vinnig 'n nuwe nodus uit die argief kon oplaai, wat minimale las op die Meester skep.
En nog 'n soortgelyke situasie. Dit is die behoefte om die ou Meester te herbegin nadat die Cluster Master oorgeskakel is vanaf die datasentrum waarmee konneksie verloor is.
- As gevolg hiervan, toe ons die vereistes vir die kopiestelsel geformuleer het, het ons besef dat pg_basebackup nie geskik is vir ons wanneer ons in die wolk werk nie.
- Ons wou ons data kon saamdruk. Maar byna enige rugsteunstelsel behalwe wat in die boks kom, sal datakompressie verskaf.
- Ons wou alles paralleliseer omdat 'n gebruiker in die wolk 'n groot aantal verwerkerkerne koop. Maar as ons nie parallelisme in een of ander operasie het nie, dan word 'n groot aantal kerne nutteloos.
- Ons het enkripsie nodig, want die data is dikwels nie ons s'n nie en kan nie in duidelike teks gestoor word nie. Terloops, ons bydrae tot WAL-G het begin met enkripsie. Ons het die enkripsie in WAL-G voltooi, waarna ons gevra is: "Miskien sal een van ons die projek ontwikkel?" En sedertdien werk ek al meer as 'n jaar saam met WAL-G.
- Ons het ook hulpbronversperring nodig gehad, want met verloop van tyd met behulp van die wolk, het ons uitgevind dat mense soms 'n belangrike kruidenierswarevrag in die nag het en met hierdie vrag kan nie ingemeng word nie. Daarom het ons hulpbronversperring bygevoeg.
- Sowel as notering en bestuur.
- En verifikasie.
Ons het na baie verskillende gereedskap gekyk. Gelukkig het ons 'n groot keuse in PostgreSQL. En oral het ons iets gemis, een of ander klein funksie, een of ander een klein kenmerk.
En nadat ons die bestaande stelsels ondersoek het, het ons tot die gevolgtrekking gekom dat ons WAL-G sal ontwikkel. Dit was toe ’n nuwe projek. Dit was redelik maklik om die ontwikkeling na die wolkinfrastruktuur van die rugsteunstelsel te beïnvloed.
Die hoofideologie waaraan ons voldoen, is dat WAL-G so eenvoudig soos 'n balalaika moet wees.
WAL-G het 4 opdragte. Dit:
WAL-PUSH – argiveer die skag.
WAL-FETCH – kry 'n skag.
BACKUP-PUSH – maak 'n rugsteun.
BACKUP-HAAL – kry 'n rugsteun vanaf die rugsteunstelsel.
Trouens, WAL-G het ook die bestuur van hierdie rugsteun, dit wil sê om rekords en rugsteune in die geskiedenis te lys en uit te vee wat op die oomblik nie meer nodig is nie.
Een van die belangrike funksies vir ons is die funksie om delta-kopieë te skep.
Delta-kopieë beteken dat ons nie 'n volledige rugsteun van die hele groep skep nie, maar slegs die veranderde bladsye van die veranderde lêers in die groep. Dit wil voorkom asof dit funksioneel baie soortgelyk is aan die vermoë om met WAL te herstel. Maar ons kan 'n WAL enkel-draad delta rugsteun in parallel oprol. Gevolglik, wanneer ons 'n basiese rugsteun op Saterdag maak, delta-rugsteun daagliks, en Donderdag misluk ons, dan moet ons 4 delta-rugsteun en 10 uur se WAL oprol. Dit sal ongeveer dieselfde tyd neem omdat die delta-rugsteun in parallel rol.
LSN-gebaseerde deltas - dit beteken dat wanneer ons 'n rugsteun skep, ons elke bladsy moet kombineer en sy LSN met die LSN van die vorige rugsteun moet kontroleer om te verstaan dat dit verander het. Enige bladsy wat moontlik veranderde data kan bevat, moet teenwoordig wees in die delta-rugsteun.
Soos ek gesê het, is nogal baie aandag aan parallelisme gegee.
Maar die argief-API in PostgreSQL is konsekwent. PostgreSQL argiveer een WAL-lêer en versoek een WAL-lêer wanneer dit herstel word. Maar wanneer die databasis een WAL-lêer versoek deur die "WAL-FETCH"-opdrag te gebruik, roep ons die "WAL-PREFETCH"-opdrag, wat die volgende 8 lêers voorberei om data van die objekstoor parallel te gaan haal.
En wanneer die databasis ons vra om een lêer te argiveer, kyk ons na archive_status en kyk of daar ander WAL-lêers is. En ons probeer ook om WAL parallel af te laai. Dit bied 'n aansienlike prestasiewins en verminder die afstand in die aantal ongeargiveerde WAL's aansienlik. Baie rugsteunstelselontwikkelaars glo dat dit so 'n riskante stelsel is omdat ons staatmaak op ons kennis van die interne van kode wat nie die PostgreSQL API is nie. PostgreSQL waarborg nie die teenwoordigheid van die archive_status-lêergids vir ons nie en waarborg nie die semantiek, die teenwoordigheid van gereedheidsseine vir WAL-lêers daar nie. Nietemin, ons bestudeer die bronkode, ons sien dat dit so is en ons probeer dit uitbuit. En ons beheer die rigting waarin PostgreSQL ontwikkel; as hierdie meganisme skielik gebreek word, sal ons ophou om dit te gebruik.
In sy suiwer vorm vereis LSN-gebaseerde WAL delta die lees van enige groeplêer waarvan die modustyd in die lêerstelsel verander het sedert die vorige rugsteun. Ons het lank hiermee saamgeleef, amper 'n jaar. En op die ou end het ons tot die gevolgtrekking gekom dat ons WAL-deltas het.
Dit beteken dat elke keer as ons WAL op die Meester argiveer, ons dit nie net saamdruk, enkripteer en na die netwerk stuur nie, maar ons lees dit ook terselfdertyd. Ons ontleed en lees die rekords daarin. Ons verstaan watter blokke verander het en versamel delta-lêers.
'n Delta-lêer beskryf 'n sekere reeks WAL-lêers, beskryf inligting oor watter blokke in hierdie reeks WAL verander is. En dan word hierdie delta-lêers ook geargiveer.
Hier word ons gekonfronteer met die feit dat ons alles redelik vinnig geparallaliseer het, maar ons kan nie 'n opeenvolgende geskiedenis parallel lees nie, want in 'n sekere segment kan ons die einde van die vorige WAL-rekord teëkom, wat ons nog niks het om mee te verbind nie, want parallelle lees het daartoe gelei dat ons eers die toekoms, wat nog nie 'n verlede het nie, ontleed.
As gevolg hiervan moes ons onverstaanbare stukke in _delta_partial lêers plaas. As gevolg hiervan, wanneer ons terugkeer na die verlede, sal ons die stukke van die WAL-rekord in een plak, daarna sal ons dit ontleed en verstaan wat daarin verander het.
As daar in die geskiedenis van ons skagontleding ten minste een punt is waar ons nie verstaan wat gebeur het nie, dan sal ons dienooreenkomstig tydens die volgende rugsteun gedwing word om die hele groep weer te lees, net soos ons met 'n gewone LSN gedoen het. -gebaseerde delta.
Gevolglik het al ons lyding daartoe gelei dat ons die WAL-G-ontledingsbiblioteek oopbronverkoop het. Sover ek weet gebruik niemand dit nog nie, maar as iemand dit wil, skryf en gebruik, is dit in die publieke domein. (Opgedateerde skakel )
Gevolglik lyk alle inligtingvloei redelik ingewikkeld. Ons Meester argiveer die skag en argiveer deltalêers. En die replika wat die rugsteunkopie maak, moet delta-lêers ontvang gedurende die tyd wat tussen rugsteun verloop het. In hierdie geval sal dele van die geskiedenis in grootmaat bygevoeg en ontleed moet word, want nie die hele geskiedenis pas in groot segmente nie. En eers hierna kan die replika 'n volledige delta-rugsteun argiveer.
Op die grafieke lyk alles baie eenvoudiger. Dit is 'n aflaai vanaf een van ons regte groepe. Ons het LSN-gebaseerde, gemaak in een dag. En ons sien dat die LSN-gebaseerde delta-rugsteun van drie in die oggend tot vyf in die oggend aan die gang was. Dit is die las in die aantal verwerkerkerne. WAL-delta het ons hier ongeveer 20 minute geneem, dit wil sê, dit het aansienlik vinniger geword, maar terselfdertyd was daar 'n meer intense uitruiling oor die netwerk.
Aangesien ons inligting het oor watter blokke verander het en op watter tydstip in die geskiedenis van die databasis, het ons verder gegaan en besluit om funksionaliteit te integreer - 'n PostgreSQL-uitbreiding genaamd "pg_prefaulter"
Dit beteken dat wanneer die bystandbasis die herstelopdrag uitvoer, dit vir WAL-G sê om die volgende WAL-lêer te gaan haal. Ons verstaan ongeveer tot watter datablokke die WAL-herstelproses in die nabye toekoms toegang sal verkry en begin 'n leesbewerking op hierdie blokke. Dit is gedoen om die werkverrigting van SSD-beheerders te verhoog. Omdat die WAL-rol die bladsy sal bereik wat verander moet word. Hierdie bladsy is op skyf en is nie in die bladsykas nie. En hy sal sinchronies wag vir hierdie bladsy om te arriveer. Maar naby is WAL-G, wat weet dat ons in die volgende paar honderd megagrepe van WAL sekere bladsye sal benodig en terselfdertyd begin om dit op te warm. Inisieer verskeie skyftoegange sodat hulle parallel uitgevoer word. Dit werk goed op SSD-aandrywers, maar ongelukkig is dit absoluut nie van toepassing op 'n hardeskyf nie, want ons meng net daarmee in met ons opdragte.
Dit is wat nou in die kode is.
Daar is kenmerke wat ons graag wil byvoeg.
Hierdie prent wys dat WAL-delta 'n relatief kort tyd neem. En dit is die lees van die veranderinge wat gedurende die dag in die databasis plaasgevind het. Ons kan WAL-delta nie net in die nag doen nie, want dit is nie meer 'n beduidende bron van las nie. Ons kan elke minuut WAL-delta lees, want dit is goedkoop. In een minuut kan ons al die veranderinge wat aan die groep plaasgevind het, skandeer. En dit kan "instant WAL-delta" genoem word.
Die punt is dat wanneer ons die groep herstel, ons die aantal stories verminder wat ons opeenvolgend moet oprol. Dit wil sê, die hoeveelheid WAL wat PostgreSQL rol, moet verminder word, want dit neem aansienlike tyd.
Maar dit is nie al nie. As ons weet dat een of ander blok verander sal word tot die punt van rugsteunkonsekwentheid, kan ons dit nie in die verlede verander nie. Dit wil sê, nou het ons lêer-vir-lêer-optimalisering van WAL-delta-aanstuur. Dit beteken dat as, byvoorbeeld, op Dinsdag 'n tabel heeltemal uitgevee is of sommige lêers heeltemal uit die tabel geskrap is, dan wanneer delta op Maandag oorrol en Saterdag se pg_basebackup herstel word, sal ons nie eers hierdie data skep nie.
Ons wil hierdie tegnologie uitbrei na die bladsyvlak. Dit wil sê, as 'n deel van die lêer op Maandag verander, maar op Woensdag oorgeskryf sal word, hoef ons nie die eerste paar weergawes van bladsye na 'n skyf te skryf wanneer ons Donderdag na 'n punt herstel nie.
Maar dit is steeds 'n idee wat aktief in ons bespreek word, maar dit het nog nie die kode bereik nie.
Ons wil nog een kenmerk in WAL-G maak. Ons wil dit uitbreidbaar maak omdat ons verskillende databasisse moet ondersteun en graag rugsteunbestuur op dieselfde manier wil kan benader. Maar die probleem is dat die MySQL API's radikaal verskil. In MySQL is PITR nie gebaseer op die fisiese WAL-logboek nie, maar op die binlog. En ons het nie 'n argiefstelsel in MySQL wat vir een of ander eksterne stelsel sal vertel dat hierdie binlog klaar is en geargiveer moet word nie. Ons moet iewers in cron met die databasis staan en kyk of daar iets gereed is?
En op dieselfde manier, tydens 'n MySQL-herstel, is daar geen herstelopdrag wat die stelsel kan vertel dat ek sulke en sulke lêers nodig het nie. Voordat jy begin om jou groep te herbou, moet jy weet watter lêers jy nodig het. U moet self raai watter lêers u benodig. Maar hierdie probleme kan dalk op een of ander manier omseil word. (Verduideliking: MySQL word reeds ondersteun)
In die berig wou ek ook praat oor daardie gevalle waar WAL-G nie vir jou geskik is nie.
As jy nie 'n sinchrone replika het nie, waarborg WAL-G nie dat die laaste segment bewaar sal word nie. En as argivering agter die laaste paar segmente van die geskiedenis bly, is dit 'n risiko. As daar geen sinchrone replika is nie, sal ek nie aanbeveel om WAL-G te gebruik nie. Tog is dit hoofsaaklik ontwerp vir 'n wolkinstallasie, wat 'n Hoë Beskikbaarheid-oplossing impliseer met 'n sinchrone replika, wat verantwoordelik is vir die veiligheid van die laaste grepe wat gepleeg is.
Ek sien dikwels mense wat beide WAL-G en WAL-E op dieselfde tyd probeer hardloop. Ons ondersteun terugwaartse versoenbaarheid in die sin dat WAL-G 'n lêer vanaf WAL-E kan herstel en 'n rugsteun wat in WAL-E gemaak is, kan herstel. Maar aangesien beide hierdie stelsels parallelle wal-stoot gebruik, begin hulle lêers van mekaar steel. As ons dit in WAL-G regmaak, sal dit steeds in WAL-E bly. In WAL-E kyk dit na argiefstatus, sien die voltooide lêers en argiveer dit, terwyl ander stelsels eenvoudig nie sal weet dat hierdie WAL-lêer bestaan het nie, want PostgreSQL sal dit nie 'n tweede keer probeer argiveer nie.
Wat gaan ons hier aan die WAL-G-kant regmaak? Ons sal nie vir PostgreSQL inlig dat hierdie lêer parallel oorgedra is nie, en wanneer PostgreSQL ons vra om dit te argiveer, sal ons reeds weet dat so 'n lêer met hierdie modus-tyd en met hierdie md5 reeds geargiveer is en ons sal eenvoudig sê PostgreSQL - OK, alles is gereed sonder om in wese iets te doen.
Maar dit is onwaarskynlik dat hierdie probleem aan die WAL-E-kant opgelos sal word, so dit is tans onmoontlik om 'n argiefopdrag te skep wat die lêer in beide WAL-G en WAL-E sal argiveer.
Daarbenewens is daar gevalle waar WAL-G nie nou vir jou geskik is nie, maar ons sal dit beslis regmaak.
Eerstens, ons het tans nie ingeboude rugsteunverifikasie nie. Ons het nie verifikasie tydens rugsteun of herstel nie. Natuurlik word dit in die wolk geïmplementeer. Maar dit word eenvoudig geïmplementeer deur vooraf na te gaan, bloot deur die groep te herstel. Ek wil graag hierdie funksionaliteit aan gebruikers gee. Maar deur verifikasie neem ek aan dat dit in WAL-G moontlik sal wees om die cluster te herstel en dit te begin, en rooktoetse uit te voer: pg_dumpall na /dev/null en amcheck indeksverifikasie.
Tans in WAL-G is daar geen manier om een rugsteun van WAL uit te stel nie. Dit wil sê, ons ondersteun een of ander venster. Byvoorbeeld, die stoor van die laaste sewe dae, die stoor van die laaste tien rugsteun, die stoor van die laaste drie volle rugsteun. Dikwels kom mense en sê: "Ons het 'n rugsteun nodig van wat op Nuwejaar gebeur het en ons wil dit vir altyd hou." WAL-G weet nog nie hoe om dit te doen nie. (Let wel - Dit is reeds reggestel. Lees meer - Rugsteunmerk opsie in )
En ons het nie bladsykontrolesomme en integriteitkontroles vir alle skagsegmente wanneer PITR bekragtig word nie.
Uit dit alles het ek 'n projek vir Google Summer of Code saamgestel. As jy slim studente ken wat graag iets in Go wil skryf en etlike duisende dollars van een maatskappy met die letter “G” wil kry, beveel dan ons projek vir hulle aan. Ek sal as mentor vir hierdie projek optree, hulle kan dit doen. As daar nie studente is nie, dan sal ek dit neem en dit self in die somer doen.
En ons het baie ander klein probleme waaraan ons geleidelik werk. En 'n paar redelik vreemde dinge gebeur.
Byvoorbeeld, as jy WAL-G 'n leë rugsteun gee, sal dit eenvoudig val. Byvoorbeeld, as jy vir hom sê dat hy 'n leë gids moet rugsteun. Die pg_control lêer sal nie daar wees nie. En hy sal dink dat hy iets nie verstaan nie. In teorie moet jy in hierdie geval 'n normale boodskap aan die gebruiker skryf om aan hom te verduidelik hoe om die instrument te gebruik. Maar dit is nie eers 'n kenmerk van programmering nie, maar 'n kenmerk van 'n goeie, verstaanbare taal.
Ons weet nie hoe om vanlyn rugsteun te doen nie. As die databasis lieg, kan ons dit nie rugsteun nie. Maar alles is baie eenvoudig hier. Ons noem rugsteun deur LSN toe dit begin het. Die LSN van die onderliggende basis moet vanaf die kontrolelêer gelees word. En dit is so 'n ongerealiseerde kenmerk. Baie rugsteunstelsels kan 'n onderliggende databasis rugsteun. En dit is gerieflik.
Ons kan tans nie die gebrek aan rugsteunspasie behoorlik hanteer nie. Want ons werk gewoonlik met groot rugsteun by die huis. En hulle het nie daarby uitgekom nie. Maar as iemand nou in Go wil programmeer, voeg hantering vir buite-spasie foute by die emmer. Ek sal beslis na die trekversoek kyk.
En die belangrikste ding wat ons bekommer, is dat ons soveel as moontlik dokker-integrasietoetse wil hê wat verskillende scenario's nagaan. Op die oomblik toets ons net basiese scenario's. Op elke commit, maar ons wil commit-vir-commit al die funksionaliteit wat ons ondersteun, nagaan. In die besonder sal ons byvoorbeeld genoeg ondersteuning hê vir PostgreSQL 9.4-9.5. Ons ondersteun hulle omdat die gemeenskap PostgreSQL ondersteun, maar ons kyk nie commit-by-commit na om seker te maak alles is nie stukkend nie. En dit lyk vir my of dit 'n taamlik ernstige risiko is.
Ons het WAL-G wat op meer as duisend groepe in Yandex-databasisbestuur loop. En dit rugsteun 'n paar honderd teragrepe data elke dag.
Ons het baie TODO in ons kode. As jy wil programmeer, kom, ons wag vir trekversoeke, ons wag vir vrae.
vrae
Goeienaand! Dankie! My raaiskoot is dat as jy WAL-delta gebruik, jy waarskynlik sterk staatmaak op volbladskrywes. En indien wel, het jy toetse gedoen? Jy het 'n pragtige grafiek gewys. Hoeveel mooier word dit as FPW afgeskakel is?
Volbladskryf is vir ons geaktiveer, ons het nie probeer om dit te deaktiveer nie. Dit wil sê, ek, as 'n ontwikkelaar, het nie probeer om dit af te skakel nie. Stelseladministrateurs wat nagevors het, het waarskynlik hierdie kwessie nagevors. Maar ons het FPW nodig. Byna niemand deaktiveer dit nie, want anders is dit onmoontlik om 'n rugsteun van 'n replika te neem.
Dankie vir die verslag! Ek het twee vrae. Die eerste vraag is wat sal met tablespaces gebeur?
Ons wag vir 'n trekversoek. Ons databasisse leef op SSD- en NMVE-skywe en ons het hierdie funksie nie regtig nodig nie. Ek is nie gereed om nou ernstig tyd daaraan te bestee om dit goed te doen nie. Ek bepleit heelhartig dat ons dit ondersteun. Daar is mense wat dit ondersteun het, maar dit ondersteun het op 'n manier wat hulle pas. Hulle het 'n vurk gemaak, maar hulle doen nie trekversoeke nie. (Bygevoeg in weergawe 0.2.13)
En die tweede vraag. Jy het heel aan die begin gesê dat WAL-G aanvaar dat dit alleen werk en geen omhulsels nodig is nie. Ek gebruik self omhulsels. Hoekom moet hulle nie gebruik word nie?
Ons wil hê dit moet so eenvoudig soos 'n balalaika wees. Dit beteken dat jy niks behalwe 'n balalaika nodig het nie. Ons wil hê die stelsel moet eenvoudig wees. As jy funksionaliteit het wat jy in 'n skrif moet doen, kom vertel ons dan - ons sal dit in Go doen.
Goeienaand! Dankie vir die verslag! Ons kon nie WAL-G kry om met GPG-dekripsie te werk nie. Dit enkripteer normaalweg, maar wil nie dekripteer nie. Is dit iets wat nie vir ons uitgewerk het nie? Die situasie is neerdrukkend.
Skep 'n probleem op GitHub en kom ons vind dit uit.
Dit wil sê, jy het dit nog nie teëgekom nie?
Daar is 'n kenmerk van die foutverslag dat wanneer WAL-G nie verstaan watter soort lêer dit is nie, dit vra: "Miskien is dit geïnkripteer?" Miskien is die probleem glad nie enkripsie nie. Ek wil die aanmelding oor hierdie onderwerp verbeter. Hy moet dit ontsyfer. Ons werk tans aan hierdie onderwerp in die sin dat ons nie regtig hou van hoe die stelsel vir die verkryging van publieke en private sleutels georganiseer is nie. Omdat ons eksterne GPG noem sodat dit vir ons sy sleutels gee. En dan neem ons hierdie sleutels en dra dit oor na die interne GPG, wat oop PGP is, wat vir ons binne WAL-G saamgestel is, en daar noem ons enkripsie. In hierdie verband wil ons die stelsel verbeter en wil ons Libsodium-enkripsie ondersteun (Bygevoeg in weergawe 0.2.15). Natuurlik moet dekodering werk, kom ons vind dit uit - jy het meer van 'n simptoom nodig as 'n paar woorde. Jy kan een of ander tyd in die spreker se kamer bymekaarkom en na die stelsel kyk. (PGP-enkripsie sonder eksterne GPG - v0.2.9)
Hallo! Dankie vir die verslag! Ek het twee vrae. Ek het 'n vreemde begeerte om pg_basebackup en WAL aan te meld by twee verskaffers, dit wil sê ek wil een wolk en 'n ander doen. Is daar 'n manier om dit te doen?
Dit bestaan nie nou nie, maar dit is 'n interessante idee.
Ek vertrou net nie een verskaffer nie, ek wil dieselfde in 'n ander hê, net vir ingeval.
Die idee is interessant. Tegnies is dit glad nie moeilik om te implementeer nie. Om te verhoed dat die idee verlore raak, kan ek jou vra om 'n probleem op GitHub te maak?
Ja natuurlik.
En dan, wanneer studente na Google Summer of Code kom, sal ons hulle by die projek voeg sodat daar meer werk is om meer uit hulle te kry.
En die tweede vraag. Daar is 'n probleem op GitHub. Ek dink dit is reeds gesluit. Daar is paniek tydens herstel. En om dit te verslaan, het jy 'n aparte vergadering gemaak. Dit is reg in kwessies. En daar is 'n opsie om 'n veranderlike omgewing in een draad te doen. En daarom werk dit baie stadig. En ons het hierdie probleem teëgekom, en dit is nog nie reggestel nie.
Die probleem is dat die berging (CEPH) om een of ander rede die verbinding terugstel wanneer ons met hoë gelyktydigheid daarby kom. Wat kan hieraan gedoen word? Die herprobeerlogika lyk so. Ons probeer om die lêer weer af te laai. In een pas het ons 'n aantal lêers wat nie afgelaai is nie, ons sal 'n tweede een maak vir almal wat nie aangemeld het nie. En solank as wat ten minste een lêer per iterasie gelaai word, herhaal ons en herhaal en herhaal. Ons het die logika van herprobeer verbeter - eksponensiële terugslag. Maar dit is nie heeltemal duidelik wat om te doen met die feit dat die verbinding eenvoudig aan die bergingstelselkant breek nie. Dit wil sê, wanneer ons na een stroom oplaai, breek dit nie hierdie verbindings nie. Wat kan ons hier verbeter? Ons het netwerkversperring, ons kan elke verbinding beperk deur die aantal grepe wat dit stuur. Andersins weet ek nie hoe om die feit te hanteer dat objekberging ons nie toelaat om parallel daarvan af te laai of af te laai nie.
Geen SLA nie? Is dit nie vir hulle geskryf hoe hulle toelaat dat hulle gepynig word nie?
Die punt is dat mense wat met hierdie vraag vorendag kom, gewoonlik hul eie kluis het. Dit wil sê, niemand kom van Amazon of Google Cloud of Yandex Object Storage nie.
Is die vraag dalk nie meer vir jou nie?
Die vraag hier in hierdie geval maak nie saak vir wie nie. As daar enige idees is oor hoe om dit te hanteer, kom ons doen dit in WAL-G. Maar tot dusver het ek geen goeie idees oor hoe om dit te hanteer nie. Daar is 'n paar Object Storage wat die lys van rugsteun anders ondersteun. Jy vra hulle om voorwerpe te lys, en hulle voeg vouer daar by. WAL-G raak bang hiervoor - daar is 'n soort ding hier wat nie 'n lêer is nie, ek kan dit nie herstel nie, wat beteken dat die rugsteun nie herstel is nie. Dit wil sê, jy het 'n heeltemal herstelde groepering, maar dit gee jou 'n foutiewe status omdat Object Storage 'n paar vreemde inligting teruggestuur het wat dit nie ten volle verstaan het nie.
Dit is iets wat in die Mail-wolk gebeur.
As jy 'n reproduksie kan bou...
Dit word konsekwent weergegee ...
As daar 'n reproduseer is, dan dink ek ons sal eksperimenteer met herprobeerstrategieë en uitvind hoe om weer te probeer en te verstaan wat die wolk van ons vereis. Miskien sal dit vir ons stabiel wees op drie verbindings en sal nie die verbinding verbreek nie, dan sal ons versigtig drie bereik. Want nou los ons die verbinding baie vinnig, dit wil sê as ons 'n herstel met 16 drade begin het, sal daar na die eerste herprobering 8 drade, 4 drade, 2 drade en een wees. En dan sal dit die lêer in een stroom trek. As daar 'n paar magiese waardes is, soos 7,5 drade is die beste om te pomp, dan sal ons daaroor stilstaan en probeer om nog 7,5 drade te maak. Hier is 'n idee.
Dankie vir die verslag! Hoe lyk 'n volledige werkvloei om met WAL-G te werk? Byvoorbeeld, in die dom geval wanneer daar geen delta oor bladsye is nie. En ons neem en verwyder die aanvanklike rugsteun, en argiveer dan die skag totdat ons blou in die gesig is. Hier, soos ek verstaan, is daar 'n ineenstorting. Op 'n stadium moet jy 'n delta-rugsteun van bladsye maak, d.w.s. 'n eksterne proses dryf dit of hoe gebeur dit?
Die delta-rugsteun-API is redelik eenvoudig. Daar is 'n nommer daar - maksimum delta stappe, dit is wat dit genoem word. Dit is verstek na nul. Dit beteken dat elke keer as jy 'n rugsteundruk doen, dit 'n volledige rugsteun aflaai. As jy dit verander na enige positiewe getal, byvoorbeeld 3, dan kyk dit die volgende keer as jy 'n rugsteundruk doen na die geskiedenis van vorige rugsteun. Hy sien dat jy nie die ketting van 3 deltas oorskry nie en maak 'n delta.
Dit wil sê, elke keer as ons WAL-G begin, probeer dit om 'n volledige rugsteun te maak?
Nee, ons bestuur WAL-G, en dit probeer om 'n delta te maak as jou beleid dit toelaat.
Rofweg gesproke, as jy dit elke keer met nul laat loop, sal dit optree soos pg_basebackup?
Nee, dit sal steeds vinniger loop omdat dit kompressie en parallelisme gebruik. Pg_basebackup sal die skag langs jou plaas. WAL-G neem aan dat u argivering opgestel het. En dit sal 'n waarskuwing uitreik as dit nie opgestel is nie.
Pg_basebackup kan sonder skagte uitgevoer word.
Ja, dan sal hulle amper dieselfde optree. Pg_basebackup kopieer na die lêerstelsel. Terloops, ons het 'n nuwe kenmerk wat ek vergeet het om te noem. Ons kan nou rugsteun na die lêerstelsel vanaf pg_basebackup. Ek weet nie hoekom dit nodig is nie, maar dit is daar.
Byvoorbeeld, op CephFS. Nie almal wil Object Storage opstel nie.
Ja, dit is waarskynlik hoekom hulle 'n vraag oor hierdie kenmerk gevra het sodat ons dit kon doen. En ons het dit gedoen.
Dankie vir die verslag! Daar is net 'n vraag oor kopiëring na die lêerstelsel. Ondersteun jy nou uit die boks kopieer na afgeleë berging, byvoorbeeld, as daar een of ander rak in die datasentrum is of iets anders?
In hierdie formulering is dit 'n moeilike vraag. Ja, ons ondersteun, maar hierdie funksionaliteit is nog nie by enige vrystelling ingesluit nie. Dit wil sê, alle voorvrystellings ondersteun dit, maar die vrystellingweergawes nie. Hierdie funksionaliteit is bygevoeg in weergawe 0.2. Dit sal beslis binnekort vrygestel word, sodra ons al die bekende foute reggemaak het. Maar op die oomblik kan dit net in die voorvrystelling gedoen word. Daar is twee foute in die voorvrystelling. Probleem met WAL-E herstel, ons het dit nie reggemaak nie. En in die jongste voorvrystelling is 'n fout oor delta-rugsteun bygevoeg. Daarom beveel ons almal aan om die vrystelling weergawes te gebruik. Sodra daar nie meer foute in die voorvrystelling is nie, kan ons sê dat ons Google Cloud, S3-versoenbare goed en lêerberging ondersteun.
Hallo, dankie vir die verslag. Soos ek dit verstaan, is WAL-G nie 'n soort gesentraliseerde stelsel soos kroegmanne nie? Beplan jy om in hierdie rigting te beweeg?
Die probleem is dat ons van hierdie rigting wegbeweeg het. WAL-G leef op die basisgasheer, op die groepgasheer en op alle gashere in die groepering. Toe ons na etlike duisende groepe verhuis het, het ons baie kroegman-installasies gehad. En elke keer as iets in hulle uitmekaar val, is dit 'n groot probleem. Omdat hulle herstel moet word, moet jy verstaan watter groepe nou nie rugsteun het nie. Ek beplan nie om WAL-G te ontwikkel in die rigting van fisiese hardeware vir rugsteunstelsels nie. As die gemeenskap 'n bietjie funksionaliteit hier wil hê, gee ek glad nie om nie.
Ons het spanne wat verantwoordelik is vir berging. En ons voel so goed dat dit nie ons is nie, dat daar spesiale mense is wat ons lêers plaas waar die lêers veilig is. Hulle doen allerhande slim kodering daar om die verlies van 'n sekere aantal lêers te weerstaan. Hulle is verantwoordelik vir netwerkbandwydte. Wanneer jy 'n kroegman het, kan jy skielik uitvind dat klein databasisse met baie verkeer op dieselfde bediener versamel het. Dit lyk of jy baie spasie daarop het, maar om een of ander rede pas alles nie deur die netwerk nie. Dit kan dalk andersom uitdraai. Daar is baie netwerke daar, daar is verwerkerkerne, maar hier is geen skywe nie. En ons het moeg geword vir hierdie behoefte om iets te jongleren, en ons het beweeg na die feit dat databerging 'n aparte diens is, waarvoor aparte spesiale mense verantwoordelik is.
NS 'n Nuwe weergawe is vrygestel , waarin jy die .walg.json-konfigurasielêer kan gebruik, wat by verstek in die postgres-tuisgids geleë is. Jy kan bash-skrifte laat vaar. Voorbeeld .walg.json is in hierdie uitgawe
Video:
Bron: will.com