Ju propozoj të njiheni me shpjegimin e raportit të fillimit të vitit 2020 nga Georgi Rylov "WAL-G: mundësi të reja dhe zgjerimi i komunitetit"
Maintainerët e open-source përballen me shumë probleme ndërsa rriten. Si të shkruajmë më shumë tipare të kërkuara, të rregullojmë më shumë issues dhe të arrijmë të shikojmë më shumë pull request? Në shembullin e WAL-G (mjete për backup për PostgreSQL) do të flas për mënyrën se si i zgjidhëm këto probleme duke nisur një kurs për zhvillimin Open-source në universitet, çfarë arritëm dhe ku do të shkojmë më tej.
Përshëndetje të gjithëve përsëri! Unë jam zhvillues në Yandex nga Ekaterinburgu. Dhe sot do të flas për WAL-G.
Në titullin e raportit nuk ishte përmendur se është diçka mbi backup-et. A di ndokush se çfarë është WAL-G? Apo të gjithë e dinë? Ndizni dorën, kush nuk e di. Wow, erdhët në raport dhe nuk e dini se për çfarë është.
Le të tregoj se çfarë do të ndodhë sot. Ndodhi që ekipi ynë merret me backup prej një kohe të gjatë. Dhe ky është një raport tjetër në serinë ku tregojmë se si ruajmë të dhënat në mënyrë të sigurt, të besueshme, të përshtatshme dhe efikase.
Në epizodat e mëparshme kishte shumë raportime nga Andrei Borodin, Vladimir Leskov. Ne ishim shumë. Dhe të gjithë ne flasim për WAL-G tashmë për shumë vite.
clck.ru/F8ioz —
clck.ru/Ln8Qw —
Ky raport do të dallojë pak nga të tjerët, sepse ai do të fokusohet më shumë në pjesën teknike, ndërsa këtu do të tregoj si u përballëm me problemet e lidhura me rritjen e komunitetit. Dhe si erdhëm me një ide të vogël që na ndihmon të përballojmë këtë.
Disa vite më parë WAL-G ishte një projekt mjaft i vogël që morëm nga Citus Data. Dhe ne vetëm e morëm. Dhe e zhvillonte një person.
Dhe vetëm në WAL-G nuk kishte:
- Backup nga replika.
- Nuk kishte backup-e inkrementale.
- Nuk kishte backup-e WAL-Delta.
- Dhe ende shumë gjëra të tjera nuk ishin të pranishme.
Gjatë këtyre disa viteve, WAL-G ka pësuar një rritje të madhe.
Dhe deri në vitin 2020, gjithçka e përmendur më lart ishte tashmë e pranishme. Dhe përveç kësaj, tani kemi:
- Më shumë se 1,000 yje në GitHub.
- 150 forka.
- Rreth 15 PR të hapura.
- Dhe shumë kontributorë të tjerë.
- Dhe çështje të hapura vazhdimisht. Dhe kjo është në atë pikë që ne shkojmë atje çdo ditë, bëjmë diçka me këtë.
Dhe arritëm në përfundimin se ky projekt kërkon më shumë vëmendjen tonë, edhe atëherë kur vetë nuk kemi nevojë për të realizuar diçka për shërbimin tonë Managed Databases në Yandex.
Dhe diku në vjeshtën e vitit 2018, na erdhi një ide. Në përgjithësi, ekipi ka disa mënyra si të krijojë ndonjë funksionalitet, të riparojë bugs, nëse iu mungojnë duar. Për shembull, mund të angazhoni një zhvillues të ri dhe t'i paguani atij para. Ose mund të merrni një praktikant për njëfarë kohe dhe gjithashtu t'i paguani një pagë. Por ka edhe një grup të konsiderueshëm njerëzish, pjesa e të cilëve tashmë di që të shkruaj kod. Thjesht nuk e dini gjithnjë se çfarë cilësie ka ky kod.
Kemi menduar dhe vendosur të përfshijmë studentë. Por studentët nuk do të angazhohen në çdo aspekt. Ata do të marrin përsipër vetëm disa detyra. Për shembull, ata do të shkruajnë teste, do të rregullojnë gabime dhe do të implementojnë veçori që nuk prekin funksionalitetin kryesor. Funksionaliteti kryesor është krijimi dhe rikuperimi i backup-eve. Nëse ndodh një gabim në krijimin e një backup-i, atëherë ne do të humbasim të dhëna. Dhe askush nuk e dëshiron këtë, sigurisht. Të gjithë duan që gjithçka të jetë shumë e besueshme. Prandaj, kodi që ne i besojmë më pak se kodit tonë personal, ne sigurisht nuk do ta lejojmë atë. Domethënë, çdo kod jo kritik është ajo që do të dëshironim të merrnim nga duar të tjera pune.
Në cilat kushte pranohet PR-i i studentit
- Ata janë të detyruar ta mbulojnë kodin e tyre me teste. Gjithçka duhet të kalojë në CI.
- Dhe gjithashtu kalojmë 2 rishikime. Një të Andrey Borodin dhe një të imën.
- Për më tepër, për të verifikuar që kjo nuk do të thyejë asgjë në shërbimin tonë, unë veçmas ngarkoj një ndërtim me këtë komit. Dhe ne verifikojmë në testet end-to-end që asgjë nuk dështojmë.
Kurs i veçantë për Open Source
Pak sa për atë se përse është e nevojshme dhe pse mendoj se është një ide e mrekullueshme.
Për ne, përfitimi është i qartë:
- Ne kemi më shumë duar për të punuar.
- Dhe po kërkojmë kandidatë për ekipin midis studentëve të zellshëm, të cilët shkruajnë kod të mirë.
Cili është përfitimi për studentët?
Ato mund të jenë më pak të qarta, sepse studentët, të paktën, nuk marrin para për kodin që shkruajnë, por marrin vetëm nota në regjistrin e tyre.
I pyeta ata për këtë. Dhe sipas tyre:
- Përvoja si kontribues në Open Source.
- Të marrin një rresht në CV.
- Të shprehin veten dhe të kalojnë një intervistë në Yandex.
- Të bëhen pjesëmarrës në GSoC.
- +1 kurs specialistik për ata që duan të shkruajnë kod.
Nuk do të flas për mënyrën se si ishte organizuar kursi. Do të them vetëm se WAL-G ishte projekti kryesor. Gjithashtu, përfshimë projekte si Odyssey, PostgreSQL dhe ClickHouse në këtë kurs.
Dhe dhëmë detyra jo vetëm në këtë kurs, por gjithashtu lëshuam diploma dhe punime kursi.
Çfarë përfitimi ka për përdoruesit?
Tani kalojmë në pjesën që ju intereson, çfarë do të fitoni nga kjo? Përfitimi është se studentët kanë riparuar shumë gabime. Dhe kanë bërë kërkesa për funksione që na keni kërkuar të bëjmë.
Le të flas për gjërat që ju keni dashur prej një kohe dhe që janë realizuar.
Mbështetje për tablespaces. Tablespaces në WAL-G janë pritur ndoshta që nga publikimi i WAL-G, sepse WAL-G është pasardhës i një mjeti tjetër rezervimi, WAL-E, ku ishin mbështetur kopjet rezervë të bazave të të dhënave me tablespaces.
Le të kujtoj se çfarë është kjo dhe përse është e nevojshme. Si rregull, të gjitha të dhënat e Postgres zënë një direktori në sistemin e skedarëve, e cila quhet bazike. Dhe kjo direktori përmban të gjitha skedarët dhe nën-drektoritë e nevojshme për Postgres.
Tablespaces janë direktori ku ndodhen të dhënat e Postgres, por ato nuk ndodhen jashtë direktorisë bazike. Në slajd shihet se tablespac’ët janë jashtë direktorisë bazike.
Si duket kjo për vetë Postgres? Në direktorinë bazike ka një nën-drejtori të veçantë pg_tblspc. Dhe aty ndodhen lidhjet simbolike për direktoritë ku realisht ndodhen të dhënat e Postgres jashtë direktorisë bazike.
Kur përdorni të gjitha këto, komandat mund të duken kështu për ju. Pra, krijoni një tabelë në ndonjë tablespace të caktuar dhe shihni se ku ndodhet aktualisht. Këto dy rreshta të fundit, dy komandat e fundit të thirrura. Dhe aty duket se ka një rrugë. Por në fakt – kjo nuk është një rrugë e vërtetë. Kjo është një rrugë me prefiksin nga direktorja themelore për në tablespace. Dhe nga aty ajo është e lidhur me një symlink, i cili çon në të dhënat tuaja reale.
Ne nuk e përdorim këtë në ekipin tonë, por shumë përdorues të tjerë të WAL-E e përdorën këtë dhe na shkruan se donin të migronin në WAL-G, por kjo i pengonte. Tani, kjo mb suporton.
Një funksion tjetër që na solli kursi ynë i specializuar është catchup. Rreth catchup e dinë njerëzit që ndoshta kanë punuar më shumë me Oracle se sa me Postgres.
Një përmbledhje e asaj se çfarë është. Kështu mund të duket zakonisht topologjia e klasterit në shërbimin tonë. Kemi një master. Ka një replikë që transmeton nga të ajo logun para-shkruese. Dhe riplikimi e thotë masterit në cilin LSN ndodhet aktualisht. Dhe ndoshta paralelisht me këtë, mund të arkivohet jurnali. Përveç arkivimit të jurnalit, po ashtu dërgohen backupet në re. Dhe dërgohen backupet delta.
Cila mund të jetë problemi? Kur keni një bazë mjaft të madhe, mund të ndodhë që riplikimi fillon të mbetet shumë pas masterit. Dhe ai mbetet kaq shumë pas, saqë nuk mund ta arrijë kurrë. Ky problem zakonisht duhet zgjidhur në një farë mënyre.
Dhe mënyra më e thjeshtë është të hiqni replikimin dhe ta ringarkoni atë nga e para, sepse ajo nuk do të arrijë kurrë më, dhe me problemin duhet të merremi. Por kjo është shumë e gjatë, sepse rikthimi i një backupi të plotë të një baze prej 10 TB është shumë, shumë e gjatë. Dhe ne duam ta bëjmë gjithçka sa më shpejt të jetë e mundur, nëse ndodhin probleme të tilla. Dhe pikërisht për këtë është menduar catchup.
Catchup lejonë përdorimin e delta-backup-eve, të cilat ruhen në re në këtë mënyrë. Ju tregoni se në cilin LSN ndodhet tani replika që është pas, dhe e specificoni atë në komandën catchup për të krijuar një delta-backup mes atij LSN dhe LSN në të cilin ndodhet tani klasteri juaj. Më pas, e ristabëlsoni këtë backup në replikën që ishte pas.
Të tjera baza
Gjithashtu, studentët na sollën menjëherë shumë karakteristika. Pasi ne në Yandex zhvillojmë jo vetëm Postgres, kemi gjithashtu MySQL, MongoDB, Redis, ClickHouse, ndodhi që në një moment na duhej të mundeshim të bënim backup me rikuperim nga pikë në kohë për MySQL, dhe që kishte mundësinë t'i ngarkonim ato në re.
Dhe dëshironim ta bënim këtë në një mënyrë të ngjashme me mënyrën se si e bën WAL-G. Prandaj, vendosëm të eksperimentojmë dhe të shohim si do të duket tutto.
Dhe në fillim, duke mos e ndarë fare këtë logjikë në fork, shkruam kodin. E pashë se kishim një model funksional dhe mund të funksiononte. Më pas, menduam se komuniteti ynë kryesor është postgres’istët, ata përdorin WAL-G. Prandaj, duhet të ndajmë ndonjëherë këto pjesë. Kështu që, kur rregullojmë kodin për Postgres, nuk prishim MySQL; kur rregullojmë MySQL, nuk prishim Postgres.
Ideja e parë për ndarjen e këtij procesi ishte të përdorej i njëjti qasje siç përdoret në zgjerimet e PostgreSQL. Dhe, në thelb, për të bërë një backup të MySQL, duhet të instalonit një bibliotekë dinamike.
Por këtu duket menjëherë asimetria e këtij qasje. Kur bëni backup në Postgres, instaloni një backup të zakonshme për Postgres dhe gjithçka shkon mirë. Ndërsa për MySQL, rezulton se instaloni një backup për Postgres dhe më pas një bibliotekë dinamike për MySQL. Tingëllon ndoshta pak çuditshëm. Edhe ne menduam kështu dhe vendosëm që ky nuk është zgjidhja që na nevojitet.
Ndarje të ndryshme për Postgres, MySQL, MongoDB, Redis
Por kjo na lejoi, siç mendojmë ne, të arrijmë në zgjidhjen e duhur – të ndashin ndarjet e ndryshme për baza të ndryshme. Kjo lejon izolimin e logjikës që lidhet me backupet e ndryshme të bazave të të dhënave, të cilat do të drejtohen ndaj një API të përbashkët që implementon WAL-G.
Kjo është pjesa që e shkruam vetë – para se t’u jepnim studentëve detyra. Kjo është pikërisht pjesa ku ata mund të bënin diçka gabim, prandaj vendosëm që është më mirë të bëjmë diçka siç duhet dhe gjithçka do të shkojë mirë.
Pas këtij, ne lëshuam disa detyra. Ato u morën menjëherë. Nga studentët kërkohej të mbështesnin tri baza të dhënash.
Kjo është MySQL, e cila ne e rezervojmë me ndihmën e WAL-G në këtë mënyrë tashmë më shumë se një vit.
Dhe tani MongoDB po i afrohet prodhimit, aty po e përmirësojnë me dorë. Në thelb, ne shkruam kornizën për të gjitha këto. Më pas studentët shkruan disa gjëra funksionale. Dhe pastaj ne i çojmë ato në një gjendje që mund të pranojmë në prodhimin tonë.
Këto detyra nuk dukeshin ashtu që studentët duhej të shkruanin mjete back-up të plota për secilën nga këto baza. Ne nuk kishim këtë problem. Problemi ynë ishte se donim rikuperim në pikë të kohës dhe donim të bënim rezervë në cloud. Dhe kërkuam nga studentët të shkruanin ndonjë kod, i cili do të zgjidhte këtë. Studentët shfrytëzuan mjete rezervë ekzistuese, të cilat e bëjnë rezervimin, dhe pastaj e lidhën këtë me WAL-G, që e dërgonte gjithçka në cloud. Po kështu, ata shtuan rikuperim në pikë të kohës.
Çfarë tjetër sollën studentët? Ata sollën në WAL-G mbështetje për enkriptimin Libsodium.
Tani kemi politika të ruajtjes së kopjeve rezervë. Tani kopjet rezervë mund të shënohen si të përhershme. Dhe ndërlikon më shumë që për shërbimin tuaj të automatizoni procesin e ruajtjes së tyre.
Çfarë rezultati u arrit nga ky eksperiment?
Për kursin fillimisht ishin regjistruar më shumë se 100 persona. Në fillim nuk thashë se universiteti në Jekaterinburg është Universitete Federale Ural. Aty e kemi njoftuar gjithçka. 100 persona u regjistruan. Në realitet, diçka filloi të bëhej shumë më pak, rreth 30 persona.
Kurset e mbyllën edhe më pak njerëz, sepse duhej të shkruhen teste për kodet që tashmë ekzistojnë. Dhe gjithashtu të rregullohet ndonjë bug ose të bëhet ndonjë funksion. Dhe disa studentë e mbyllën kursin.
Në këtë moment, studentët për këtë kurs kanë ndrequr rreth 14 issues, kanë bërë 10 funksione të ndryshme. Dhe, siç mendoj, kjo është një zëvendësim i plotë për një ose dy zhvillues.
Përveç gjithçkaje, ne ndamë diploma dhe projekte kursi. Dhe 12 morën diplomën. 6 prej tyre tashmë e kanë mbrojtur me nota '5'. Për të tjerët mbrojtjet nuk kanë ndodhur ende, por mendoj se gjithashtu do t'iu shkojë mirë.
Planet për të ardhmen
Çfarë plane kemi për të ardhmen?
Së paku, këto janë disa nga karakteristikat që kemi dëgjuar nga përdoruesit dhe dëshirojmë t'i realizojmë. Këto përfshijnë:
- Monitorimi i saktësisë së ndjekjes së kronologjisë në arkivën e backup-eve të klasterit HA. Me ndihmën e WAL-G, kjo është e mundur. Dhe mendoj se do të kemi studentë të gatshëm për ta marrë përsipër këtë.
- Për migrimin e backup-eve dhe WAL-it midis mjeteve tona, kemi tashmë një person të caktuar përgjegjës.
- Kemi publikuar së fundmi idenë se mund ta akcelerojmë edhe më shumë WAL-G-në përmes shpërndarjes së backup-eve inkrementale pa rinovimin e faqeve dhe optimizimin e arkivave që i dërgojmë atje.
Mund të ndani ato këtu
Çfarë përcolli ky raport? Tani, përveç katër nesh që mbështesim këtë projekt, kemi gjithashtu duar shtesë, të cilat janë mjaft të shumta. Sidomos nëse iu shkruani në mesazh të drejtpërdrejtë. Dhe nëse bëni backup të të dhënave tuaja dhe e bëni këtë me ndihmën e WAL-G, ose nëse do të dëshironit të migroni në WAL-G, atëherë ne mund t'i marrim dëshirat tuaja në konsideratë mjaft lehtësisht.
Ky është kodi qr dhe lidhja. Mund të kaloni përmes tyre dhe të shkruani të gjitha dëshirat tuaja. Për shembull, ne nuk e rregullojmë ndonjë bog. Ose ndonjë tipar që ju e dëshironit shumë, por për ndonjë arsye nuk është ende në asnjë rezervë, përfshirë edhe tonën. Sigurohuni që të shkruani për këtë.
Pyetje
Përshëndetje! Faleminderit për raportin! Kam një pyetje për WAL-G, por jo për Postgres. WAL-G bën backup për MySQL dhe thërret ekstra-ndihmë. Nëse merrni instalimet moderne në CentOS dhe nëse bëni yum install MySQL, do të instalohet MariDB. Që nga versioni 10.3, ekstra-ndihma nuk mbështetet, mbështetet MariDB-backup. Si e keni situatën me këtë?
Në këtë moment nuk kemi provuar të bëjmë backup për MariDB. Kishim kërkesa për mbështetje për FoundationDB, por në përgjithësi, nëse ka një kërkesë të tillë, mund të gjejmë njerëz që munden ta bëjnë këtë. Nuk është kaq e gjatë dhe as kaq e lehtë, sa më duket.
Mirëdita! Faleminderit për raportin! Kam një pyetje për potencialisht tiparet e reja. A jeni të gatshëm ta bëni WAL-G të punojë me kasetat, në mënyrë që të mund të bëni backup në kaseta?
A është backup në ruajtjen me kaseta që i referoheni?
Po.
Atje është Andrei Borodin, i cili mund të përgjigjet më mirë për këtë çështje se sa unë.
(Andi) Po, faleminderit për pyetjen! Kemi pasur një kërkesë për të transferuar një backup në kasetë nga ruajtja cloud. Dhe për këtë transferimi mes cloud-eve. Sepse transferimi mes cloud-eve është një version i përgjithshëm i transferimit në kasetë. Për më tepër, kemi një arkitekturë të zgjerueshme në pjesën e Ruajtjes. Nga ana tjetër, shumë nga Ruajtjet janë shkruar nga studentët. Dhe nëse shkruani një Ruajtje për kasetën, atëherë sigurisht që do të mbështetet. Jemi të gatshëm të shqyrtojmë pull request-et. Duhet të shkruhet një skedë, të lexoni skedën. Nëse këto gjëra realizohen në Go, zakonisht dalin 50 rreshta kodi. Atëherë në WAL-G do të mbështetet kaseta.
Faleminderit për raportin! Një proces zhvillimi interesant. Backup-i është një pjesë serioze e funksionalitetit që duhet të mbulohet mirë me teste. Ju, kur realizuat funksionalitetin për bazat e reja, a i keni shkruar testet studentët ose i keni shkruar ju vetë testet dhe pastaj ua keni dorëzuar realizimin studentëve?
Testet i kanë shkruar gjithashtu studentët. Por studentët kanë shkruar më shumë për tipologji të tilla si bazat e reja. Ata shkruan teste integruese. Dhe ata shkruan teste njësi. Nëse testet integruese kalojnë, dmth tani – ky është skenari që e ekzekutoni me duar ose e bën cron, për shembull. Pra, ky skenar është shumë i qartë.
Studentët nuk kanë shumë përvojë. A shpenzohet shumë kohë për rishikim?
Po, rishikimi merr mjaft kohë. Pra, zakonisht, kur vijnë disa kontribues menjëherë dhe thonë se unë bëra këtë, unë bëra atë, është e nevojshme të mendoni dhe të rezervoni diku gjysmën e ditës për të kuptuar se çfarë kanë shkruar. Sepse kodi duhet të lexohet me kujdes. Ata nuk kaluan intervista. Ne nuk i njohim shumë mirë, prandaj kjo merr një kohë të konsiderueshme.
Faleminderit për raportin! Më parë, Andrey Borodin deklaroi se archive_command në WAL-G duhet të thirret drejtpërdrejt. Por në rastin e ndonjë klasteri patron, na nevojitet një logjikë të shtuar për të përcaktuar nodin nga i cili të dërgojmë valët. Si e zgjidhni ju këtë problem?
Në çfarë problemi po përballeni këtu? Supozoni se keni një replikë sinkrone nga e cila po merrni kopje rezervë? Ose çfarë?
(Andrei) Problemi është se vërtet WAL-G parashikon përdorimin pa shell-skripte. Nëse diçka mungon, le të shkruajmë logjikën që duhet të jetë brenda WAL-G. Sa i përket burimit nga e cila duhet të bëhet arkivimi, ne besojmë se arkivimi duhet të bëhet nga master-i aktual në klaster. Arkivimi nga replika është një ide e keqe. Ka skenarë të ndryshëm me probleme. Në veçanti, probleme me arkivimin e linjave të kohës dhe informacionit të tjera shtesë. Faleminderit për pyetjen!
(Sqarim: U hoqën skriptet shell) )
Mirëmëngjes! Faleminderit për prezantimin! Më interesoi karakteristika catchup, për të cilën treguat. Keni hasur në situata kur replika po vonohej dhe s’po arrinte të përputhej. Dhe unë në WAL-G nuk e gjeta përshkrimin e kësaj veçorie në dokumentacione.
Catchup u shfaq dosido në fundjavën e 20-të të janarit 2020. Mund të merret më mirë me dokumentacionin. Ne e shkruajmë dhe nuk e shkruajmë ashtu siç duhet. Dhe ndoshta duhen kërkuar nga studentët që ta shkruajnë ata.
A është në lëshim tashmë?
Kërkesa për tërheqje është miratuar tashmë, që do të thotë se unë e kam kontrolluar atë. E kam provuar në klasterin e testimit. Deri tani, nuk kemi pasur situata ku mund të kontrollonim këtë në një shembull në prodhim.
Kur të pritet?
Nuk e di. Prisni një muaj, do ta verifikojmë me siguri.
Burimi: habr.com
