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

Soovitan tutvuda Georgi Rõlovi 2020. aasta alguses peetud ettekande "WAL-G: uued võimalused ja kogukonna laienemine" kokkuvõttega

Open-source'i hooldajatele tekib kasvades palju probleeme. Kuidas kirjutada järjest rohkem vajalikke funktsioone, parandada üha rohkem probleeme ja jõuda järjest enam pull request'ide vaatamiseni? WAL-G (PostgreSQLi varundustööriist) näitel räägin, kuidas me neid probleeme lahendasime, käivitades avatud lähtekoodiga arenduse kursuse ülikoolis, mida me saavutasime ja kuhu edasi liikuda plaanime.

Tere kõigile veel kord! Olen arendaja Yandexis Jekaterinburgis. Täna räägin WAL-G-st.

Ettekanne pealkirjas ei olnud öeldud, et see on seotud varundustega. Kas keegi ei tea, mis on WAL-G? Kas kõik teavad? Palun tõstke käsi, kes ei tea. Jõhkralt, te tulite ettekanne kuulama ja ei tea, millest see on.

Las ma räägin, mis täna toimub. Meie meeskond on juba mõnda aega varundamisega tegelenud. See on veel üks ettekande osa seeriast, kus räägime sellest, kuidas me hoiame andmeid turvaliselt, usaldusväärselt, mugavalt ja efektiivselt.

Eelnevad osad sisaldasid palju ettekandeid Andrei Borodini ja Vladimir Leskovi poolt. Meid oli palju. Ja me kõik oleme rääkinud WAL-G-st juba palju aastaid.

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

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

See ettekanne erineb veidi teistest, kuna see keskendub rohkem tehnilisele poolele. Räägin, kuidas me kohtasime probleemidega, mis olid seotud kogukonna kasvuga. Ja kuidas me mõtlesime välja väikese ideed, mis aitab meil sellega toime tulla.

Mõned aastad tagasi oli WAL-G üsna väike projekt, mille saime Citus Datalt. Me lihtsalt võtsime selle üle. Ja seda arendas ainult üks inimene.

Ja WAL-G-s ei olnud:

• Replikatsioonist varukoopiaid.
• Ei olnud inkrementaalset varukoopiaid.
• Ei olnud WAL-Delta varukoopiaid.
• Ja veel palju muud polnud.

Nende aastate jooksul on WAL-G tugevasti kasvanud.

Ja 2020. aastaks olid kõik ülaltoodud omadused juba olemas. Ja sellele lisandus veel see, et meil on nüüd:

• Rohkem kui 1 000 tähte GitHubis.
• 150 fork'i.
• Umbes 15 avatud PR-i.
• Ja veel palju kontribuutoreid.
• Ja avatud probleeme on pidevalt. Ja see on arvestades, et me käime seal sõna otseses mõttes iga päev ja teeme midagi selle nimel.

Ja jõudsime järeldusele, et see projekt vajab rohkem meie tähelepanu, isegi siis, kui meil endil ei ole vaja midagi meie hallatavate andmebaaside teenuse jaoks Yandext rakendada.

Ja kuskil 2018. aasta sügisel tuli meile idee. Tavaliseeriti, et meeskonnal on mitmeid viise, kuidas funktsioone arendada ja vigu parandada, kui käsi on puudu. Näiteks võite palgata veel ühe arendaja ja maksta talle raha. Või võite võtta praktikandi teatud ajaks ja maksta ka talle mingit palka. Kuid on ka veel päris suur hulk inimesi, kellest osa oskab juba tegelikult koodi kirjutada. Lihtsalt te ei tea alati, millise kvaliteediga see kood on.

Oleme mõelnud ja otsustanud üritada tudengeid kaasata. Kuid tudengid ei osale meil kõiges. Nad teevad ainult osa tööst. Näiteks kirjutavad nad teste, parandavad vigu ja rakendavad funktsioone, mis ei mõjuta põhifunktsionaalsust. Põhifunktsionaalsus on varukoopiate loomine ja nende taastamine. Kui lasta sisse viga varukoopia loomises, kaotame andmed. Ja keegi ei taha seda, loomulikult. Kõik soovivad, et kõik oleks väga usaldusväärne. Seetõttu ei soovi me lubada koodi, millele me ei usalda vähem kui omaenda. St iga mittetähtis kood on see, mida sooviksime saada oma lisatöötajate käest.

