WAL-G: uued võimalused ja kogukonna laienemine. Georgiy Rõlov

Pakun tutvuda 2020. aasta jaanuaris Georgi Rylovi ettekandega "WAL-G: uued võimalused ja kogukonna laienemine"

Open-source'i hoidjatel tekivad mitmeid probleeme nende kasvu käigus. Kuidas kirjutada üha rohkem vajalikke funktsioone, parandada üha rohkem issues'e ja jõuda vaadata üha rohkem pull request'e? WAL-G (backup-tööriist PostgreSQL jaoks) näitel räägin, kuidas me neid probleeme lahendasime, käivitades open-source arenduse kursuse ülikoolis, mida me saavutasime ja kuhu me edasi liigume.

Tere jälle kõigile! Olen Yandexes arendaja ja tulen Jekaterinburgist. Täna räägin WAL-G-st.

Ettekande pealkirjas ei olnud öeldud, et see on midagi varundamist. Kas keegi ei tea, mis on WAL-G? Või kas kõik teavad? Palun tõstke käsi, kes ei tea. Oi, tulite ettekandele ja ei tea, millest see on.

Lase mul rääkida, mis täna toimuma hakkab. Juhtub, et meie meeskond on juba pikka aega varundamisega tegelenud. Ja see on veel üks ettekande sari, kus räägime sellest, kuidas me andmeid turvaliselt, usaldusväärselt, mugavalt ja tõhusalt salvestame.

Eelmistel sarjadel oli palju ettekandeid Andreist Borodini ja Vladimir Leskovi poolt. Meid oli palju. Ja me kõik oleme juba aastaid rääkinud WAL-G-st.

clck.ru/F8ioz — https://www.highload.ru/moscow/2018/abstracts/3964

clck.ru/Ln8Qw — https://www.highload.ru/moscow/2019/abstracts/5981

See ettekande erineb natuke teistest, sest seal räägiti rohkem tehnilisest osast, aga siin räägin, kuidas me silmitsi seisme kogukonna kasvu probleemidega. Ja kuidas me tuli meelde mõni väike idee, mis aitab meil sellega toime tulla.

Mõned aastat tagasi oli WAL-G üsna väike projekt, mille saime Citus Data'lt. Ja me lihtsalt võtsime selle üle. Ja seda arendas üks inimene.

Ja ainult WAL-G-s polnud:

• Repliigilt varundamist.
• Ei olnud inkrementaalseid varundusi.
• Ei olnud WAL-Delta varundusi.
• Ja veel palju asju polnud.

Mõne aasta jooksul on WAL-G tugevalt kasvanud.

Ja 2020. aastaks oli kõik eespool loetletud juba olemas. Ja lisaks sellele on meil nüüd:

• Rohkem kui 1 000 tähte GitHub'is.
• 150 hargnemist.
• Umbes 15 avatud PR-d.
• Ja veel palju kaastöölisi.
• Ja pidevalt avatud issues. Ja see, et me läheme sinna sõna otseses mõttes igapäevaselt sisse ja teeme sellega midagi.

Ja me jõudsime järeldusele, et see projekt vajab rohkem meie tähelepanu, isegi siis, kui meile endale ei ole vaja midagi meie haldusteenuste jaotuses Yandexis ellu viia.

Ja ja üks sügisel 2018. aastal tuli meile mõte. Tavaliselt on meeskonnal mitu viisi, kuidas funktsioone arendada, vigu parandada, kui käed on vähe. Näiteks võib koondada ühe uue arendaja ning maksta talle palka. Või võite võtta praktikandi mingiks ajaks ja maksta ka temale mingit palka. Kuid on veel üsna suur hulk inimesi, kellest osa oskab juba tõeliselt koodi kirjutada. Lihtsalt te ei pruugi alati teada, milline on selle koodi kvaliteet.

Me mõtlesime ja otsustasime proovida kaasata tudengeid. Kuid tudengid ei osale meie juures kõiges. Nad teevad ainult osa tööst. Näiteks kirjutavad nad teste, parandavad vigu, rakendavad funktsioone, mis ei mõjuta põhifunktsionaalsust. Põhifunktsionaalsus on varukoopiate loomine ja varukoopiate taastamine. Kui lasta läbi viga varukoopia loomisel, saame me andmete kaotuse. Ja seda ei soovi keegi. Kõik soovivad, et kõik oleks väga usaldusväärne. Seetõttu ei soovi me lasta vähese usaldusväärsusega koodi meie süsteemi. Ehk iga mitte-kriitiline kood on see, mida me tahaksime saada meie täiendavatelt töötaja käelt.

