Azt javaslom, hogy olvassa el Georgy Rylov 2020 eleji jelentésének átiratát „WAL-G: új lehetőségek és a közösség terjeszkedése”
A nyílt forráskódú karbantartók növekedésük során számos kihívással néznek szembe. Hogyan írhatunk meg egyre több és több szükséges funkciót, hogyan javíthatunk ki egyre több problémát, és hogyan lehet egyre több lehívási kérést megtekinteni? A WAL-G (PostgreSQL biztonsági mentési eszköze) példaként elmondom, hogyan oldottuk meg ezeket a problémákat azzal, hogy nyílt forráskódú fejlesztésről indítottunk kurzust az egyetemen, mit értünk el, és merre haladunk tovább.
Üdv újra mindenkinek! Yandex fejlesztő vagyok Jekatyerinburgból. És ma a WAL-G-ről fogok beszélni.
A jelentés címében nem szerepel, hogy a biztonsági mentésekről szólna. Tudja valaki, hogy mi az a WAL-G? Vagy mindenki tudja? Emelje fel a kezét, ha nem tudja. Szent ég, eljöttél a jelentéshez, és nem tudod, miről szól.
Hadd mondjam el, mi fog történni ma. Megesik, hogy csapatunk már jó ideje biztonsági mentéseket készít. És ez egy újabb riport egy sorozatból, ahol arról beszélünk, hogyan tároljuk az adatokat biztonságosan, biztonságosan, kényelmesen és hatékonyan.
Az előző sorozatokban Andrej Borodin és Vlagyimir Leszkov számos riportot közölt. Sokan voltunk. És sok éve beszélünk a WAL-G-ről.
clck.ru/F8ioz —
clck.ru/Ln8Qw —
Ez a jelentés egy kicsit különbözni fog a többitől abban, hogy inkább a technikai részről szólt, de itt arról fogok beszélni, hogyan találkoztunk a közösség növekedésével kapcsolatos problémákkal. És hogyan jutottunk egy kis ötlethez, ami segít megbirkózni ezzel.
Néhány évvel ezelőtt a WAL-G egy meglehetősen kicsi projekt volt, amelyet a Citus Data-tól kaptunk. És csak elvittük. És egy személy fejlesztette ki.
És csak a WAL-G nem rendelkezett:
- Biztonsági mentés egy replikából.
- Nem voltak növekményes biztonsági mentések.
- Nem voltak WAL-Delta biztonsági mentések.
- És még sok minden hiányzott.
Ez alatt a néhány év alatt a WAL-G sokat fejlődött.
2020-ra pedig már a fentiek mindegyike megjelent. És ehhez jött még, ami most van:
- Több mint 1 csillag a GitHubon.
- 150 villa.
- Körülbelül 15 nyitott PR.
- És még sok más közreműködő.
- És folyamatosan nyitott kérdések. És ez annak ellenére, hogy szó szerint minden nap odamegyünk és teszünk is ellene.
Arra a következtetésre jutottunk, hogy ez a projekt több figyelmet igényel, még akkor is, ha nekünk magunknak semmit sem kell megvalósítanunk a Yandexben lévő Managed Databases szolgáltatásunkhoz.
És valahol 2018 őszén eszünkbe jutott egy ötlet. Általában a csapatnak többféle módja van bizonyos funkciók fejlesztésére vagy hibák kijavítására, ha nincs elég keze. Például bérelhetsz egy másik fejlesztőt, és fizethetsz neki pénzt. Vagy vállalhatsz egy gyakornokot egy időre, és fizethetsz neki némi fizetést. De még mindig elég nagy embercsoport van, akik közül néhányan már tényleg tudják, hogyan kell kódot írni. Csak nem mindig tudja, milyen minőségű a kód.
Gondolkodtunk ezen, és úgy döntöttünk, hogy megpróbáljuk vonzani a diákokat. De a diákok nem fognak mindenben részt venni velünk. Csak a munka egy részét fogják elvégezni. És például teszteket írnak, hibákat javítanak, olyan funkciókat valósítanak meg, amelyek nem befolyásolják a fő funkcionalitást. A fő funkció a biztonsági mentések készítése és a biztonsági másolatok visszaállítása. Ha hibát követünk el a biztonsági mentés elkészítésekor, adatvesztést tapasztalunk. És ezt persze senki sem akarja. Mindenki azt akarja, hogy minden nagyon biztonságos legyen. Ezért természetesen nem akarjuk megengedni azt a kódot, amelyben kevésbé bízunk, mint a sajátunkban. Vagyis minden nem kritikus kódot szeretnénk megkapni további dolgozóinktól.
Milyen feltételek mellett fogadják el a hallgatói PR-t?
- Kódjukat tesztekkel kell lefedniük. Mindennek a CI-ben kell történnie.
- És végigmegyünk 2 értékelésen is. Egy Andrej Borodintól, egy pedig tőlem.
- Ezenkívül, annak ellenőrzésére, hogy ez nem ront-e el semmit a szolgáltatásunkban, külön feltöltöm az összeállítást ezzel a véglegesítéssel. Végponttól végpontig teszteljük, hogy semmi sem sikerül.
Speciális tanfolyam a nyílt forráskódról
Kicsit arról, hogy miért van erre szükség, és miért ez, szerintem, jó ötlet.
Számunkra a profit nyilvánvaló:
- Plusz kezet kapunk.
- A csapatba pedig okos kódot író okos diákok közé keresünk jelentkezőket.
Mi az előnye a hallgatóknak?
Lehet, hogy kevésbé nyilvánvalóak, mert a diákok legalább nem kapnak pénzt az általuk írt kódért, hanem csak osztályzatot kapnak a tanulói nyilvántartásukért.
Erről kérdeztem őket. És az ő szavaikkal:
- Közreműködői tapasztalat nyílt forráskóddal.
- Írjon egy sort az önéletrajzába.
- Bizonyítsd magad, és adj egy interjút a Yandexen.
- Legyél GSoC tag.
- +1 speciális tanfolyam azoknak, akik szeretnének kódot írni.
A tanfolyam felépítéséről nem beszélek. Csak annyit mondok, hogy a WAL-G volt a fő projekt. Olyan projekteket is bevontunk a tanfolyamba, mint az Odyssey, a PostgreSQL és a ClickHouse.
És nem csak ezen a tanfolyamon adtak problémákat, hanem okleveleket és tanfolyami munkákat is adtak.
Mi a helyzet a felhasználók előnyeivel?
Most pedig térjünk át arra a részre, amelyik leginkább érdekli. Mire jó ez neked? A lényeg az, hogy a diákok sok hibát javítottak. És a kéréseket olyan funkciókkal láttuk el, amelyeket Ön kért tőlünk.
És hadd meséljek azokról a dolgokról, amelyekre régóta vágytál, és amelyek megvalósultak.
Asztalterek támogatása. A WAL-G táblaterületei valószínűleg a WAL-G megjelenése óta várhatók, mivel a WAL-G egy másik WAL-E biztonsági mentési eszköz utódja, ahol támogatták a táblaterületekkel rendelkező adatbázis-mentéseket.
Hadd emlékeztesselek röviden, mi ez, és miért van rá szükség. Általában az összes Postgres-adat egy könyvtárat foglal el a fájlrendszerben, amelyet alapnak nevezünk. Ez a könyvtár pedig már tartalmazza a Postgres által igényelt összes fájlt és alkönyvtárat.
A táblaterületek olyan könyvtárak, amelyek Postgres adatokat tartalmaznak, de nem az alapkönyvtáron kívül találhatók. A dián látható, hogy a táblaterületek az alapkönyvtáron kívül találhatók.
Hogy néz ki ez magának a Postgres-nek? Az alapkönyvtárban van egy külön pg_tblspc alkönyvtár. Ezenkívül szimbolikus hivatkozásokat tartalmaz olyan könyvtárakra, amelyek ténylegesen tartalmazzák az alapkönyvtáron kívüli Postgres adatokat.
Ha mindezt használja, akkor az Ön számára ezek a parancsok valahogy így nézhetnek ki. Vagyis létrehoz egy táblát egy meghatározott táblaterületen, és megnézi, hol van most. Ez az utolsó két sor, az utolsó két parancs meghívása. És ott világos, hogy van valami mód. De a valóságban ez nem az igazi út. Ez az előtagozott elérési út az alapkönyvtártól a táblaterületig. Innen pedig egy szimbolikus linkkel párosul, amely a valódi adataihoz vezet.
A csapatunkban mindezt nem használjuk, de sok más WAL-E felhasználó használta, akik azt írták nekünk, hogy szeretnének áttérni a WAL-G-re, de ez megállította őket. Ez most támogatott.
Egy másik funkció, amelyet speciális tanfolyamunk hozott nekünk, a felzárkózás. Azok, akik valószínűleg többet dolgoztak az Oracle-lel, mint a Postgres-szel, ismerik a felzárkózást.
Röviden arról, hogy mi az. A szolgáltatásunkban található fürt topológia általában így néz ki. Van egy mesterünk. Van egy replika, amely az előre írási naplót továbbítja belőle. És a replika közli a mesterrel, hogy éppen melyik LSN-en van. És valahol ezzel párhuzamosan a napló archiválható. És a napló archiválása mellett a biztonsági mentések is elküldésre kerülnek a felhőbe. És elküldik a delta biztonsági mentéseket.
Mi lehet a probléma? Ha meglehetősen nagy adatbázissal rendelkezik, akkor kiderülhet, hogy a replika kezd messze lemaradni a mester mögött. És annyira le van maradva, hogy soha nem tudja utolérni őt. Ezt a problémát általában valahogy meg kell oldani.
A legegyszerűbb pedig az, ha eltávolítod a replikát és újra feltöltöd, mert soha nem fogja utolérni, és a problémát kezelni kell. De ez elég hosszú idő, mert egy teljes 10 TB-os adatbázis-mentés visszaállítása nagyon-nagyon hosszú idő. És mindezt a lehető leggyorsabban meg akarjuk tenni, ha ilyen problémák merülnek fel. És a felzárkózás pontosan erre való.
A Catchup lehetővé teszi a delta biztonsági mentések használatát, amelyek ilyen módon a felhőben tárolódnak. Meg kell mondania, hogy a késleltetett replika jelenleg melyik LSN-en van, és megadja azt a catchup parancsban, hogy delta biztonsági másolatot hozzon létre az LSN és az LSN között, amelyen a fürt jelenleg található. Ezután visszaállítja ezt a biztonsági másolatot a lemaradt replikára.
Egyéb alapok
A diákok is rengeteg funkciót hoztak nekünk egyszerre. Mivel a Yandexnél nem csak a Postgres-t főzzük, hanem van MySQL, MongoDB, Redis, ClickHouse is, valamikor tudnunk kellett biztonsági mentéseket készíteni a MySQL-hez pont-időben történő helyreállítással, és hogy lehetőség legyen feltölteni. őket a felhőbe.
És valami hasonló módon akartuk csinálni, mint amit a WAL-G csinál. És úgy döntöttünk, hogy kísérletezünk, és megnézzük, hogyan fog kinézni az egész.
És eleinte anélkül, hogy ezt a logikát bármi módon megosztották volna, beírták a kódot a villába. Látták, hogy van valami működő modellünk, és tud repülni. Aztán arra gondoltunk, hogy a fő közösségünk a posztgresisták, ők a WAL-G-t használják. Ezért ezeket a részeket valahogy el kell különítenünk. Ez azt jelenti, hogy amikor a Postgres kódját szerkesztjük, nem törjük meg a MySQL-t; amikor szerkesztjük a MySQL-t, akkor nem bontjuk meg a Postgres-t.
Az első ötlet a szétválasztásról az volt, hogy ugyanazt a megközelítést használjuk, mint a PostgreSQL-bővítményekben. Valójában a MySQL biztonsági másolat készítéséhez telepítenie kellett valamiféle dinamikus könyvtárat.
De itt azonnal látható ennek a megközelítésnek az aszimmetriája. Amikor biztonsági másolatot készít a Postgresről, tesz rá egy normál biztonsági másolatot a Postgresről, és minden rendben van. És a MySQL esetében kiderül, hogy telepít egy biztonsági másolatot a Postgreshez, és telepít egy dinamikus könyvtárat a MySQL-hez. Kicsit furcsán hangzik. Mi is így gondoltuk, és úgy döntöttünk, hogy nem erre van szükségünk.
Különféle buildek a Postgres, MySQL, MongoDB, Redis számára
De ez lehetővé tette számunkra, hogy – úgy tűnik – a helyes döntést hozzuk – hogy különböző szerelvényeket rendeljünk a különböző bázisokhoz. Ez lehetővé tette a különféle adatbázisok biztonsági mentéseihez kötött logika elkülönítését, amelyek hozzáférnek a WAL-G által megvalósított közös API-hoz.
Ez az a rész, amit mi magunk írtunk – mielőtt a diákoknak adnánk a problémákat. Vagyis pontosan ez az a rész, ahol valamit rosszul csinálhatnak, ezért úgy döntöttünk, hogy inkább csinálunk valami ilyesmit, és minden rendben lesz.
Ezt követően kiadtuk a problémákat. Azonnal leszerelték. A diákoknak három bázist kellett támogatniuk.
Ez a MySQL, amelyről már több mint egy éve készítünk biztonsági mentést WAL-G használatával ilyen módon.
És most a MongoDB közeledik a gyártáshoz, ahol egy fájllal fejezik be. Valójában mi írtuk meg mindehhez a keretet. Ezután a diákok írtak néhány működőképes dolgot. Utána pedig olyan állapotba hozzuk őket, hogy el tudjuk fogadni a gyártásban.
Ezek a problémák nem úgy tűntek, mintha a diákoknak teljes biztonsági mentési eszközöket kellett volna írniuk ezekhez az adatbázisokhoz. Nálunk nem volt ilyen gond. A problémánk az volt, hogy pontos helyreállítást akartunk, és a felhőbe akartunk biztonsági másolatot készíteni. És megkérték a diákokat, hogy írjanak valami kódot, ami ezt megoldja. A diákok a már meglévő biztonsági mentési eszközöket használták, amelyek valahogyan biztonsági másolatot készítenek, majd az egészet összeragasztották a WAL-G-vel, ami az egészet továbbította a felhőbe. És ehhez hozzáadták a pont-időben történő helyreállítást is.
Mit hoztak még a diákok? Elhozták a Libsodium titkosítási támogatást a WAL-G-hez.
Vannak biztonsági mentési tárolási szabályzataink is. Mostantól a biztonsági másolatok véglegesnek jelölhetők. És valahogy kényelmesebb a szolgáltatás számára, ha automatizálja a tárolás folyamatát.
Mi volt ennek a kísérletnek az eredménye?
Kezdetben több mint 100-an regisztráltak a tanfolyamra. Először nem mondtam, hogy a jekatyerinburgi egyetem az Uráli Szövetségi Egyetem. Ott mindent bejelentettünk. 100 fő regisztrált. Valójában sokkal kevesebben kezdtek el valamit, körülbelül 30 ember.
Még kevesebben végezték el a tanfolyamot, mert a már meglévő kódokhoz teszteket kellett írni. És javítson néhány hibát, vagy készítsen funkciót. És néhány diák még mindig bezárta a tanfolyamot.
Jelenleg a kurzus során a hallgatók körülbelül 14 problémát javítottak, és 10 különböző méretű funkciót készítettek el. És számomra úgy tűnik, hogy ez egy vagy két fejlesztő teljes értékű helyettesítése.
Többek között okleveleket és tanfolyami munkákat adtunk ki. És 12-en kaptak oklevelet. Közülük 6-an már „5”-nél védekeztek. Akik maradtak, még nem volt védettségük, de szerintem nekik is minden rendben lesz.
Tervek a jövőre
Milyen terveink vannak a jövőre nézve?
Legalábbis azok a funkcióigények, amelyeket már hallottunk a felhasználóktól, és meg akarunk tenni. Ez:
- Az idővonal-követés helyességének figyelése a HA-fürt biztonsági mentési archívumában. Ezt megteheti a WAL-G-vel. És azt hiszem, lesznek tanítványaink, akik felveszik ezt az ügyet.
- Már van egy személyünk, aki felelős a biztonsági mentések és a WAL átviteléért a felhők között.
- Nemrég pedig közzétettünk egy ötletet, miszerint a növekményes biztonsági mentések oldalak átírása nélkül történő kicsomagolásával és az odaküldött archívumok optimalizálásával még tovább gyorsíthatjuk a WAL-G-t.
Itt megoszthatod őket
Mire szolgált ez a jelentés? Ráadásul most a projektet támogató 4 emberen kívül további kezeink is vannak, amelyekből elég sok van. Főleg ha személyes üzenetben írsz nekik. Ha pedig biztonsági másolatot készít az adatairól, és ezt a WAL-G használatával teszi, vagy szeretne áttérni a WAL-G-re, akkor könnyedén teljesíteni tudjuk kívánságait.
Ez egy QR kód és egy link. Végignézheti őket, és leírhatja minden kívánságát. Például nem javítunk ki néhány hibát. Vagy nagyon szeretne valamilyen funkciót, de valamiért még nincs biztonsági másolatban, beleértve a miénket sem. Erről mindenképpen írj.
kérdések
Helló! Köszönöm a beszámolót! Kérdés a WAL-G-ről, de nem a Postgres-ről. A WAL-G biztonsági másolatot készít a MySQL-ről, és meghív egy extra biztonsági másolatot. Ha modern telepítéseket vesszük CentOS-en, és ha yum-t telepítünk a MySQL-re, akkor a MariDB települ. A 10.3-as verziótól az extra biztonsági mentés nem támogatott, a MariDB biztonsági mentés támogatott. Hogy állsz ezzel?
Jelenleg nem próbáltuk meg biztonsági másolatot készíteni a MariDB-ről. Volt már kérésünk FoundationDB támogatásra, de általánosságban elmondható, hogy ha van ilyen igény, akkor találunk olyan embereket, akik megteszik. Nem olyan hosszú és nem olyan nehéz, mint gondolom.
Jó napot Köszönöm a beszámolót! Kérdés a lehetséges új funkciókkal kapcsolatban. Készen áll arra, hogy a WAL-G szalagokkal működjön, hogy szalagokra készíthessen biztonsági másolatot?
A biztonsági mentés a szalagos tárolóról láthatóan azt jelenti?
Igen.
Van Andrej Borodin, aki jobban tud válaszolni erre a kérdésre, mint én.
(Andrey) Igen, köszönöm a kérdést! Kérésünk volt, hogy egy biztonsági másolatot vigyünk át szalagra a felhőtárhelyről. És erre átvitel a felhők között. Mivel a felhőből felhőbe átvitel a szalagos átvitel általánosított változata. Emellett a Tárolás terén is bővíthető architektúrával rendelkezünk. Mellesleg sok Storogot diákok írtak. És ha azt írod, hogy Storage for szalag, akkor természetesen támogatva lesz. Készek vagyunk figyelembe venni a lehívási kérelmeket. Ott fájlt kell írni, fájlt olvasni. Ha ezeket a dolgokat a Go-ban csinálja, általában 50 sornyi kódot kap. Ezután a szalagot a WAL-G támogatja.
Köszönöm a beszámolót! Érdekes fejlesztési folyamat. A biztonsági mentés egy komoly funkció, amelyet alaposan tesztelni kell. Amikor új adatbázisokhoz valósított meg funkcionalitást, akkor a diákok is írták a teszteket, vagy te magad írtad a teszteket, majd átadtad a megvalósítást a diákoknak?
A diákok teszteket is írtak. A diákok azonban többet írtak olyan szolgáltatásokról, mint például az új adatbázisok. Integrációs teszteket írtak. És egységteszteket írtak. Ha az integráció sikeres, vagyis pillanatnyilag, akkor ez egy olyan szkript, amelyet kézzel hajtasz végre, vagy például a cron csinálja. Vagyis ott nagyon világos a forgatókönyv.
A diákoknak nincs sok tapasztalatuk. Sok időt vesz igénybe az áttekintés?
Igen, a felülvizsgálatok sok időt vesznek igénybe. Vagyis általában amikor több committer jön egyszerre és azt mondja, hogy ezt csináltam, azt csináltam, akkor gondolkodni kell és fél napot szánni arra, hogy rájöjjön, mit írtak oda. Mert a kódot figyelmesen el kell olvasni. Nem volt interjújuk. Nem nagyon ismerjük őket, ezért ez jelentős időt vesz igénybe.
Köszönöm a beszámolót! Korábban Andrej Borodin kijelentette, hogy a WAL-G-ben az archive_command parancsot közvetlenül kell meghívni. De valamilyen klaszter kazetta esetén további logikára van szükségünk ahhoz, hogy meghatározzuk azt a csomópontot, ahonnan küldjük a tengelyeket. Hogyan oldja meg ezt a problémát saját maga?
mi itt a problémád? Tegyük fel, hogy van egy szinkron replikája, amellyel biztonsági mentést készít? Vagy mi?
(Andrey) A tény az, hogy a WAL-G-t shell szkriptek nélkül szánják. Ha valami hiányzik, akkor adjuk hozzá azt a logikát, aminek a WAL-G-n belül kell lennie. Ami az archiválást illeti, úgy gondoljuk, hogy az archiválásnak a fürt jelenlegi mesterétől kell történnie. A replika archiválása rossz ötlet. Különféle lehetséges forgatókönyvek lehetségesek a problémákkal. Különösen az idővonalak archiválásával és minden további információval kapcsolatos problémák. Köszönöm a kérdést!
(Tisztázás: Megszabadultunk a shell szkriptektől )
Jó estét! Köszönöm a beszámolót! Érdekel a felzárkózási funkció, amiről beszéltél. Olyan helyzettel szembesültünk, amikor egy replika mögött volt, és nem tudta utolérni. Ennek a funkciónak a leírását nem találtam a WAL-G dokumentumokban.
A Catchup szó szerint 20. január 2020-án jelent meg. A dokumentáció további munkát igényelhet. Mi magunk írjuk, és nem írjuk túl jól. És talán el kellene kezdenünk megkövetelni a diákoktól, hogy írják meg.
Kiadták már?
A lehúzási kérés már halott, vagyis megnéztem. Kipróbáltam ezt egy tesztklaszteren. Eddig nem volt olyan helyzetünk, hogy ezt egy harci példában tesztelhettük volna.
Mikorra várható?
Nem tudom. Várj egy hónapot, biztosan megnézzük.
Forrás: will.com