Millistel tingimustel aktsepteeritakse tudengi PR-i

• Nad peavad katma oma koodi testidega. Kõik peab läbima CI.
• Ja läbinud 2 ülevaatust. Üks Andrei Borodini ja üks minu omalt.
• Lisaks, et veenduda, et see ei riku midagi meie teenuses, laadisin ma eraldi selle päringuga üles ehituse. Ja me kontrollime end-to-end testides, et meil ei jää midagi katki.

Erikursus avatud lähtekoodiga

Veidi sellest, miks see vajalik on ja miks see, minu arvates, on äge idee.

Meile on kasu ilmne:

• Me saame täiendavaid käsi.
• Ja otsime meeskonda andekaid tudengeid, kes kirjutavad head koodi.

Milline on kasu tudengitele?

See võib olla vähem ilmne, sest tudengid, vähemalt, ei saa raha selle eest, mida nad kirjutavad, vaid saavad ainult hindesüsteemi punkte.

Küsin nende käest. Ja nende sõnul:

• Open Source'i kontributori kogemus.
• Saada rida oma CV-sse.
• Tõestada ennast ja läbida vestlus Yandexis.
• Osaleda GSoCi-s.
• +1 erikursus neile, kes soovivad koodi kirjutada.

Ma ei hakka rääkima, kuidas kursus oli üles ehitatud. Ütlen ainult, et WAL-G oli põhiprojekt. Lisaks sisaldas see kursus ka projekte nagu Odyssey, PostgreSQL ja ClickHouse.

Ja andsime ülesandeid mitte ainult sellel kursusel, vaid andsime välja ka diplomeid ja kursusetöid.

Aga milline on kasu kasutajatele?

Nüüd liigume osa juurde, mis tõenäoliselt huvitab teid. Mis kasu teil sellest on? Kasu on selles, et tudengid parandasid palju vigu. Ja tegid funktsioonitaotlusi, mida te soosite, et me teeksime.

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

Tablespace'ide tugi. Tablespace'id WAL-G-s on oodatud juba WAL-G väljaandmisest saadik, kuna WAL-G on WAL-E nimelise teise varundustööriista järeltulija, kus oli toetatud andmebaaside varukoopiad tablespace'idega.

Kordaks lühidalt, mis asi see on ja miks see vajalik on. Üldiselt hõivavad kõik vahemälu Postgres'i andmed ühe kausta failisüsteemis, mida nimetatakse baasiks. See kaust sisaldab kõiki faile ja alamkaustu, mis on Postgres'ile vajalikud.

Tablespace'id on kaustad, kus asuvad Postgres'i andmed, kuid need ei asu baasikaustast väljas. Slidil on näha, et tablespace'id asuvad väljaspool baasi kausta.

Kuidas see Postgres’is välja näeb? Baasikaustas on eraldi alamkaust pg_tblspc. Ja selle sees on sümboolsed lingid kaustadele, kus asuvad Postgres'i andmed väljaspool baasikausta.

Kui te seda kõike kasutate, võivad need käsud teie jaoks välja näha umbes nii. St. loote tabeli mõnes määratud tablespace'is ja vaatate, kus see nüüd asub. Need kaks viimast rida, kaks viimast käsku. Sealt on näha, et seal on mingi tee. Aga tegelikult – see ei ole tõeline tee. See on tee, millel on eeltingimus põhikaustast tablespace'i. Ja sealt on see seotud sümboolse lingiga, mis viib teie tegelike andmeteni.

Meie tiimis seda kõike ei kasutata, kuid paljude teiste WAL-E kasutajate seas, kes kirjutasid meile, et nad soovivad üle minna WAL-G-le, oli see probleemiks. Nüüd on see toetatud.

Teine funktsioon, mille meie spetsiaalne kursus meile tõi, on catchup. Catchupist teavad inimesed, kes on ilmselt rohkem töötanud Oracle'iga kui Postgres'iga.

Lühidalt, mis see on. Nii võib meie teenuse klastritopoloogia välja näha. Meil on peamine server. On replikatsiooniserver, mis voogedastab sellest write-ahead log'i. Ja replikatsiooniserver ütleb peamisele serverile, millisel LSN-il ta praegu on. Ja samal ajal võib log'i arhiivida. Lisaks log'i arhiivimisele saadetakse ka varukoopiad pilve. Ja saadetakse delta-varukoopiad.