Millistel tingimustel aktsepteeritakse tudengi PR-i

• Nad peavad katma oma koodi testidega. Kõik peab läbima CI.
• Ja läbime samuti 2 ülevaatust. Üks Andrei Borodinilt ja üks minult.
• Lisaks, et kontrollida, et see ei rikuks meie teenuses midagi, laadime ma eraldi versiooni selle commitiga. Ja me kontrollime end-to-end testides, et meil ei lendaks midagi kokku.

Erikursus Open Source'i kohta

Veidi selle kohta, miks see on vajalik ja miks see, minu arvates, on lahe idee.

Meie jaoks on kasu ilmselge:

• Saame täiendavad käed.
• Ja otsime meie meeskonda asjatundlikke tudengeid, kes kirjutavad head koodi.

Mis on tudengite kasu?

Need võivad olla vähem ilmsed, sest tudengid ei saa vähemalt raha selle koodi eest, mida nad kirjutavad, vaid saavad ainult hindeid oma õpikus.

Küsin neilt selle kohta ja nende sõnul:

• Kogemus Open Source'i kaastöölisena.
• Saada rida CV-sse.
• Oma oskuste näitamine ja vestlusel läbimine Yandexis.
• Osaleda GSoC-is.
• +1 erikursus neile, kes soovivad koodi kirjutada.

Ma ei hakka rääkima, kuidas kursus oli korraldatud. Ütlen vaid, et WAL-G oli peamine projekt. Samuti hõlmasime kursusel selliseid projekte nagu Odyssey, PostgreSQL ja ClickHouse.

Ja ülesandeid anti mitte ainult sellel kursusel, vaid samuti jagati diplome ja kursusetöid.

Aga mis on sellest kasu kasutajatele?

Nüüd liigume osa juurde, mis teie jaoks on ilmselt huvitavam. Mis kasu te sellest saate? Kasu on selles, et õpilased parandavad palju vigu. Ja nad tegid teie palutud funktsioonide päringud.

Ja rääkigem asjadest, mida olete ammu soovinud ja mis on nüüd ellu viidud.

Tablespace'ide toetus. Tablespace'id WAL-G-s olid oodatud ilmselt alates WAL-G väljalaskmisest, kuna WAL-G on teise varundustööriista WAL-E järglane, kus olid toetatud andmebaaside varukoopiad tablespace'idega.

Kokkuvõtteks meenutan, mis see on ja miks see kõik vajalik on. Tavaliselt asuvad kõik teie Postgres andmed ühises kataloogis failisüsteemis, mida nimetatakse põhikataloogiks. Ja see kataloog sisaldab juba kõiki faile ja alamkatalooge, mida Postgres vajab.

Tablespace'id on kataloogid, kus asuvad Postgres andmed, kuid need ei asu põhikataloogist väljaspool. Esitluses on näha, et tablespace'id asuvad väljaspool põhikatalooge.

Kuidas see Postgrese jaoks välja näeb? Põhikataloogis on eraldi alamkataloog pg_tblspc. Ja selles on sümboolsed lingid kataloogidele, kus tegelikult asuvad Postgres andmed väljaspool põhikatalooge.

Kui te seda kõike kasutate, võivad need käsud teie jaoks välja näha umbes nii. St. te loote tabeli mõnes kindlas tablespace'is ja vaatate, kus see nüüd asub. Need kaks viimast rida, kaks viimati välja kutsutud käsku. Ja seal on näha, et on mingi tee. Kuid tegelikult – see ei ole tõeline tee. See on tee, millel on põhikatalooge eeltoodud prefiks ja tablespace. Ja sealt edasi on see ühendatud sümboolse lingiga, mis suunab teie tegelikele andmetele.

Meie tiimis seda ei kasutata, aga paljusid teisi WAL-E kasutajaid, kes kirjutasid meile, et nad tahavad üle minna WAL-G-le, häiris see. Nüüd on see toetatud.

Teine funktsioon, mille meie erikursus meile tõi, on catchup. Catchup'ist teavad inimesed, kes on ilmselt rohkem töötanud Oracle'iga kui Postgresega.

Lühidalt sellest, mis see on. Nii võib meie teenuse klastritopoloogia välja näha. Meil on peamine server. On ka replikant, mis voogedastab kirjutamislogi. Ja replikant ütleb peamisele serverile, millisel LSN-l ta parasjagu asub. Ja samal ajal võib logi arhiivida. Lisaks ajakohastatakse ka varukoopiaid pilve.

