Ek stel voor jy lees die transkripsie van die vroeë 2020-verslag deur Georgy Rylov "WAL-G: nuwe geleenthede en uitbreiding van die gemeenskap"
Oopbron-onderhouers staar baie uitdagings in die gesig namate hulle groei. Hoe om meer en meer vereiste kenmerke te skryf, meer en meer probleme op te los en dit reg te kry om meer en meer trekversoeke te sien? Deur WAL-G (rugsteuninstrument vir PostgreSQL) as 'n voorbeeld te gebruik, sal ek jou vertel hoe ons hierdie probleme opgelos het deur 'n kursus oor Oopbron-ontwikkeling by die universiteit te begin, wat ons bereik het en waarheen ons volgende sal beweeg.
Hallo weer almal! Ek is 'n Yandex-ontwikkelaar van Yekaterinburg. En vandag sal ek praat oor WAL-G.
Die titel van die verslag het nie gesê dat dit iets oor rugsteun gaan nie. Weet iemand wat WAL-G is? Of weet almal? Steek jou hand op as jy nie weet nie. Holy shit, jy het by die verslag gekom en weet nie waaroor dit gaan nie.
Laat ek jou vertel wat vandag gaan gebeur. Dit gebeur so dat ons span al 'n geruime tyd rugsteun doen. En dit is nog 'n verslag in 'n reeks waar ons praat oor hoe ons data veilig, veilig, gerieflik en doeltreffend stoor.
In vorige reekse was daar baie berigte deur Andrei Borodin en Vladimir Leskov. Daar was baie van ons. En ons praat al baie jare oor WAL-G.
clck.ru/F8ioz —
clck.ru/Ln8Qw —
Hierdie verslag sal 'n bietjie anders wees as die ander deurdat dit meer oor die tegniese deel gegaan het, maar hier sal ek praat oor hoe ons probleme ondervind het wat verband hou met die groei van die gemeenskap. En hoe ons met 'n klein idee vorendag gekom het wat ons help om dit te hanteer.
'n Paar jaar gelede was WAL-G 'n redelik klein projek wat ons van Citus Data gekry het. En ons het dit net geneem. En dit is deur een persoon ontwikkel.
En net WAL-G het nie:
- Rugsteun vanaf 'n replika.
- Daar was geen inkrementele rugsteun nie.
- Daar was geen WAL-Delta-rugsteun nie.
- En daar was nog 'n hele klomp vermis.
Oor hierdie paar jaar het WAL-G baie gegroei.
En teen 2020 het al die bogenoemde reeds verskyn. En hierby is bygevoeg wat ons nou het:
- Meer as 1 000 sterre op GitHub.
- 150 vurke.
- Ongeveer 15 oop PR's.
- En nog baie meer bydraers.
- En maak heeltyd kwessies oop. En dit ten spyte van die feit dat ons letterlik elke dag daarheen gaan en iets daaromtrent doen.
En ons het tot die gevolgtrekking gekom dat hierdie projek meer van ons aandag verg, selfs wanneer ons self niks vir ons Bestuurde Databasisse-diens in Yandex hoef te implementeer nie.
En iewers in die herfs van 2018 het 'n idee by ons opgekom. Gewoonlik het die span verskeie maniere om sekere kenmerke te ontwikkel of foute reg te stel as jy nie genoeg hande het nie. Byvoorbeeld, jy kan 'n ander ontwikkelaar huur en hom geld betaal. Of jy kan vir 'n rukkie 'n intern aanneem en hom ook 'n salaris betaal. Maar daar is nogal 'n groot groep mense, van wie sommige reeds regtig weet hoe om kode te skryf. Jy weet net nie altyd watter kwaliteit die kode is nie.
Ons het daaroor nagedink en besluit om studente te probeer lok. Maar studente sal nie saam met ons aan alles deelneem nie. Hulle sal net 'n deel van die werk doen. En hulle sal byvoorbeeld toetse skryf, foute regmaak, kenmerke implementeer wat nie die hooffunksionaliteit beïnvloed nie. Die hooffunksie is om rugsteun te skep en rugsteun te herstel. As ons 'n fout maak met die skep van 'n rugsteun, sal ons dataverlies ervaar. En niemand wil dit natuurlik hê nie. Almal wil hê alles moet baie veilig wees. Daarom wil ons natuurlik nie kode toelaat wat ons minder vertrou as ons eie nie. Dit wil sê, enige nie-kritieke kode is wat ons graag van ons bykomende werkers wil ontvang.
Onder watter voorwaardes word studente PR aanvaar?
- Daar word van hulle verwag om hul kode met toetse te dek. Alles moet in CI plaasvind.
- En ons gaan ook deur 2 resensies. Een deur Andrey Borodin en een deur my.
- En boonop, om seker te maak dat dit niks in ons diens sal breek nie, laai ek die vergadering afsonderlik op met hierdie verbintenis. En ons kyk in end-tot-end-toetse dat niks misluk nie.
Spesiale kursus oor Oopbron
'n Bietjie oor hoekom dit nodig is en hoekom dit, lyk dit vir my, 'n gawe idee is.
Vir ons is die wins voor die hand liggend:
- Ons kry ekstra hande.
- En ons soek kandidate vir die span onder slim studente wat slim kode skryf.
Wat is die voordeel vir studente?
Hulle kan minder voor die hand liggend wees, omdat studente op 'n minimum nie geld ontvang vir die kode wat hulle skryf nie, maar slegs punte vir hul studenterekords ontvang.
Ek het hulle hieroor uitgevra. En in hulle woorde:
- Bydraer-ervaring in oopbron.
- Kry 'n lyn in jou CV.
- Bewys jouself en slaag 'n onderhoud in Yandex.
- Word 'n GSoC-lid.
- +1 spesiale kursus vir diegene wat kode wil skryf.
Ek sal nie praat oor hoe die kursus gestruktureer is nie. Ek sal net sê dat WAL-G die hoofprojek was. Ons het ook projekte soos Odyssey, PostgreSQL en ClickHouse by hierdie kursus ingesluit.
En hulle het probleme nie net in hierdie kursus gegee nie, maar ook diplomas en kursuswerk uitgedeel.
Wat van die voordeel vir gebruikers?
Kom ons gaan nou oor na die deel wat jou die meeste interesseer. Wat baat dit jou? Die punt is dat die studente baie foute reggemaak het. En ons het die versoekfunksies gemaak wat jy ons gevra het om te doen.
En laat ek jou vertel van die dinge wat jy lankal wou hê en wat verwesenlik is.
Ondersteuning vir tafelspasies. Tabelruimtes in WAL-G is waarskynlik sedert die vrystelling van WAL-G verwag, want WAL-G is die opvolger van 'n ander rugsteunhulpmiddel WAL-E, waar databasisrugsteun met tabelruimtes ondersteun is.
Laat ek jou kortliks herinner wat dit is en hoekom dit alles nodig is. Tipies beslaan al jou Postgres-data een gids op die lêerstelsel, wat die basis genoem word. En hierdie gids bevat reeds al die lêers en subgidse wat deur Postgres vereis word.
Tabelruimtes is gidse wat Postgres-data bevat, maar hulle is nie buite die basisgids geleë nie. Die skyfie wys dat die tablespacs buite die basisgids geleë is.
Hoe lyk dit vir Postgres self? Daar is 'n aparte subgids pg_tblspc in die basisgids. En dit bevat simskakels na gidse wat eintlik Postgres-data buite die basisgids bevat.
Wanneer jy dit alles gebruik, kan hierdie opdragte vir jou iets soos hierdie lyk. Dit wil sê, jy skep 'n tabel in een of ander gespesifiseerde tafelspasie en sien waar dit nou is. Dit is die laaste twee reëls, die laaste twee opdragte genoem. En daar is dit duidelik dat daar een of ander manier is. Maar in werklikheid is dit nie die regte manier nie. Dit is die voorvoegselpad vanaf die basisgids na tabelruimte. En van daar af word dit gekoppel aan 'n simboliek wat na jou regte data lei.
Ons gebruik nie dit alles in ons span nie, maar dit is deur baie ander WAL-E-gebruikers gebruik wat aan ons geskryf het dat hulle na WAL-G wou skuif, maar dit het hulle gekeer. Dit word nou ondersteun.
Nog 'n kenmerk wat ons spesiale kursus vir ons gebring het, is inhaal. Mense wat waarskynlik meer met Oracle as met Postgres gewerk het, weet van catchup.
Kortliks oor wat dit is. Die klustertopologie in ons diens kan gewoonlik so iets lyk. Ons het 'n meester. Daar is 'n replika wat vooruitskryflog daaruit stroom. En die replika vertel die meester op watter LSN dit tans is. En iewers parallel hiermee, kan die log in die argief geplaas word. En benewens die argivering van die logboek, word rugsteun ook na die wolk gestuur. En delta-rugsteun word gestuur.
Wat kan die probleem wees? Wanneer jy 'n redelik groot databasis het, kan dit blyk dat jou replika ver agter die meester begin bly. En sy bly so ver agter dat sy hom nooit kan inhaal nie. Hierdie probleem moet gewoonlik op een of ander manier opgelos word.
En die maklikste manier is om die replika te verwyder en dit weer op te laai, want dit sal nooit inhaal nie, en die probleem moet hanteer word. Maar dit is nogal 'n lang tyd, want die herstel van 'n hele 10 TB databasis rugsteun is 'n baie, baie lang tyd. En ons wil dit alles so vinnig moontlik doen as sulke probleme opduik. En dit is presies waarvoor inhaalslag is.
Met Catchup kan u delta-rugsteun gebruik, wat op hierdie manier in die wolk gestoor word. Jy sê op watter LSN die agterstallige replika tans is en spesifiseer dit in die catchup-opdrag om 'n delta-rugsteun te skep tussen daardie LSN en die LSN waarop jou groep tans geleë is. En daarna herstel jy hierdie rugsteun na die replika wat agtergebly het.
Ander basisse
Die studente het ook vir ons baie funksies op een slag gebring. Aangesien ons by Yandex nie net Postgres kook nie, ons het ook MySQL, MongoDB, Redis, ClickHouse, op 'n stadium moes ons rugsteun maak met punt-in-tyd herstel vir MySQL, en sodat daar 'n geleentheid was om op te laai hulle na die wolk.
En ons wou dit op 'n soortgelyke manier doen as wat WAL-G doen. En ons het besluit om te eksperimenteer en te kyk hoe dit alles sou lyk.
En aanvanklik, sonder om hierdie logika op enige manier te deel, het hulle die kode in die vurk geskryf. Hulle het gesien dat ons 'n soort werkende model het en dit kan vlieg. Toe het ons gedink dat ons hoofgemeenskap postgresists is, hulle gebruik WAL-G. En daarom moet ons hierdie dele op een of ander manier skei. Dit wil sê, wanneer ons kode vir Postgres wysig, breek ons nie MySQL nie; wanneer ons MySQL redigeer, breek ons nie Postgres nie.
Die eerste idee oor hoe om dit te skei, was die idee om dieselfde benadering te gebruik wat in PostgreSQL-uitbreidings gebruik word. En om 'n MySQL-rugsteun te maak, moes jy 'n soort dinamiese biblioteek installeer.
Maar hier is die asimmetrie van hierdie benadering onmiddellik sigbaar. As u Postgres rugsteun, plaas u 'n normale rugsteun vir Postgres daarop en alles is in orde. En vir MySQL blyk dit dat jy 'n rugsteun vir Postgres installeer en ook 'n dinamiese biblioteek vir MySQL daarvoor installeer. Dit klink nogal vreemd. Ons het ook so gedink en besluit dat dit nie die oplossing is wat ons nodig het nie.
Verskeie geboue vir Postgres, MySQL, MongoDB, Redis
Maar dit het ons, so lyk dit vir ons, toegelaat om tot die regte besluit te kom – om verskillende vergaderings vir verskillende basisse toe te ken. Dit het dit moontlik gemaak om die logika wat gekoppel is aan rugsteun van verskeie databasisse wat toegang tot die algemene API wat WAL-G implementeer, te isoleer.
Dit is die deel wat ons self geskryf het - voordat ons die studente die probleme gegee het. Dit wil sê, dit is presies die deel waar hulle iets verkeerd kan doen, so ons het besluit dat ons beter so iets moet doen en alles sal reg wees.
Daarna het ons probleme uitgegee. Hulle is dadelik uitmekaar gehaal. Daar is van studente verwag om drie basisse te ondersteun.
Dit is MySQL, wat ons al meer as 'n jaar lank op hierdie manier met WAL-G rugsteun.
En nou nader MongoDB produksie, waar hulle dit met 'n lêer afrond. Trouens, ons het die raamwerk vir dit alles geskryf. Toe het die studente 'n paar werkbare dinge geskryf. En dan bring ons hulle tot 'n toestand wat ons in produksie kan aanvaar.
Hierdie probleme het nie gelyk of studente volledige rugsteunnutsmiddels vir elk van hierdie databasisse moes skryf nie. Ons het nie so 'n probleem gehad nie. Ons probleem was dat ons punt-in-tyd herstel wou hê en ons wou rugsteun na die wolk. En hulle het die studente gevra om 'n kode te skryf wat dit sou oplos. Die studente het reeds bestaande rugsteunhulpmiddels gebruik, wat op een of ander manier rugsteun neem, en dan alles vasgeplak met WAL-G, wat dit alles na die wolk aangestuur het. En hulle het ook punt-in-tyd herstel hierby gevoeg.
Wat het die studente nog saamgebring? Hulle het Libsodium-enkripsie-ondersteuning na WAL-G gebring.
Ons het ook rugsteunbergingsbeleide. Rugsteun kan nou as permanent gemerk word. En op een of ander manier is dit geriefliker vir u diens om die proses van berging daarvan te outomatiseer.
Wat was die resultaat van hierdie eksperiment?
Meer as 100 mense het aanvanklik vir die kursus geregistreer. Ek het eers nie gesê dat die universiteit in Jekaterinburg die Oeral Federale Universiteit is nie. Ons het alles daar aangekondig. 100 mense het geregistreer. In werklikheid het baie minder mense iets begin doen, omtrent 30 mense.
Nog minder mense het die kursus voltooi, want dit was nodig om toetse te skryf vir die kodes wat reeds bestaan. En maak ook 'n fout reg of maak 'n kenmerk. En sommige studente het steeds die kursus gesluit.
Tans, tydens hierdie kursus, het studente ongeveer 14 kwessies reggemaak en 10 kenmerke van verskillende groottes gemaak. En dit lyk vir my, dit is 'n volwaardige vervanging van een of twee ontwikkelaars.
Ons het onder meer diplomas en kursuswerk uitgereik. En 12 het diplomas ontvang. 6 van hulle het hulself reeds by “5” verdedig. Die wat oorgebly het, het nog nie beskerming gehad nie, maar ek dink dat alles vir hulle ook reg sal wees.
Planne vir die toekoms
Watter planne het ons vir die toekoms?
Ten minste daardie kenmerkversoeke wat ons reeds van gebruikers gehoor het en wil doen. Dit:
- Monitering van die korrektheid van tydlynnasporing in die HA-kluster-rugsteunargief. Jy kan dit met WAL-G doen. En ek dink ons sal studente hê wat hierdie saak sal opneem.
- Ons het reeds 'n persoon wat verantwoordelik is vir die oordrag van rugsteun en WAL tussen wolke.
- En ons het onlangs 'n idee gepubliseer dat ons WAL-G selfs meer kan bespoedig deur inkrementele rugsteun uit te pak sonder om bladsye te herskryf en die argiewe wat ons daarheen stuur, te optimaliseer.
Jy kan hulle hier deel
Waarvoor was hierdie verslag? Boonop het ons nou, benewens die 4 mense wat hierdie projek ondersteun, bykomende hande, waarvan daar nogal baie is. Veral as jy in ’n persoonlike boodskap aan hulle skryf. En as jy jou data rugsteun en dit met WAL-G doen of na WAL-G wil skuif, dan kan ons jou wense redelik maklik akkommodeer.
Dit is 'n QR-kode en 'n skakel. Jy kan deur hulle gaan en al jou wense skryf. Ons maak byvoorbeeld nie een of ander fout reg nie. Of jy wil regtig een of ander kenmerk hê, maar om een of ander rede is dit nog nie in enige rugsteun nie, insluitend ons s'n. Maak seker om hieroor te skryf.
vrae
Hallo! Dankie vir die verslag! Vraag oor WAL-G, maar nie oor Postgres nie. WAL-G rugsteun MySQL en roep 'n ekstra rugsteun. As ons moderne installasies op CentOS neem en as jy MySQL installeer, sal MariDB geïnstalleer word. Vanaf weergawe 10.3 word ekstra rugsteun nie ondersteun nie, MariDB-rugsteun word ondersteun. Hoe gaan dit met jou?
Op die oomblik het ons nie probeer om MariDB te rugsteun nie. Ons het versoeke vir FoundationDB-ondersteuning gehad, maar oor die algemeen, as daar so 'n versoek is, kan ons mense kry wat dit sal doen. Dit is nie so lank of so moeilik as wat ek dink nie.
Goeie middag Dankie vir die verslag! Vraag oor potensiële nuwe kenmerke. Is jy gereed om WAL-G met bande te laat werk sodat jy na bande kan rugsteun?
Rugsteun op bandberging beteken blykbaar?
Ja.
Daar is Andrei Borodin, wat hierdie vraag beter as ek kan beantwoord.
(Andrey) Ja, dankie vir die vraag! Ons het 'n versoek gehad om 'n rugsteun na band oor te dra vanaf wolkberging. En hiervoor oordrag tussen wolke. Omdat wolk-tot-wolk-oordrag 'n algemene weergawe van bandoordrag is. Daarbenewens het ons 'n uitbreidbare argitektuur in terme van bergings. Terloops, baie Storoges is deur studente geskryf. En as jy Storage for tape skryf, dan sal dit natuurlik ondersteun word. Ons is gereed om trekversoeke te oorweeg. Daar moet jy 'n lêer skryf, 'n lêer lees. As jy hierdie dinge in Go doen, eindig jy gewoonlik met 50 reëls kode. En dan sal band in WAL-G ondersteun word.
Dankie vir die verslag! Interessante ontwikkelingsproses. Rugsteun is 'n ernstige stuk funksionaliteit wat goed deur toetse gedek moet word. Toe jy funksionaliteit vir nuwe databasisse geïmplementeer het, het die studente ook die toetse geskryf, of het jy self die toetse geskryf en dan die implementering aan die studente gegee?
Studente het ook toetse geskryf. Maar studente het meer geskryf vir kenmerke soos nuwe databasisse. Hulle het integrasietoetse geskryf. En hulle het eenheidstoetse geskryf. As die integrasie slaag, dit wil sê op die oomblik, is dit 'n skrip wat u met die hand uitvoer of u het byvoorbeeld cron wat dit doen. Dit wil sê, die skrif daar is baie duidelik.
Die studente het nie veel ondervinding nie. Neem hersiening baie tyd?
Ja, resensies neem nogal baie tyd. Dit is, gewoonlik, wanneer verskeie committers op een slag kom en sê dat ek dit gedoen het, het ek dit gedoen, dan moet jy dink en ongeveer 'n halwe dag opsy sit om uit te vind wat hulle daar geskryf het. Omdat die kode noukeurig gelees moet word. Hulle het nie 'n onderhoud gehad nie. Ons ken hulle nie baie goed nie, so dit neem 'n aansienlike hoeveelheid tyd.
Dankie vir die verslag! Voorheen het Andrey Borodin gesê dat archive_command in WAL-G direk geroep moet word. Maar in die geval van 'n soort trospatroon, het ons addisionele logika nodig om die nodus te bepaal waarvandaan die skagte gestuur moet word. Hoe los jy hierdie probleem self op?
Wat is jou probleem hier? Kom ons sê jy het 'n sinchrone replika waarmee jy 'n rugsteun maak? Of wat?
(Andrey) Die feit is dat WAL-G inderdaad bedoel is om sonder dopskrifte gebruik te word. As iets ontbreek, laat ons die logika byvoeg wat binne WAL-G behoort te wees. Wat betref waar argivering vandaan moet kom, glo ons dat argivering van die huidige meester in die kluster moet wees. Argiveer vanaf 'n replika is 'n slegte idee. Daar is verskeie moontlike scenario's met probleme. Veral probleme met die argivering van tydlyne en enige bykomende inligting. Dankie vir die vraag!
(Verduideliking: Ons het ontslae geraak van dopskrifte )
Goeienaand! Dankie vir die verslag! Ek stel belang in die inhaalfunksie waaroor jy gepraat het. Ons het te staan gekom voor 'n situasie waar 'n replika agter was en nie kon inhaal nie. En ek het nie 'n beskrywing van hierdie kenmerk in WAL-G-dokumente gevind nie.
Catchup het letterlik op 20 Januarie 2020 verskyn. Die dokumentasie benodig dalk nog werk. Ons skryf dit self en ons skryf dit nie supergoed nie. En miskien moet ons begin vereis dat studente dit skryf.
Is dit reeds vrygestel?
Die trekversoek is reeds dood, maw ek het dit nagegaan. Ek het dit op 'n toetsgroep probeer. Tot dusver het ons nog nie 'n situasie gehad waar ons dit in 'n gevegsvoorbeeld kon toets nie.
Wanneer om te verwag?
Ek weet nie. Wag 'n maand, ons sal seker maak.
Bron: will.com