Milline võib olla probleem? Kui teil on üsna suur andmebaas, võib juhtuda, et replikatsiooniserver jääb peamisest serverist tugevalt maha. Ja ta jääb nii palju maha, et ei suuda enam kunagi järele jõuda. Selle probleemi lahendamiseks tuleb tavaliselt midagi ette võtta.

Ja kõige lihtsam viis – on eemaldada replikatsiooniserver ja seadistada see uuesti, kuna ta ei suuda kunagi enam järele jõuda, aga probleemiga tuleb tegeleda. Kuid see võtab üsna kaua aega, kuna 10 TB andmebaasi taastamine on väga, väga aeganõudev. Tahame selliseid probleeme lahendada võimalikult kiiresti. Just selleks ongi mõeldud catchup.

Catchup võimaldab kasutada delta-varukoopiate tegemist, mis salvestatakse pilve sellisel viisil. Te ütlete, millisel LSN-il asub praegu mahajääv replika, ja määrate selle catchup käsus, et luua delta-varukoopia nende LSN-ide vahel, kus asub teie klaster. Seejärel taastate selle varukoopia mahajäävale replikale.

Teised baasid

Veel tõid tudengid meile kohe palju funktsioone. Kuna me Yandaxis töötleme mitte ainult Postgres, meil on ka MySQL, MongoDB, Redis, ClickHouse, siis mingil hetkel vajasime, et saaksime teha varukoopiad point-in-time taastamise võimalusega MySQL jaoks ning et oleks võimalik need pilve laadida.

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

Alguses ei jaganud me seda loogikat ja kirjutasime koodi otse forki. Nägime, et meil on mingi toimiv mudel ja see võib toimida. Hiljem mõtlesime, et meie peamine kogukond on postgres’i kasutajad, kes kasutavad WAL-G-d. Seetõttu tuleb neid osi mingil viisil eraldada, st kui me parandame koodi Postgresi jaoks, ei rikku me MySQL-i, ja kui me parandame MySQL-i, ei rikku me Postgresi.

Esimene idee selle kohta, kuidas seda jagada, oli idee kasutada sama lähenemist, mida kasutatakse PostgreSQL-i laiendustes. Ja põhimõtteliselt, et MySQL-i varundamiseks pidite paigaldama mingi dünaamilise teegi.

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

Erinevad kogud Postgresi, MySQL, MongoDB, Redis jaoks

Kuid see võimaldas meil, nagu me arvame, jõuda õigele lahendusele – eraldada erinevad kogud erinevatele andmebaasidele. See võimaldas isoleerida loogika, mis oli seotud erinevate andmebaaside varundamisega, mis pöördusid ühise API poole, mida rakendab WAL-G.

See on see osa, mille me ise kirjutasime – enne seda, kui andsime õpilastele ülesandeid. St. see on just see osa, kus nad võiksid midagi valesti teha, seetõttu otsustasime, et parem on, kui teeme ise midagi õigesti ja kõik läheb suurepäraselt.

Pärast seda meie andsime ülesandeid. Need kohe jagati ära. Õpilastelt oodati kolme andmebaasi toetust.

See on MySQL, mida me varundame WAL-G abil juba üle aasta sellisel viisil.

Ja nüüd juba MongoDB läheneb produktiivsusele, seal seda lihvitakse. Põhimõtteliselt kirjutasime kogu selle raamistiku meie. Siis kirjutasid õpilased mingeid töötavaid asju. Ja seejärel viime need sellisesse seisundisse, mille me saame oma tootmises aktsepteerida.

Need ülesanded ei tundunud sellistena, et õpilastelt oleks oodatud igasuguste backup-täiendite kirjutamine iga andmebaasi jaoks. Meil sellist probleemi ei olnud. Meie probleem oli see, et soovisime punkt-punkti taastumist ning et tahame varundada pilve. Ja palusime õpilastel kirjutada mingit koodi, mis seda lahendaks. Õpilased kasutasid juba olemasolevaid backup-täiendusi, mis mingil moel varundavad, ja seejärel ühendati see kõik WAL-G-ga, mis edastas selle kõik pilve. Samuti lisati sellele punkt-punkti taastamine.