Milline võib olla probleem? Kui teil on suhteliselt suur andmebaas, võib juhtuda, et replikant hakkab peamisest serverist oluliselt maha jääma. Ja jääb nii palju maha, et tal ei õnnestu enam kunagi järgi jõuda. Seda probleemi tuleb tavaliselt lahendada.

Ja kõige lihtsam viis on replikant eemaldada ja see uuesti installida, sest ta ei suuda kunagi järgi jõuda ning probleemiga tuleb tegeleda. Kuid see võtab üsna kaua aega, kuna 10 TB suuruse andmebaasi täis varukoopia taastamine on väga-väga aeganõudev. Ja me tahame selle kõik võimalikult kiiresti ära teha, kui sellised probleemid tekivad. Ja just selleks on mõeldud catchup.

Catchup võimaldab kasutada delta-varukoopiaid, mis on pilves salvestatud. Te ütlete, millisel LSN-l on praegu maha jäänud replikant ja märkite selle catchup käsus, et luua delta-varukoopia selle LSN-i vahel ja LSN-i, kus teie klaster praegu asub. Ja seejärel taastate selle varukoopia replikantile, mis jäi maha.

Teised andmebaasid

Samuti tõid üliõpilased meile kohe palju funktsioone. Kuna me Yandexis töötleme mitte ainult Postgres'i, vaid ka MySQL, MongoDB, Redis, ClickHouse, siis tekkis mingil hetkel vajadus, et saaksime teha varukoopiaid ajapunkti taastamise võimalusega MySQL'ist ja et oleks võimalus neid pilve laadida.

Ja me tahtsime seda teha sarnasel viisil, nagu WAL-G teeb. Otsustasime katsetada ja vaadata, kuidas see kõik välja näeb.

Alguses ei eraldanud me seda loogikat haru sees, vaid kirjutasime koodi. Nägime, et meil on mingisugune toimiv mudel ja see võib toimida. Seejärel mõtlesime, et meie peamine kogukond on postgres'i kasutajad, kes kasutavad WAL-G-d. Seetõttu tuleb need osad kuidagi eraldada. See tähendab, et kui me parandame koodi Postgres'i jaoks, ei sega me MySQL-i ja kui me parandame MySQL-i, ei sega me Postgres'i.

Esimene idee, kuidas seda jagada, oli kasutada sama lähenemist, mida kasutatakse PostgreSQL laiendustes. Sisuliselt, et teha MySQL varukoopia, pidite paigaldama mingi dünaamilise teegi.

Aga siin on kohe näha selle lähenemise asümmeetria. Kui te varundate Postgres'i, paigaldatakse sellele normaalne varundustööriist, ja kõik on suurepärane. Aga MySQL puhul käib see nii, et paigaldate Postgres'i varundustööriista ja selle jaoks paigaldatakse veel dünaamiline teek MySQL jaoks. See kõlab kuidagi kummaliselt. Me mõtlesime ka nii ja otsustasime, et see ei ole see lahendus, mida vajame.

Erinevad paketid Postgres'i, MySQL, MongoDB, Redis jaoks

Aga see võimaldas meil, nagu me arvame, jõuda õige lahenduseni – eristada erinevaid pakette erinevate andmebaaside jaoks. See võimaldas isoleerida loogikat, mis on seotud erinevate andmebaaside varukoopiate tegemisega, mis pöörduvad ühise API poole, mida rakendab WAL-G.

See on see osa, mille me ise kirjutasime – enne, kui andsime tudengitele ülesanded. Teisisõnu, see on just see osa, kus nad võisid midagi valesti teha, seega otsustasime, et teeme midagi ise ja kõik on suurepärane.

Pärast seda andsime ülesanded. Need viidati kohe läbi. Tudengitelt oodati, et nad toetavad kolme andmebaasi.

See on MySQL, mida me oleme juba rohkem kui aasta varundanud pideva WAL-G abiga.

Ja praegu läheneb ka MongoDB tootmisfaasile, seal täiustatakse seda veel. Sisuliselt kirjutasime selle jaoks raami. Hiljem kirjutasid tudengid mõned funktsionaalsed lahendused. Ja siis viime need sellisesse seisundsesse, mida saame oma tootmises aktsepteerida.

