Unë ju sugjeroj të lexoni transkriptin e raportit të fillimit të vitit 2020 nga Georgy Rylov "WAL-G: mundësi të reja dhe zgjerimi i komunitetit"
Mbajtësit me burim të hapur përballen me shumë sfida ndërsa rriten. Si të shkruani gjithnjë e më shumë veçori të kërkuara, të rregulloni gjithnjë e më shumë probleme dhe të arrini të shikoni gjithnjë e më shumë kërkesa për tërheqje? Duke përdorur WAL-G (vegël rezervë për PostgreSQL) si shembull, unë do t'ju tregoj se si i zgjidhëm këto probleme duke nisur një kurs mbi zhvillimin me burim të hapur në universitet, çfarë arritëm dhe ku do të shkojmë më pas.
Përshëndetje përsëri të gjithëve! Unë jam një zhvillues Yandex nga Yekaterinburg. Dhe sot do të flas për WAL-G.
Titulli i raportit nuk thoshte se bëhej fjalë për kopje rezervë. A e di dikush se çfarë është WAL-G? Apo e dinë të gjithë? Ngrini dorën nëse nuk e dini. Mot i shenjtë, ju erdhët në raport dhe nuk e dini se për çfarë bëhet fjalë.
Më lejoni t'ju them se çfarë do të ndodhë sot. Ndodh që ekipi ynë ka bërë kopje rezervë për mjaft kohë. Dhe ky është një tjetër raport në një seri ku flasim për mënyrën se si i ruajmë të dhënat në mënyrë të sigurt, të sigurt, të përshtatshme dhe efikase.
Në seritë e mëparshme kishte shumë raporte nga Andrei Borodin dhe Vladimir Leskov. Ishim shumë prej nesh. Dhe ne kemi folur për WAL-G për shumë vite.
clck.ru/F8ioz -
clck.ru/Ln8Qw -
Ky raport do të jetë pak më ndryshe nga të tjerët në atë që kishte të bënte më shumë me pjesën teknike, por këtu do të flas sesi kemi hasur probleme që lidhen me rritjen e komunitetit. Dhe si na erdhi një ide e vogël që na ndihmon ta përballojmë këtë.
Disa vite më parë, WAL-G ishte një projekt mjaft i vogël që e morëm nga Citus Data. Dhe ne sapo e morëm atë. Dhe u zhvillua nga një person.
Dhe vetëm WAL-G nuk kishte:
- Rezervimi nga një kopje.
- Nuk kishte rezerva shtesë.
- Nuk kishte kopje rezervë të WAL-Delta.
- Dhe ende mungonte shumë.
Gjatë këtyre pak viteve, WAL-G është rritur shumë.
Dhe deri në vitin 2020, të gjitha sa më sipër janë shfaqur tashmë. Dhe kësaj iu shtua ajo që kemi tani:
- Më shumë se 1 yje në GitHub.
- 150 pirunë.
- Rreth 15 PR të hapura.
- Dhe shumë kontribues të tjerë.
- Dhe çështje të hapura gjatë gjithë kohës. Dhe kjo pavarësisht nga fakti se ne fjalë për fjalë shkojmë atje çdo ditë dhe bëjmë diçka për të.
Dhe arritëm në përfundimin se ky projekt kërkon më shumë vëmendjen tonë, edhe kur ne vetë nuk kemi nevojë të zbatojmë asgjë për shërbimin tonë të Bazave të të Dhënave të Menaxhuara në Yandex.
Dhe diku në vjeshtën e vitit 2018, na erdhi në mendje një ide. Zakonisht ekipi ka disa mënyra për të zhvilluar disa veçori ose për të rregulluar gabimet nëse nuk keni duar të mjaftueshme. Për shembull, ju mund të punësoni një zhvillues tjetër dhe t'i paguani atij para. Ose mund të merrni një praktikant për një kohë dhe gjithashtu t'i paguani atij një rrogë. Por ka ende një grup mjaft të madh njerëzish, disa prej të cilëve tashmë dinë të shkruajnë kod. Ju thjesht nuk e dini gjithmonë se çfarë cilësie është kodi.
Ne menduam për këtë dhe vendosëm të përpiqemi të tërheqim studentë. Por studentët nuk do të marrin pjesë në gjithçka me ne. Ata do të bëjnë vetëm një pjesë të punës. Dhe ata, për shembull, do të shkruajnë teste, do të rregullojnë gabimet, do të zbatojnë veçori që nuk ndikojnë në funksionalitetin kryesor. Funksionaliteti kryesor është krijimi i kopjeve rezervë dhe rivendosja e kopjeve rezervë. Nëse bëjmë një gabim në krijimin e një kopje rezervë, do të përjetojmë humbje të të dhënave. Dhe askush nuk e dëshiron këtë, natyrisht. Të gjithë duan që gjithçka të jetë shumë e sigurt. Prandaj, sigurisht, ne nuk duam të lejojmë kodin që i besojmë më pak se tonit. Kjo do të thotë, çdo kod jo kritik është ajo që ne do të dëshironim të merrnim nga punëtorët tanë shtesë.
Në çfarë kushtesh pranohet PR studentore?
- Atyre u kërkohet të mbulojnë kodin e tyre me teste. Gjithçka duhet të bëhet në CI.
- Dhe ne gjithashtu kalojmë nëpër 2 rishikime. Një nga Andrey Borodin dhe një nga unë.
- Dhe përveç kësaj, për të kontrolluar që kjo nuk do të prishë asgjë në shërbimin tonë, unë ngarkoj veçmas asamblenë me këtë komitet. Dhe ne kontrollojmë në testet nga fundi në fund se asgjë nuk dështon.
Kurs special mbi kodin e hapur
Pak se pse është e nevojshme kjo dhe pse kjo, më duket, është një ide e lezetshme.
Për ne, fitimi është i dukshëm:
- Ne kemi duar shtesë.
- Dhe ne po kërkojmë kandidatë për ekipin midis studentëve të zgjuar që shkruajnë kodin inteligjent.
Cili është përfitimi për studentët?
Mund të jenë më pak të dukshme, sepse studentët, minimalisht, nuk marrin para për kodin që shkruajnë, por marrin vetëm nota për të dhënat e tyre studentore.
Unë i pyeta ata për këtë. Dhe në fjalët e tyre:
- Përvoja e kontribuesit në Open Source.
- Merrni një linjë në CV-në tuaj.
- Provoni veten dhe kaloni një intervistë në Yandex.
- Bëhuni një anëtar i GSoC.
- +1 kurs special për ata që duan të shkruajnë kod.
Nuk do të flas se si u strukturua kursi. Do të them vetëm se WAL-G ishte projekti kryesor. Ne kemi përfshirë gjithashtu projekte të tilla si Odyssey, PostgreSQL dhe ClickHouse në këtë kurs.
Dhe ata dhanë probleme jo vetëm në këtë kurs, por dhanë edhe diploma dhe lëndë.
Po në lidhje me përfitimet për përdoruesit?
Tani le të kalojmë në pjesën që ju intereson më shumë. Çfarë të mirë ju bën kjo? Çështja është se studentët rregulluan shumë gabime. Dhe ne kemi bërë veçoritë e kërkesës që na kërkuat të bënim.
Dhe më lejoni t'ju tregoj për gjërat që keni dashur prej kohësh dhe që janë realizuar.
Mbështetja e hapësirave të tavolinës. Hapësirat e tabelave në WAL-G priten ndoshta që nga lëshimi i WAL-G, sepse WAL-G është pasardhësi i një mjeti tjetër rezervë WAL-E, ku mbështeteshin kopjet rezervë të bazës së të dhënave me hapësira tavoline.
Më lejoni t'ju kujtoj shkurtimisht se çfarë është dhe pse është e nevojshme. Në mënyrë tipike, të gjitha të dhënat tuaja Postgres zënë një direktori në sistemin e skedarëve, të quajtur bazë. Dhe kjo direktori përmban tashmë të gjithë skedarët dhe nëndrejtoritë e kërkuara nga Postgres.
Hapësirat e tabelave janë drejtori që përmbajnë të dhëna Postgres, por ato nuk janë të vendosura jashtë drejtorisë bazë. Sllajdi tregon se hapësirat e tabelave janë të vendosura jashtë drejtorisë bazë.
Si duket kjo për vetë Postgres? Ekziston një nëndrejtori e veçantë pg_tblspc në drejtorinë bazë. Dhe ai përmban lidhje simbolesh me drejtoritë që në të vërtetë përmbajnë të dhëna Postgres jashtë drejtorisë bazë.
Kur përdorni të gjitha këto, atëherë për ju këto komanda mund të duken diçka si kjo. Kjo do të thotë, ju krijoni një tabelë në një hapësirë të caktuar tavoline dhe shihni se ku është tani. Këto janë dy rreshtat e fundit, dy komandat e fundit të thirrura. Dhe atje është e qartë se ka një mënyrë. Por në realitet, kjo nuk është mënyra e vërtetë. Kjo është rruga e prefiksuar nga drejtoria bazë në hapësirën e tavolinës. Dhe prej andej ajo përputhet me një lidhje simbolike që çon në të dhënat tuaja reale.
Ne nuk i përdorim të gjitha këto në ekipin tonë, por është përdorur nga shumë përdorues të tjerë të WAL-E të cilët na shkruanin se donin të kalonin në WAL-G, por kjo po i ndalonte. Kjo tani mbështetet.
Një veçori tjetër që na solli kursi ynë special është catchup. Njerëzit që ndoshta kanë punuar më shumë me Oracle sesa me Postgres dinë për catchup.
Shkurtimisht për atë që është. Topologjia e grupimit në shërbimin tonë zakonisht mund të duket diçka e tillë. Ne kemi një mjeshtër. Ekziston një kopje që transmeton regjistrin e shkrimit përpara prej saj. Dhe kopja i tregon masterit se në cilin LSN është aktualisht. Dhe diku paralelisht me këtë, regjistri mund të arkivohet. Dhe përveç arkivimit të regjistrit, kopjet rezervë dërgohen gjithashtu në cloud. Dhe dërgohen kopje rezervë delta.
Cili mund të jetë problemi? Kur keni një bazë të dhënash mjaft të madhe, mund të rezultojë se kopja juaj fillon të mbetet shumë prapa masterit. Dhe ajo mbetet aq shumë prapa sa nuk mund ta arrijë kurrë atë. Ky problem zakonisht duhet të zgjidhet disi.
Dhe mënyra më e lehtë është të hiqni kopjen dhe ta ngarkoni përsëri, sepse nuk do të arrijë kurrë, dhe problemi duhet të zgjidhet. Por kjo është një kohë mjaft e gjatë, sepse rivendosja e një kopje rezervë të të dhënave të të dhënave 10 TB është një kohë shumë, shumë e gjatë. Dhe ne duam t'i bëjmë të gjitha këto sa më shpejt që të jetë e mundur nëse shfaqen probleme të tilla. Dhe pikërisht për këtë është catchup.
Catchup ju lejon të përdorni kopje rezervë delta, të cilat ruhen në cloud në këtë mënyrë. Ju thoni se në cilin LSN është aktualisht kopja e vonuar dhe e specifikoni atë në komandën catchup në mënyrë që të krijoni një kopje rezervë delta midis atij LSN dhe LSN-së në të cilën grupi juaj ndodhet aktualisht. Dhe pas kësaj ju e rivendosni këtë kopje rezervë në kopjen që kishte mbetur prapa.
Bazat e tjera
Studentët na sollën edhe shumë veçori njëherësh. Meqenëse në Yandex ne gatuajmë jo vetëm Postgres, kemi gjithashtu MySQL, MongoDB, Redis, ClickHouse, në një moment na duhej të ishim në gjendje të bënim kopje rezervë me rikuperim në kohë për MySQL, dhe kështu të kishte një mundësi për të ngarkuar ato në re.
Dhe ne donim ta bënim atë në një mënyrë të ngjashme me atë që bën WAL-G. Dhe ne vendosëm të eksperimentonim dhe të shohim se si do të dukej gjithçka.
Dhe në fillim, pa e ndarë në asnjë mënyrë këtë logjikë, ata e shkruan kodin në pirun. Ata e panë që ne kemi një lloj modeli pune dhe ai mund të fluturojë. Atëherë menduam se komuniteti ynë kryesor janë postgresistët, ata përdorin WAL-G. Dhe për këtë arsye ne duhet t'i ndajmë disi këto pjesë. Kjo do të thotë, kur ne redaktojmë kodin për Postgres, ne nuk e thyejmë MySQL; kur modifikojmë MySQL, ne nuk e thyejmë Postgres.
Ideja e parë se si të ndahej kjo ishte ideja e përdorimit të së njëjtës qasje që përdoret në shtesat PostgreSQL. Dhe, në fakt, për të bërë një kopje rezervë të MySQL ju duhej të instaloni një lloj biblioteke dinamike.
Por këtu asimetria e kësaj qasjeje është menjëherë e dukshme. Kur bëni kopje rezervë të Postgres, vendosni një kopje rezervë normale për Postgres në të dhe gjithçka është në rregull. Dhe për MySQL rezulton se ju instaloni një kopje rezervë për Postgres dhe gjithashtu instaloni një bibliotekë dinamike për MySQL për të. Tingëllon disi e çuditshme. Kështu menduam edhe ne dhe vendosëm që kjo nuk ishte zgjidhja që na duhej.
Ndërtime të ndryshme për Postgres, MySQL, MongoDB, Redis
Por kjo na lejoi, na duket, të arrijmë në vendimin e duhur - të ndajmë asamble të ndryshme për baza të ndryshme. Kjo bëri të mundur izolimin e logjikës së lidhur me kopjet rezervë të bazave të të dhënave të ndryshme që do të aksesojnë API-në e përbashkët që zbaton WAL-G.
Kjo është pjesa që kemi shkruar vetë - para se t'u japim nxënësve problemet. Domethënë, kjo është pikërisht pjesa ku ata mund të bënin diçka të gabuar, kështu që vendosëm që më mirë të bëjmë diçka të tillë dhe gjithçka do të jetë mirë.
Pas kësaj ne lëshuam probleme. Ata u çmontuan menjëherë. Studentëve iu kërkua të mbështesin tre baza.
Kjo është MySQL, të cilën ne e kemi mbështetur duke përdorur WAL-G në këtë mënyrë për më shumë se një vit.
Dhe tani MongoDB po i afrohet prodhimit, ku ata po e përfundojnë atë me një skedar. Në fakt, ne kemi shkruar kornizën për të gjithë këtë. Më pas nxënësit shkruan disa gjëra të realizueshme. Dhe pastaj i sjellim në një gjendje që mund t'i pranojmë në prodhim.
Këto probleme nuk dukeshin sikur studentët kishin nevojë të shkruanin mjete të plota rezervë për secilën prej këtyre bazave të të dhënave. Ne nuk e kishim një problem të tillë. Problemi ynë ishte se ne donim rikuperim pikë-në-kohë dhe donim të bënim kopje rezervë në cloud. Dhe ata u kërkuan studentëve të shkruanin një kod që do ta zgjidhte këtë. Studentët përdorën mjete rezervë ekzistuese, të cilat në njëfarë mënyre marrin kopje rezervë, dhe më pas i ngjitën të gjitha së bashku me WAL-G, i cili i përcolli të gjitha në cloud. Dhe kësaj ata shtuan gjithashtu rikuperimin në kohë.
Çfarë tjetër sollën studentët? Ata sollën mbështetjen e kriptimit të Libsodiumit në WAL-G.
Ne kemi gjithashtu politika të ruajtjes rezervë. Tani kopjet rezervë mund të shënohen si të përhershme. Dhe disi është më i përshtatshëm për shërbimin tuaj që të automatizojë procesin e ruajtjes së tyre.
Cili ishte rezultati i këtij eksperimenti?
Më shumë se 100 persona u regjistruan fillimisht për kursin. Në fillim nuk thashë që universiteti në Yekaterinburg është Universiteti Federal Ural. Ne njoftuam gjithçka atje. 100 persona janë regjistruar. Në realitet, shumë më pak njerëz filluan të bëjnë diçka, rreth 30 persona.
Edhe më pak njerëz e përfunduan kursin, sepse ishte e nevojshme të shkruante teste për kodet që tashmë ekzistojnë. Dhe gjithashtu rregulloni disa gabime ose krijoni ndonjë veçori. Dhe disa studentë ende e mbyllën kursin.
Aktualisht, gjatë këtij kursi, studentët kanë rregulluar rreth 14 probleme dhe kanë bërë 10 veçori të madhësive të ndryshme. Dhe, më duket, ky është një zëvendësim i plotë i një ose dy zhvilluesve.
Ndër të tjera kemi lëshuar diploma dhe lëndë. Dhe 12 morën diploma. 6 prej tyre tashmë janë mbrojtur në “5”. Ata që mbetën nuk kishin ende mbrojtje, por mendoj se gjithçka do të jetë mirë edhe për ta.
Planet për të ardhmen
Çfarë planesh kemi për të ardhmen?
Të paktën ato kërkesa për veçori që ne kemi dëgjuar tashmë nga përdoruesit dhe duam t'i bëjmë. Kjo:
- Monitorimi i korrektësisë së gjurmimit të afatit kohor në arkivin rezervë të grupit HA. Këtë mund ta bëni me WAL-G. Dhe mendoj se do të kemi studentë që do të merren me këtë çështje.
- Ne tashmë kemi një person përgjegjës për transferimin e kopjeve rezervë dhe WAL midis reve.
- Dhe së fundmi kemi publikuar një ide se mund ta përshpejtojmë WAL-G edhe më shumë duke shpaketuar kopje rezervë shtesë pa rishkruar faqet dhe duke optimizuar arkivat që dërgojmë atje.
Ju mund t'i shpërndani ato këtu
Për çfarë ishte ky raport? Për më tepër, tani përveç 4 personave që e mbështesin këtë projekt, kemi edhe duar shtesë, prej të cilave janë mjaft. Sidomos nëse u shkruani atyre në një mesazh personal. Dhe nëse bëni kopje rezervë të të dhënave tuaja dhe e bëni atë duke përdorur WAL-G ose dëshironi të kaloni në WAL-G, atëherë ne mund t'i akomodojmë lehtësisht dëshirat tuaja.
Ky është një kod QR dhe një lidhje. Ju mund t'i kaloni ato dhe të shkruani të gjitha dëshirat tuaja. Për shembull, ne nuk po rregullojmë ndonjë gabim. Ose vërtet dëshironi një veçori, por për ndonjë arsye nuk është ende në asnjë kopje rezervë, përfshirë tonën. Sigurohuni që të shkruani për këtë.
Pyetjet tuaja
Përshëndetje! Faleminderit për raportin! Pyetje për WAL-G, por jo për Postgres. WAL-G rezervon MySQL dhe thërret një kopje rezervë shtesë. Nëse marrim instalime moderne në CentOS dhe nëse instaloni MySQL, MariDB do të instalohet. Nga versioni 10.3 nuk mbështetet rezervimi shtesë, mbështetet kopja rezervë MariDB. Si ja kaloni me këtë?
Për momentin nuk jemi përpjekur të kopjojmë MariDB. Kemi pasur kërkesa për mbështetje FoundationDB, por në përgjithësi, nëse ka një kërkesë të tillë, atëherë mund të gjejmë njerëz që do ta bëjnë. Nuk është aq e gjatë apo aq e vështirë sa mendoj.
Mirembrema Faleminderit për raportin! Pyetje rreth veçorive të reja të mundshme. A jeni gati të bëni WAL-G të funksionojë me kaseta në mënyrë që të mund të bëni kopje rezervë në kaseta?
Rezervimi në ruajtjen e kasetës me sa duket do të thotë?
Po.
Është Andrei Borodin, i cili mund t'i përgjigjet kësaj pyetjeje më mirë se unë.
(Andrey) Po, faleminderit për pyetjen! Ne kishim një kërkesë për të transferuar një kopje rezervë në kasetë nga ruajtja e resë kompjuterike. Dhe për këtë transferimi midis reve. Sepse transferimi cloud-to-cloud është një version i përgjithësuar i transferimit të shiritit. Përveç kësaj, ne kemi një arkitekturë të zgjerueshme për sa i përket ruajtjes. Nga rruga, shumë Storoge u shkruan nga studentët. Dhe nëse shkruani Storage për kasetë, atëherë sigurisht që do të mbështetet. Ne jemi gati të shqyrtojmë kërkesat për tërheqje. Aty duhet të shkruani një skedar, të lexoni një skedar. Nëse i bëni këto gjëra në Go, zakonisht përfundoni me 50 rreshta kodi. Dhe më pas kaseta do të mbështetet në WAL-G.
Faleminderit për raportin! Procesi interesant i zhvillimit. Rezervimi është një pjesë serioze e funksionalitetit që duhet të mbulohet mirë nga testet. Kur keni zbatuar funksionalitetin për bazat e reja të të dhënave, studentët i kanë shkruar edhe testet, apo i keni shkruar vetë testet dhe më pas ua keni dhënë zbatimin studentëve?
Nxënësit shkruan edhe teste. Por studentët shkruan më shumë për veçori të tilla si bazat e reja të të dhënave. Ata shkruan teste integruese. Dhe ata shkruan teste njësi. Nëse integrimi kalon, domethënë për momentin, ky është një skript që ju e ekzekutoni manualisht ose keni cron që ta bëjë atë, për shembull. Domethënë, skenari atje është shumë i qartë.
Studentët nuk kanë shumë përvojë. A kërkon shumë kohë rishikimi?
Po, rishikimet kërkojnë mjaft kohë. Kjo do të thotë, zakonisht, kur disa kryerës vijnë menjëherë dhe thonë që unë bëra këtë, bëra atë, atëherë duhet të mendoni dhe të lini mënjanë rreth gjysmë dite për të kuptuar se çfarë kanë shkruar atje. Sepse kodi duhet lexuar me kujdes. Ata nuk patën një intervistë. Ne nuk i njohim shumë mirë, kështu që kërkon 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 një lloj fisheku të grumbullimit, na duhet logjikë shtesë për të përcaktuar nyjen nga e cila do të dërgohen boshtet. Si e zgjidhni vetë këtë problem?
Cili është problemi juaj këtu? Le të themi se keni një kopje sinkrone me të cilën po bëni një kopje rezervë? Apo çfarë?
(Andrey) Fakti është se me të vërtetë WAL-G synohet të përdoret pa skripta shell. Nëse diçka mungon, atëherë le të shtojmë logjikën që duhet të jetë brenda WAL-G. Sa i përket asaj se nga duhet të vijë arkivimi, ne besojmë se arkivimi duhet të jetë nga masteri aktual në grup. Arkivimi nga një kopje është një ide e keqe. Ka skenarë të ndryshëm të mundshëm me probleme. Në veçanti, probleme me arkivimin e afateve kohore dhe çdo informacion shtesë. Faleminderit për pyetjen!
(Sqarim: Kemi hequr qafe skriptet e guaskës )
Mirembrema! Faleminderit për raportin! Më intereson veçoria catchup për të cilën folët. Ne u përballëm me një situatë ku një kopje ishte prapa dhe nuk arrinte dot. Dhe nuk gjeta një përshkrim të kësaj veçorie në dokumentet WAL-G.
Catchup u shfaq fjalë për fjalë në 20 janar 2020. Dokumentacioni mund të ketë nevojë për më shumë punë. E shkruajmë vetë dhe nuk e shkruajmë shumë mirë. Dhe ndoshta duhet të fillojmë t'u kërkojmë studentëve ta shkruajnë atë.
A është lëshuar tashmë?
Kërkesa për tërheqje është tashmë e vdekur, domethënë e kontrollova. E provova këtë në një grup testimi. Deri më tani nuk kemi pasur një situatë ku mund ta testonim këtë në një shembull luftarak.
Kur të presim?
Une nuk e di. Prisni një muaj, do ta kontrollojmë me siguri.
Burimi: www.habr.com