Mida veel tõid õpilased? Nad tõid WAL-G-le Libsodium krüpteerimise toe.

Nüüd on meil ka varukoopiate säilitamise poliitikad. Nüüd saab varukoopiad tähistada püsivatena. Ja nagu kuidagi mugavam automatiseerida nende säilitamise protsessi teie teenusele.

Mida me selle eksperimendi tulemustena saime?

Alguses registreerus kursusele enam kui 100 inimest. Ma ei öelnud alguses, et Ülikool Ekaterinburgis on Uuralite Föderaalülikool. Seal me kõik kuulutasime välja. 100 inimest registreerus. Tegelikult hakkas reaalselt midagi tegema palju vähem, umbes 30 inimest.

Kursuse lõpetas veel vähem inimesi, kuna seal tuli kirjutada testid olemasolevale koodile. Samuti pidi parandama mingit viga või tegema mingit funktsiooni. Ja osa üliõpilasi lõpetas ikkagi kursuse.

Praeguseks on üliõpilased selle kursuse raames parandanud umbes 14 probleemipunkti, teinud 10 erineva suurusega funktsiooni. Ja mulle tundub, et see on tõeline asendus ühe-kahte arendajat.

Kõikidest neist andsime välja diplome ja kursusetöid. 12 võtsid diplomid. 6 neist on juba kaitsnud «5» hindega. Ülejäänud ei ole veel kaitsnud, kuid ma arvan, et neilgi läheb hästi.

Tulevikuplaanid

Millised on meie tulevikuplaanid?

Kõige vähem on neid funktsioonisoove, mida oleme juba kasutajatelt kuulnud ja mida tahame teostada. Need on:

• Ajaskaalal korraliku jälgimise tagamine HA-kliendi varukoopiate arhiivis. Selleks saame kasutada WAL-G-d. Ja ma arvan, et leidub tudengeid, kes on valmis selle tööga tegelema.
• Varukoopiate ja WAL-i üleviimise eest erinevate pilvede vahel vastutab meil juba üks inimene.
• Olemegi hiljuti avaldanud idee, et saame WAL-G-d veelgi kiiremaks muuta, kasutades inkrementaalsete varukoopiate lahtipakkimist ilma lehekülgede ülekirjutamiseta ja optimeerides arhiive, mida sinna saadame.

Võite neid siin jagada.

Milleks see ettekande eesmärk oli? Selleks, et praegu, peale meie nelja inimese, kes seda projekti toetavad, on meil ka mitmeid lisakäsi. Eriti kui nendele kirjutada isiklikult. Ja kui te teete oma andmete varukoopiaid ning kasutate selleks WAL-G-d või soovite selle peale üle minna, siis saame teie soove üsna lihtsalt arvesse võtta.

See qr-kood ja link. Nende kaudu saate minna ja kirjutada kõik oma soovid. Näiteks mõnda viga me ei lahenda. Või mõnda funktsiooni, mida te väga soovite, aga mis mingil põhjusel pole veel üheski varunduses, sealhulgas meie omas. Kindlasti kirjutage sellest.

Küsimused

Tere! Aitäh ettekande eest! Küsimus on WAL-G kohta, aga mitte Postgresi osas. WAL-G varundab MySQL-i ja kutsub välja ekstra-varunduse. Kui võtta kaasaegsed installatsioonid CentOS-il ja kui teete yum install MySQL, siis installitakse MariDB. Alates versioonist 10.3 ei toetata ekstra-varundust, toetatakse MariDB varundust. Kuidas teil sellega lood on?

Praegu me ei ole üritanud varundada MariDB-d. Meil on olnud päringud FoundationDB toe kohta, aga üldiselt, kui selline päring on, siis saame leida inimesi, kes sellega tegeleksid. See ei ole nii pikk ja mitte nii keeruline, nagu mulle tundub.

Tere päevast! Aitäh ettekande eest! Küsimus on potentsiaalsete uute funktsioonide kohta. Kas olete valmis sundima WAL-G tööle teipidega, et varundust teipidele teha?

Kas mõeldakse varundust lintlao jaoks?

Jah.

Seal on Andrei Borodin, kes sellele küsimusele paremini vastata oskab.