Need ülesanded ei näinud välja sellised, et tudengid pidid kirjutama täielikke varundustööriistu iga andmebaasi jaoks. Meie probleem ei seisnud selles. Meie probleem oli selles, et soovisime punkt-punkti taastamist ja soovisime varundada pilve. Palusime tudengitel kirjutada mingit koodi, mis selle lahendaks. Tudengid kasutasid juba olemasolevaid varundustööriistu, mis kuidagi teevad varukoopiaid, ja seejärel sidusid nad selle kõik WAL-G-ga, mis edastas kõik pilve. Samuti lisasid nad punkt-punkti taastamise.

Mida veel tõid tudengid? Nad tõid WAL-G-sse Libsodium'i krüpteerimise toe.

Samuti on meil nüüd varukoopiate säilitamise poliitikad. Nüüd saab varukoopiaid märkida püsivateks. Ja selle teenuse jaoks on mugavam automatiseerida nende säilitamise protsessi.

Mis tulemuseks sai selle eksperimendi käigus?

Kursusele registreerus algselt rohkem kui 100 inimest. Ma ei öelnud alguses, et ülikool Jekaterinburgis on Uuralite Föderaalülikool. Seal kuulutasime me kõik välja. 100 inimest registreerus. Tegelikult hakkas midagi tegema palju vähem, umbes 30 inimest.

Kursuse lõpetas veel vähem inimesi, sest seal pidi kirjutama teste juba olemasolevale koodile. Samuti pidime mõne bug'i parandama või mingit funktsiooni tegema. Ja osa üliõpilastest suudsid siiski kursuse lõpetada.

Praeguseks on üliõpilased selle kursuse käigus parandanud umbes 14 probleemi, teinud 10 erineva suurusega funktsiooni. Ja minu arvates on see täieõiguslik asendus ühe või kahe arendaja jaoks.

Lisaks sellel anname välja diplome ja kursustöid. 12 inimest võtsid diplomi. 6 neist on juba kaitsnud «5» peale. Ülejäänud ei ole veel kaitsnud, kuid arvan, et ka neil läheb kõik hästi.

Tulevikuplaanid

Millised on meie tuleviku plaanid?

Igatahes need funktsioonide päringud, mida me juba kasutajatelt kuulnud oleme ja mida tahame teha. Need on:

• Ajaskaalade täpsuse jälgimine HA-kliendi varukoopia arhivis. WAL-G abil saab seda teha. Ja ma arvan, et leiame tudengeid, kes sellega tegelema hakkavad.
• Varukoopiate ja WAL-i ülekande eest pilvedes on meil juba vastutav isik.
• Ja me avaldasime hiljuti idee, et saame WAL-G-d veel rohkem kiirendada, kasutades inkrementaalsete varukoopiate lahtipakkimist ilma lehekülgede kirjutamiseta ja arhiveerimise optimeerimist, mida me sinna saadame.

Saate neid siin jagada

Milleks oli see ettekande? Selleks, et praegu, peale meid nelja inimest, kes seda projekti toetavad, on meil palju abikäsi. Eriti, kui neile isiklikult kirjutada. Ja kui varundate oma andmeid ja teete seda WAL-G abil või soovite üle minna WAL-G-le, siis saame teie soove üsna kergesti arvesse võtta.

See on qr-kood ja link. Saate neid kasutada, et minna ja kirjutada kõik oma soovid. Näiteks me ei paranda mõnda bug'i. Või mõnda funktsiooni, mida soovite väga, kuid mikski pärast pole see veel üheski varundusteenuses, sealhulgas ka meie omas. Kirjutage sellest kindlasti.

Küsimused

Tere! Aitäh ettekande eest! Küsimus WAL-G kohta, aga mitte Postgresest. WAL-G varundab MySQL-i ja kutsub esile ekstrapäeviku. Kui võtta kaasaegsed paigaldused CentOS-is ja kui teete yum install MySQL, installitakse MariDB. Alates versioonist 10.3 ei toetata ekstrapäevikut, toetatakse MariDB varundust. Kuidas teil sellega on?

Praegu ei ole me püüdnud MariDB-d varundada. Meil on olnud taotlusi FoundationDB toe kohta, kuid üldiselt, kui selline taotlus on, saame leida inimesi, kes selle teevad. See ei ole nii pikk ega keeruline, nagu mulle tundub.

Tere päevast! Aitäh ettekande eest! Küsimus potentsiaalselt uute funktsioonide kohta. Kas olete valmis saama WAL-G tööle lintide jaoks, et saaks varundust teha lintidele?

