Predlagam, da preberete prepis poročila Georgyja Rylova z začetka leta 2020 »WAL-G: nove priložnosti in širitev skupnosti«
Vzdrževalci odprtokodnih sistemov se med rastjo soočajo s številnimi izzivi. Kako napisati vedno več zahtevanih funkcij, odpraviti vedno več težav in uspeti videti vedno več zahtev za vleko? Na primeru WAL-G (orodja za varnostno kopiranje za PostgreSQL) vam bom povedal, kako smo rešili te težave z uvedbo tečaja o odprtokodnem razvoju na univerzi, kaj smo dosegli in kam bomo šli naprej.
Še enkrat pozdravljeni vsi! Sem Yandex razvijalec iz Jekaterinburga. In danes bom govoril o WAL-G.
Naslov poročila ni povedal, da gre za nekaj o varnostnih kopijah. Ali kdo ve, kaj je WAL-G? Ali pa vsi vedo? Dvignite roko, če ne veste. Hudiča, prišel si na poročilo in ne veš, za kaj gre.
Naj vam povem, kaj se bo zgodilo danes. Zgodi se, da naša ekipa že kar nekaj časa dela varnostne kopije. In to je še eno poročilo v seriji, kjer govorimo o tem, kako varno, varno, priročno in učinkovito shranjujemo podatke.
V prejšnjih serijah je bilo veliko poročil Andreja Borodina in Vladimirja Leskova. Veliko nas je bilo. In o WAL-G govorimo že vrsto let.
clck.ru/F8ioz —
clck.ru/Ln8Qw —
To poročilo bo nekoliko drugačno od drugih, saj je bilo bolj o tehničnem delu, tukaj pa bom govoril o tem, kako smo naleteli na težave, povezane z rastjo skupnosti. In kako smo prišli do majhne ideje, ki nam pomaga pri tem.
Pred nekaj leti je bil WAL-G dokaj majhen projekt, ki smo ga dobili od Citus Data. In smo ga le vzeli. In razvila ga je ena oseba.
In samo WAL-G ni imel:
- Varnostno kopiranje iz replike.
- Inkrementalnih varnostnih kopij ni bilo.
- Varnostnih kopij WAL-Delta ni bilo.
- In še veliko je manjkalo.
V teh nekaj letih je WAL-G zelo zrasel.
In do leta 2020 se je vse našteto že pojavilo. In temu je bilo dodano, kar imamo zdaj:
- Več kot 1 zvezdic na GitHubu.
- 150 vilic.
- Približno 15 odprtih PR-jev.
- In še veliko drugih sodelavcev.
- In ves čas odprta vprašanja. In to kljub temu, da gremo tja dobesedno vsak dan in nekaj naredimo za to.
In prišli smo do zaključka, da ta projekt zahteva več naše pozornosti, tudi ko nam samim ni treba implementirati ničesar za našo storitev upravljanih baz podatkov v Yandexu.
In nekje jeseni 2018 se nam je porodila ideja. Običajno ima ekipa več načinov za razvoj nekaterih funkcij ali odpravljanje napak, če nimate dovolj rok. Na primer, lahko najamete drugega razvijalca in mu plačate denar. Lahko pa za nekaj časa vzamete pripravnika in mu tudi plačate nekaj plače. Še vedno pa obstaja kar velika skupina ljudi, med katerimi nekateri že res znajo pisati kodo. Samo ne veš vedno, kakšne kakovosti je koda.
Razmislili smo o tem in se odločili, da poskusimo privabiti študente. Študentje pa pri nas ne bodo sodelovali pri vsem. Opravili bodo le del dela. In bodo na primer pisali teste, odpravljali napake, izvajali funkcije, ki ne vplivajo na glavno funkcionalnost. Glavna funkcionalnost je ustvarjanje varnostnih kopij in obnavljanje varnostnih kopij. Če naredimo napako pri ustvarjanju varnostne kopije, bomo doživeli izgubo podatkov. In tega si seveda nihče ne želi. Vsi si želijo, da je vse zelo varno. Zato seveda ne želimo pustiti kode, ki ji zaupamo manj kot svoji. To pomeni, da bi radi prejeli vsako nekritično kodo od naših dodatnih delavcev.
Pod kakšnimi pogoji je študentski PR sprejet?
- Svojo kodo morajo pokriti s testi. Vse bi moralo potekati v CI.
- Gremo tudi skozi 2 pregleda. Enega Andreja Borodina in enega mene.
- In poleg tega, da preverim, ali to ne bo pokvarilo ničesar v naši storitvi, ločeno naložim sklop s to potrditvijo. S testi od konca do konca preverjamo, da nič ne spodleti.
Poseben tečaj o odprti kodi
Malo o tem, zakaj je to potrebno in zakaj se mi zdi to kul ideja.
Za nas je dobiček očiten:
- Dobimo dodatne roke.
- In kandidate za ekipo iščemo med pametnimi študenti, ki pišejo pametno kodo.
Kakšna je korist za študente?
Morda so manj očitne, saj študenti najmanj ne prejmejo denarja za kodo, ki jo napišejo, ampak le ocene za svoje študentske evidence.
Vprašal sem jih o tem. In po njihovih besedah:
- Izkušnje prispevkov na področju odprte kode.
- Pridobite vrstico v svojem življenjepisu.
- Dokažite se in opravite razgovor v Yandexu.
- Postanite član GSoC.
- +1 poseben tečaj za tiste, ki želijo pisati kodo.
Ne bom govoril o tem, kako je bil tečaj strukturiran. Rekel bom le, da je bil WAL-G glavni projekt. V ta tečaj smo vključili tudi projekte, kot so Odyssey, PostgreSQL in ClickHouse.
In niso delali težav le pri tem predmetu, ampak so izdali tudi diplome in tečajne naloge.
Kaj pa korist za uporabnike?
Zdaj pa preidimo na del, ki vas najbolj zanima. Kaj ti to koristi? Gre za to, da so študenti odpravili veliko napak. Izdelali smo funkcije zahteve, ki ste jih zahtevali od nas.
In naj vam povem o stvareh, ki ste si jih dolgo želeli in so se uresničile.
Podpora za tabelne prostore. Prostore tabel v WAL-G smo verjetno pričakovali že od izdaje WAL-G, ker je WAL-G naslednik drugega orodja za varnostno kopiranje WAL-E, kjer so bile podprte varnostne kopije baze podatkov s prostori tabel.
Naj vas na kratko spomnim, kaj je to in zakaj je vse to potrebno. Običajno vsi vaši podatki Postgres zasedajo en imenik v datotečnem sistemu, ki se imenuje baza. In ta imenik že vsebuje vse datoteke in podimenike, ki jih zahteva Postgres.
Prostori tabel so imeniki, ki vsebujejo podatke Postgres, vendar se ne nahajajo zunaj osnovnega imenika. Diapozitiv prikazuje, da se tabelni prostori nahajajo zunaj osnovnega imenika.
Kako to izgleda za sam Postgres? V osnovnem imeniku je ločen podimenik pg_tblspc. In vsebuje simbolne povezave do imenikov, ki dejansko vsebujejo podatke Postgres zunaj osnovnega imenika.
Ko vse to uporabite, potem lahko za vas ti ukazi izgledajo nekako takole. To pomeni, da ustvarite tabelo v določenem prostoru tabel in vidite, kje je zdaj. To sta zadnji dve vrstici, zadnja dva poklicana ukaza. In tam je jasno, da obstaja neka pot. A v resnici to ni pravi način. To je predpona pot od osnovnega imenika do prostora tabel. Od tam se ujema s simbolno povezavo, ki vodi do vaših resničnih podatkov.
Vsega tega ne uporabljamo v naši ekipi, vendar so ga uporabljali številni drugi uporabniki WAL-E, ki so nam pisali, da bi radi prešli na WAL-G, vendar jih je to ustavilo. To je zdaj podprto.
Druga lastnost, ki nam jo je prinesel naš specialni tečaj, je lovljenje. Ljudje, ki so verjetno več delali z Oracle kot s Postgresom, vedo za dohitevanje.
Na kratko o tem, kaj je. Topologija gruče v naši storitvi je običajno videti nekako takole. Imamo mojstra. Obstaja replika, ki iz nje pretaka dnevnik vnaprejšnjega pisanja. In replika pove masterju, na kateri LSN je trenutno. In nekje vzporedno s tem se lahko dnevnik arhivira. Poleg arhiviranja dnevnika se varnostne kopije pošiljajo tudi v oblak. Delta varnostne kopije so poslane.
Kaj bi lahko bil problem? Ko imate precej veliko bazo podatkov, se lahko izkaže, da vaša replika začne močno zaostajati za mojstrom. In tako zaostaja, da ga nikoli ne more dohiteti. To težavo je običajno treba nekako rešiti.
In najlažji način je, da odstranite repliko in jo znova naložite, ker nikoli ne bo dohitela, težavo pa je treba odpraviti. Toda to je precej dolgo obdobje, saj je obnovitev celotne varnostne kopije baze podatkov 10 TB zelo, zelo dolgo. In vse to želimo storiti čim hitreje, če pride do takšnih težav. In točno temu je catchap namenjen.
Catchup omogoča uporabo delta varnostnih kopij, ki se na ta način shranijo v oblak. Poveste, na katerem LSN je trenutno zaostala replika, in ga določite v ukazu catchup, da ustvarite delta varnostno kopijo med tem LSN in LSN, na katerem se trenutno nahaja vaša gruča. Po tem obnovite to varnostno kopijo na repliko, ki je zaostajala.
Druge baze
Dijaki so nam prinesli tudi veliko funkcij naenkrat. Ker pri Yandexu ne kuhamo samo Postgres, imamo tudi MySQL, MongoDB, Redis, ClickHouse, smo morali na neki točki imeti možnost izdelave varnostnih kopij z obnovitvijo v trenutku za MySQL in tako, da je bila možnost nalaganja jih v oblak.
In želeli smo to narediti na nek podoben način kot počne WAL-G. In odločili smo se, da eksperimentiramo in vidimo, kako bo vse skupaj izgledalo.
In sprva, ne da bi kakor koli delili to logiko, so zapisali kodo v fork. Videli so, da imamo nekakšen delujoč model in lahko leti. Potem smo mislili, da so naša glavna skupnost postgresisti, ki uporabljajo WAL-G. In zato moramo te dele nekako ločiti. To pomeni, da ko urejamo kodo za Postgres, ne porušimo MySQL; ko urejamo MySQL, ne porušimo Postgresa.
Prva zamisel o tem, kako to ločiti, je bila zamisel o uporabi istega pristopa, ki se uporablja v razširitvah PostgreSQL. In pravzaprav ste morali za izdelavo varnostne kopije MySQL namestiti nekakšno dinamično knjižnico.
Toda tukaj je takoj vidna asimetrija tega pristopa. Ko varnostno kopiraš Postgres, daš nanj običajno varnostno kopijo za Postgres in je vse v redu. In za MySQL se izkaže, da namestite varnostno kopijo za Postgres in zanjo namestite tudi dinamično knjižnico za MySQL. Sliši se nekako čudno. Tudi mi smo tako razmišljali in se odločili, da to ni rešitev, ki jo potrebujemo.
Različne različice za Postgres, MySQL, MongoDB, Redis
Toda to nam je omogočilo, se nam zdi, da smo prišli do prave odločitve - dodeliti različne sklope za različne baze. To je omogočilo izolacijo logike, povezane z varnostnimi kopijami različnih baz podatkov, ki bodo dostopale do skupnega API-ja, ki ga izvaja WAL-G.
To je del, ki smo ga napisali sami – preden smo študentom zadali težave. Se pravi, to je ravno tisti del, kjer bi lahko naredili kaj narobe, zato smo se odločili, da raje naredimo nekaj takega in bo vse v redu.
Po tem smo izdali težave. Takoj so jih razstavili. Študenti so morali podpirati tri baze.
To je MySQL, ki ga že več kot eno leto varnostno kopiramo s pomočjo WAL-G.
In zdaj se MongoDB bliža produkciji, kjer ga dodelujejo z datoteko. Pravzaprav smo napisali okvir za vse to. Nato so učenci napisali nekaj uporabnih stvari. In potem jih pripeljemo do stanja, ki ga lahko sprejmemo v proizvodnji.
Te težave niso bile videti, kot da bi študentje morali napisati popolna orodja za varnostno kopiranje za vsako od teh baz podatkov. Mi nismo imeli takega problema. Naša težava je bila, da smo želeli obnovitev v trenutku in želeli smo varnostno kopirati v oblak. Študente so prosili, naj napišejo kodo, ki bi to rešila. Dijaki so uporabili že obstoječa orodja za varnostno kopiranje, ki nekako delajo varnostne kopije, nato pa vse skupaj zlepili z WAL-G, ki je vse skupaj posredoval v oblak. Temu so dodali tudi obnovitev v trenutku.
Kaj so učenci še prinesli? V WAL-G so prinesli podporo za šifriranje Libsodium.
Imamo tudi politike varnostnega shranjevanja. Zdaj lahko varnostne kopije označite kot trajne. In nekako je bolj priročno za vašo storitev, da avtomatizirate postopek njihovega shranjevanja.
Kakšen je bil rezultat tega poskusa?
Na tečaj se je sprva prijavilo več kot 100 ljudi. Sprva nisem rekel, da je univerza v Jekaterinburgu Uralska zvezna univerza. Tam smo vse napovedali. 100 prijavljenih. V resnici je veliko manj ljudi začelo nekaj delati, okoli 30 ljudi.
Tečaj je opravilo še manj ljudi, ker je bilo treba pisati teste za kode, ki že obstajajo. In tudi popraviti kakšno napako ali narediti kakšno funkcijo. In nekateri študenti so tečaj vseeno zaključili.
Trenutno so med tem tečajem študentje odpravili približno 14 težav in izdelali 10 funkcij različnih velikosti. In zdi se mi, da je to popolna zamenjava enega ali dveh razvijalcev.
Med drugim smo izdali diplome in naloge. In 12 jih je prejelo diplome. 6 se jih je že zagovarjalo na "5". Tisti, ki so ostali, še niso imeli zaščite, a mislim, da bo tudi za njih vse v redu.
Načrti za prihodnost
Kakšne načrte imamo za prihodnost?
Vsaj tiste zahteve po funkcijah, ki smo jih že slišali od uporabnikov in jih želimo izvesti. To:
- Spremljanje pravilnosti sledenja časovnice v arhivu varnostne kopije gruče HA. To lahko storite z WAL-G. In mislim, da bomo imeli študente, ki se bodo tega lotili.
- Za prenos varnostnih kopij in WAL med oblaki že imamo odgovorno osebo.
- Nedavno smo objavili zamisel, da lahko še dodatno pospešimo WAL-G z razpakiranjem inkrementalnih varnostnih kopij brez ponovnega pisanja strani in optimiziranjem arhivov, ki jih pošiljamo tja.
Lahko jih delite tukaj
Čemu je bilo to poročilo? Še več, zdaj imamo poleg 4 ljudi, ki podpirajo ta projekt, še dodatne roke, ki jih je kar veliko. Še posebej, če jim pišete v osebnem sporočilu. In če varnostno kopirate svoje podatke in to storite z uporabo WAL-G ali bi radi prešli na WAL-G, lahko zlahka ustrežemo vašim željam.
To je koda QR in povezava. Lahko jih pregledate in napišete vse svoje želje. Na primer, ne popravljamo neke napake. Ali pa res želite neko funkcijo, vendar je iz nekega razloga še ni v nobeni varnostni kopiji, vključno z našo. Bodite prepričani, da pišete o tem.
vprašanja
Zdravo! Hvala za poročilo! Vprašanje o WAL-G, ne pa o Postgresu. WAL-G varnostno kopira MySQL in pokliče dodatno varnostno kopijo. Če vzamemo sodobne namestitve na CentOS in če yum namestite MySQL, bo MariDB nameščen. Od različice 10.3 dodatna varnostna kopija ni podprta, podprta je varnostna kopija MariDB. Kako si s tem?
Trenutno nismo poskušali varnostno kopirati MariDB. Imeli smo zahteve za podporo FoundationDB, a na splošno, če obstaja taka zahteva, lahko najdemo ljudi, ki bodo to storili. Ni tako dolgo ali tako težko, kot mislim.
Dober večer Hvala za poročilo! Vprašanje o potencialnih novih funkcijah. Ali ste pripravljeni, da WAL-G deluje s trakovi, tako da lahko varnostno kopirate na trakove?
Varnostno kopiranje na tračnem pomnilniku očitno pomeni?
Da.
Tu je Andrej Borodin, ki lahko na to vprašanje odgovori bolje kot jaz.
(Andrey) Ja, hvala za vprašanje! Imeli smo zahtevo za prenos varnostne kopije na trak iz shrambe v oblaku. In za to prenos med oblaki. Ker je prenos iz oblaka v oblak posplošena različica prenosa na trak. Poleg tega imamo razširljivo arhitekturo v smislu shramb. Mimogrede, številne Storoge so napisali študenti. In če napišete Storage for tape, potem bo seveda podprt. Pripravljeni smo upoštevati zahteve za vleko. Tam morate napisati datoteko, prebrati datoteko. Če te stvari počnete v Go, običajno dobite 50 vrstic kode. In potem bo trak podprt v WAL-G.
Hvala za poročilo! Zanimiv razvojni proces. Varnostno kopiranje je resna funkcionalnost, ki bi morala biti dobro pokrita s testi. Ko ste implementirali funkcionalnost za nove podatkovne baze, so dijaki pisali tudi teste ali ste teste pisali sami in potem implementacijo predali študentom?
Dijaki so pisali tudi teste. Študenti pa so več pisali za funkcije, kot so nove baze podatkov. Pisali so integracijske teste. In napisali so teste enot. Če integracija mine, se pravi trenutno, je to skripta, ki jo izvajaš ročno ali imaš cron, ki jo dela npr. To pomeni, da je scenarij tam zelo jasen.
Študenti nimajo veliko izkušenj. Ali pregledovanje vzame veliko časa?
Da, pregledi vzamejo kar nekaj časa. To je običajno, ko pride več komitatorjev hkrati in reče, da sem naredil to, naredil sem ono, potem morate razmisliti in si vzeti približno pol dneva, da ugotovite, kaj so tam napisali. Ker je treba kodo natančno prebrati. Niso imeli intervjuja. Ne poznamo jih dobro, zato vzame precej časa.
Hvala za poročilo! Prej je Andrey Borodin izjavil, da je treba archive_command v WAL-G klicati neposredno. Toda v primeru neke vrste kartuše v gruči potrebujemo dodatno logiko za določitev vozlišča, iz katerega pošiljamo gredi. Kako sami rešujete ta problem?
Kaj je tvoj problem tukaj? Recimo, da imate sinhrono repliko, s katero delate varnostno kopijo? Ali kaj?
(Andrey) Dejstvo je, da je WAL-G dejansko namenjen uporabi brez lupinskih skriptov. Če kaj manjka, potem dodajmo logiko, ki bi morala biti znotraj WAL-G. Glede tega, od kod naj izvira arhiviranje, verjamemo, da mora biti arhiviranje od trenutnega glavnega v gruči. Arhiviranje iz replike je slaba ideja. Obstajajo različni možni scenariji s težavami. Predvsem težave z arhiviranjem časovnic in morebitnih dodatnih informacij. Hvala za vprašanje!
(Pojasnilo: znebili smo se lupinskih skriptov )
Dober večer! Hvala za poročilo! Zanima me funkcija dohitevanja, o kateri ste govorili. Soočili smo se s situacijo, ko je replika zaostala in je ni mogla dohiteti. V dokumentih WAL-G nisem našel opisa te funkcije.
Catchup se je pojavil dobesedno 20. januarja 2020. Dokumentacija bo morda zahtevala še nekaj dela. Pišemo ga sami in ga ne pišemo super. In morda bi morali od študentov začeti zahtevati, da ga napišejo.
Je že izdan?
Zahteva za vleko je že mrtva, kar pomeni, da sem jo preveril. To sem preizkusil na testni gruči. Doslej še nismo imeli situacije, da bi to lahko preizkusili na bojnem primeru.
Kdaj pričakovati?
Nevem. Počakajte en mesec, zagotovo bomo preverili.
Vir: www.habr.com