(Andrei) Jah, aitäh küsimuse eest! Meil oli taotlus varukoopia ülekandmiseks lintidele pilveteenusest. Ja selleks on käimas ülekanded pilvede vahel. Sest ülekandmine pilvede vahel on teatud üldistamine ülekandmisest lintidele. Lisaks on meie salvestuste arhitektuur laiendatav. Muide, paljusid salvestusi on kirjutanud üliõpilased. Ja kui te kirjutate salvestuse lintide jaoks, siis see kindlasti saab toetust. Oleme valmis vaatama pull requeste. Seal tuleb faili kirjutada, faili lugeda. Kui need asjad teha Go-s, siis tavaliselt läheb 50 koodi rida. Ja siis toetatakse WAL-G-s linti.

Aitäh ettekande eest! Huvi arendamisprotsessi vastu. Varukoopia on tõsine funktsionaalsus, mis peab olema hästi kaetud testidega. Kui te realiseerisite uute andmebaaside jaoks funktsionaalsust, siis kas testid kirjutasid samuti üliõpilased või kirjutasite testid ise ja andsite seejärel rakendamise üliõpilastele?

Testid tegid samuti üliõpilased. Kuid üliõpilased tegid rohkem selliste funktsioonide jaoks, nagu uued andmebaasid. Nad tegid integratsioonitestid. Ja nad tegid unit-testid. Kui integratsioonitestid läbivad, st hetkel - see on stsenaarium, mida teete käsitsi või teeb selle teie eest näiteks cron. See tähendab, et stsenaarium on väga arusaadav.

Üliõpilastel pole palju kogemusi. Kui palju aega kulub ülevaatamiseks?

Jah, ülevaatamiseks kulub üsna palju aega. See tähendab, et tavaliselt, kui tuleb korraga mitu komiteerijat ja ütlevad, et ma tegin seda, ma tegin toda, siis tuleb mõelda ja eraldada kuskil pool päeva, et mõista, mida nad on kirjutanud. Sest kood tuleb hoolikalt lugeda. Nad ei ole ju intervjuud läbinud. Me ei tunne neid väga hästi, seega võtab see märkimisväärselt aega.

Aitäh ettekande eest! Varem on Andrei Borodin kinnitanud, et archive_command WAL-G-s peab olema otse kutsutud. Kuid mõne patroonklasteri puhul vajame täiendavat loogikat, et määrata, millisest noodist saata vahu. Kuidas te seda probleemi enda juures lahendate?

Milles teisel teema juures probleem on? Oletame, et teil on sünkroonne koopia, millest teete varukoopia? Või mis?

(Andrei) Asi on selles, et tõepoolest eeldab WAL-G shell-skriptide puudumist. Kui midagi on puudu, siis laske meil kirjutada loogika, mis peaks olema WAL-G sees. Mis puudutab arhiveerimise alguskohta, siis usume, et arhiveerimine peaks toimuma praeguselt peMasterilt klastris. Arhiveerimine koopiast on halb mõte. Seal võivad tekkida erinevad probleemiskenenaarid. Eelkõige ajakava arhiveerimise ja muude lisainformatsioonidega seotud probleemid. Aitäh küsimuse eest!

(Selgitus: Shell-skriptide mähistest on loobutud selles issue)

Tere õhtust! Aitäh ettekande eest! Mind huvitas catchup funktsioon, millest rääkisite. Olen kokku puutunud olukorraga, kus koopia jäi maha ja ei saanud kuidagi järele. Ja WAL-G-s ei leidnud ma selle funktsiooni kirjeldust dokumentatsioonis.

Catchup ilmus sõna otseses mõttes 20. jaanuari paiku 2020. Ahn dokumentatsiooniga tasuks võib-olla rohkem tööd teha. Me kirjutame seda ise ja ei kirjuta seda just super hästi. Ja võib-olla peaksime üliõpilastelt rohkem nõudma, et nad seda kirjutaksid.

Kas see on juba välja antud?

Pull request on juba ühendatud, st olen selle üle vaadanud. Proovisin seda testklastris. Meil pole seni olnud olukorda, kus saaksime seda tootmisnäites kontrollida.

Millal oodata?

Ma ei tea. Oodake kuu aega, siis kontrollime täpselt.

Allikas: habr.com