Kas lintide salvestamiseks mõeldud varundus on ilmselt see, mis silmas peetakse?

Jah.

Seal on Andrej Borodin, kes võib sellele küsimusele paremini vastata.

(Andrej) Jah, aitäh küsimuse eest! Meil oli taotlus varunduse edastamiseks lintidele pilvesalvestusest. Ja selle jaoks on tegemisel edastus pilvede vahel. Sest edastus pilvede vahel on mingisugune üldine versioon edastamisest lintidele. Lisaks on meil laienev arhitektuur salvestusruumide osas. Muide, paljud salvestusruumid on kirjutatud tudengite poolt. Ja kui te kirjutate salvestusruumi lintide jaoks, siis see toetatakse kindlasti. Oleme valmis vaatama sissevedu. Seal tuleb faili kirjutada, faili lugeda. Kui need asjad teha Go keeles, siis saab tavaliselt 50 rida koodi. Ja siis toetatakse WAL-G-s linti.

Aitäh ettekande eest! Huvitav arendusprotsess. Varundamine on tõsine funktsionaalsuse osa, mis peab olema hästi katetud testidega. Kui te realiseerisite uusi andmebaase, kas ka testid kirjutasid tudengid või kirjutesite testid ise ja andsite seejärel rakenduse tudengitele?

Testid kirjutasid samuti tudengid. Kuid tudengid kirjutasid rohkem selliste funktsioonide jaoks, nagu uued andmebaasid. Nad kirjutasid integratsioonitestid. Ja nad kirjutasid üksusteste. Kui integratsioonitestid läbivad, st praegu – see stsenaarium, mida te täidate käsitsi või teeb seda näiteks cron. St stsenaarium on üsna arusaadav.

Tudengitel ei ole eriti palju kogemusi. Kui palju aega ülevaatusele kulub?

Jah, ülevaatamiseks kulub tõesti üsna palju aega. Ehkki tavaliselt, kui tuleb mitu arendajat korraga ja ütlevad, et olen teinud seda ja seda, tuleb mõelda ja leida kuskil pool päeva, et aru saada, mida nad seal kirjutasid. Sest koodi peab hoolikalt lugema. Nad ju ei läbinud vestlust. Me ei tunne neid väga hästi, seetõttu võtab see märkimisväärselt aega.

Aitäh ettekande eest! Varem on Andrei Borodin öelnud, et archive_command WAL-G-is peaks olema kutsutud otse. Kuid mingisuguse patroni klastriga vajame me lisaloogikat, et määrata node, kellele saata WAL-e. Kuidas teie seda probleemi lahendate?

Milline probleem teil siin tekib? Kas teil on näiteks sünkroonne replikatsioon, kust te teete varukoopia? Või mis?

(Andrei) Asi on selles, et WAL-G eeldab tõepoolest kasutamist ilma shell-skriptide sidumiseta. Kui millestki jääb puudu, siis kirjutame loogikaga juurde, mis peaks olema WAL-G sees. Kui rääkida sellest, kust arhiveerimine peaks toimuma, siis usume, et arhiveerimine peaks toimuma klastris olevast praegusest peast. Replikatsioonist arhiveerimine on halb idee. Seal võivad tekkida erinevad stsenaariumid probleemidega. Eelkõige ajajoone ja muude lisainfo arhiveerimise probleemid. Aitäh küsimuse eest!

(Täpsustus: Shell-skriptide sidumine on eemaldatud) selles probleemis)

Tere õhtust! Aitäh ettekande eest! Mind huvitab catchup-funktsioon, millest rääkisite. Olite silmitsi olukorraga, kus replikatsioon jäi maha, mis ei suutnud kuidagi järgi jõuda. Ja ma ei leidnud WAL-G-ist selle funktsiooni kirjeldust dokumentatsioonis.

Catchup ilmus sõna otseses mõttes 2020. aasta jaanuari 20. päevadel. Dokumentatsiooniga võib-olla tasuks natuke paremini töötada. Me ise kirjutame seda ja kirjutame seda mitte just superhästi. Ja võib-olla peaksime üliõpilastelt nõudma, et nad seda kirjutaksid.

Kas see on juba välja antud?

Pull request on juba ühendatud, s.t. ma olen selle kontrollinud. Proovisin seda testklastris. Praegu ei ole meil olnud olukorda, kus saaksime seda tootmisnäitel katsetada.

Millal oodata?

Ma ei tea. Oodake kuud, me kindlasti kontrollime.

Allikas: habr.com