Ik stel voor dat u het transcript leest van het rapport uit begin 2020 van Georgy Rylov “WAL-G: nieuwe kansen en uitbreiding van de gemeenschap”
Open-source-onderhouders worden geconfronteerd met veel uitdagingen naarmate ze groeien. Hoe schrijf je steeds meer vereiste functies, hoe kun je steeds meer problemen oplossen en hoe kun je steeds meer pull-aanvragen bekijken? Met WAL-G (back-uptool voor PostgreSQL) als voorbeeld, zal ik je vertellen hoe we deze problemen hebben opgelost door een cursus over open-sourceontwikkeling aan de universiteit te lanceren, wat we hebben bereikt en waar we naartoe gaan.
Hallo nogmaals allemaal! Ik ben een Yandex-ontwikkelaar uit Jekaterinenburg. En vandaag zal ik het hebben over WAL-G.
In de titel van het rapport stond niet dat het iets over backups ging. Weet iemand wat WAL-G is? Of weet iedereen het? Steek uw hand op als u het niet weet. Holy shit, je kwam naar het rapport en weet niet waar het over gaat.
Ik zal je vertellen wat er vandaag gaat gebeuren. Toevallig is ons team al geruime tijd bezig met het maken van back-ups. En dit is weer een rapport in een serie waarin we praten over hoe we gegevens veilig, gemakkelijk en efficiënt opslaan.
In eerdere series waren er veel reportages van Andrei Borodin en Vladimir Leskov. Er waren velen van ons. En we praten al jaren over WAL-G.
clck.ru/F8ioz —
clck.ru/Ln8Qw —
Dit rapport zal een beetje anders zijn dan de andere omdat het meer over het technische gedeelte ging, maar hier zal ik het hebben over hoe we problemen tegenkwamen die verband hielden met de groei van de gemeenschap. En hoe we op een klein idee kwamen dat ons helpt hiermee om te gaan.
Een paar jaar geleden was WAL-G een vrij klein project dat we van Citus Data kregen. En we hebben het gewoon meegenomen. En het is ontwikkeld door één persoon.
En alleen WAL-G had niet:
- Back-up van een replica.
- Er waren geen incrementele back-ups.
- Er waren geen WAL-Delta-back-ups.
- En er ontbrak nog heel wat.
In deze paar jaar is WAL-G enorm gegroeid.
En tegen 2020 is al het bovenstaande al verschenen. En hieraan werd toegevoegd wat we nu hebben:
- Meer dan 1 sterren op GitHub.
- 150 vorken.
- Ongeveer 15 openstaande PR's.
- En nog veel meer bijdragers.
- En voortdurend openstaande kwesties. En dit ondanks het feit dat we er letterlijk elke dag naartoe gaan en er iets aan doen.
En we kwamen tot de conclusie dat dit project meer van onze aandacht vereist, ook al hoeven we zelf niets te implementeren voor onze Managed Databases-service in Yandex.
En ergens in de herfst van 2018 kwam er een idee bij ons op. Meestal heeft het team verschillende manieren om bepaalde functies te ontwikkelen of bugs op te lossen als je niet genoeg handen hebt. U kunt bijvoorbeeld een andere ontwikkelaar inhuren en hem geld betalen. Of je neemt een tijdje een stagiair aan en betaalt hem ook wat salaris. Maar er is nog steeds een behoorlijk grote groep mensen, waarvan sommigen al echt weten hoe ze code moeten schrijven. Je weet gewoon niet altijd wat de kwaliteit van de code is.
We hebben erover nagedacht en besloten om te proberen studenten aan te trekken. Maar studenten zullen bij ons niet aan alles meedoen. Zij zullen slechts een deel van het werk doen. En ze zullen bijvoorbeeld tests schrijven, bugs oplossen, functies implementeren die geen invloed hebben op de hoofdfunctionaliteit. De belangrijkste functionaliteit is het maken van back-ups en het terugzetten van back-ups. Als we een fout maken bij het maken van een back-up, zullen we gegevensverlies ervaren. En dit wil niemand natuurlijk. Iedereen wil dat alles zeer veilig is. Daarom willen we natuurlijk geen code toestaan die we minder vertrouwen dan de onze. Dat wil zeggen: elke niet-kritieke code is wat we graag van onze extra medewerkers willen ontvangen.
Onder welke voorwaarden wordt studenten-PR geaccepteerd?
- Ze zijn verplicht om hun code te bedekken met tests. Alles zou in CI moeten plaatsvinden.
- En we nemen ook nog eens 2 beoordelingen door. Eén van Andrey Borodin en één van mij.
- En bovendien, om te controleren of dit niets in onze service kapot maakt, upload ik de assembly afzonderlijk met deze commit. En we controleren bij end-to-end-tests of er niets mislukt.
Speciale cursus Open Source
Een beetje over waarom dit nodig is en waarom dit, naar mijn mening, een cool idee is.
Voor ons is de winst duidelijk:
- Wij krijgen extra handen.
- En voor het team zoeken wij kandidaten onder de slimme studenten die slimme code schrijven.
Wat is het voordeel voor studenten?
Ze zijn misschien minder voor de hand liggend, omdat studenten in ieder geval geen geld krijgen voor de code die ze schrijven, maar alleen cijfers voor hun studiegegevens.
Ik heb hen hierover gevraagd. En in hun woorden:
- Ervaring van een bijdrager met Open Source.
- Zorg voor een lijn in je CV.
- Bewijs jezelf en slaag voor een interview in Yandex.
- Word GSoC-lid.
- +1 speciale cursus voor degenen die code willen schrijven.
Ik zal niet praten over hoe de cursus was opgebouwd. Ik zeg alleen dat WAL-G het hoofdproject was. Ook projecten als Odyssey, PostgreSQL en ClickHouse hebben we in deze cursus meegenomen.
En ze gaven niet alleen problemen in deze cursus, maar deelden ook diploma's en cursussen uit.
Hoe zit het met het voordeel voor gebruikers?
Laten we nu verder gaan met het deel dat u het meest interesseert. Wat heb je hieraan? Het punt is dat de studenten veel bugs hebben opgelost. En we hebben de verzoekfuncties gemaakt die u ons vroeg.
En laat me je vertellen over de dingen die je al lang wilt en die zijn gerealiseerd.
Ondersteuning voor tabelruimten. Tabelruimten in WAL-G werden waarschijnlijk verwacht sinds de release van WAL-G, omdat WAL-G de opvolger is van een andere back-uptool WAL-E, waarbij databaseback-ups met tabelruimten werden ondersteund.
Ik wil u er kort aan herinneren wat het is en waarom het allemaal nodig is. Normaal gesproken bezetten al uw Postgres-gegevens één map in het bestandssysteem, de zogenaamde base. En deze map bevat al alle bestanden en submappen die Postgres nodig heeft.
Tabelruimten zijn mappen die Postgres-gegevens bevatten, maar bevinden zich niet buiten de basismap. De dia laat zien dat de tablepacs zich buiten de basismap bevinden.
Hoe ziet dit eruit voor Postgres zelf? Er is een aparte submap pg_tblspc in de basismap. En het bevat symlinks naar mappen die daadwerkelijk Postgres-gegevens bevatten buiten de basismap.
Wanneer u dit allemaal gebruikt, kunnen deze opdrachten er voor u ongeveer zo uitzien. Dat wil zeggen, u maakt een tabel in een bepaalde tabelruimte en kijkt waar deze zich nu bevindt. Dit zijn de laatste twee regels, de laatste twee opgeroepen commando's. En daar is het duidelijk dat er een manier is. Maar in werkelijkheid is dit niet de echte manier. Dit is het vooraf ingestelde pad van de basismap naar de tabelruimte. En van daaruit wordt het gekoppeld aan een symbolische link die naar uw echte gegevens leidt.
We gebruiken dit allemaal niet in ons team, maar het werd gebruikt door veel andere WAL-E-gebruikers die ons schreven dat ze naar WAL-G wilden overstappen, maar dit hield hen tegen. Dit wordt nu ondersteund.
Een ander kenmerk dat onze speciale cursus ons heeft gebracht, is inhalen. Mensen die waarschijnlijk meer met Oracle hebben gewerkt dan met Postgres, weten wat catchup is.
In het kort wat het is. De clustertopologie in onze service kan er meestal ongeveer zo uitzien. We hebben een meester. Er is een replica die vooruitgeschreven logbestanden ervan streamt. En de replica vertelt de master op welke LSN hij zich momenteel bevindt. En ergens parallel hiermee kan het logboek worden gearchiveerd. En naast het archiveren van de log worden er ook back-ups naar de cloud gestuurd. En er worden deltaback-ups verzonden.
Wat kan het probleem zijn? Als u een vrij grote database heeft, kan het blijken dat uw replica ver achterloopt op de master. En ze loopt zo ver achter dat ze hem nooit meer kan inhalen. Dit probleem moet meestal op de een of andere manier worden opgelost.
En de eenvoudigste manier is om de replica te verwijderen en opnieuw te uploaden, omdat deze de achterstand nooit zal inhalen en het probleem moet worden opgelost. Maar dit is behoorlijk lang, omdat het herstellen van een volledige databaseback-up van 10 TB heel erg lang duurt. En we willen dit allemaal zo snel mogelijk doen als dergelijke problemen zich voordoen. En dat is precies waar inhaalslag voor bedoeld is.
Met Catchup kunt u gebruik maken van deltaback-ups, die op deze manier in de cloud worden opgeslagen. U geeft aan op welke LSN de achterblijvende replica zich momenteel bevindt en specificeert deze in de catchup-opdracht om een deltaback-up te maken tussen die LSN en de LSN waarop uw cluster zich momenteel bevindt. En daarna herstel je deze backup naar de replica die achterbleef.
Andere bases
De studenten brachten ons ook veel functies tegelijk. Omdat we bij Yandex niet alleen Postgres koken, we hebben ook MySQL, MongoDB, Redis, ClickHouse, op een gegeven moment moesten we back-ups kunnen maken met point-in-time herstel voor MySQL, en zodat er een mogelijkheid was om te uploaden ze naar de wolk.
En we wilden het op een vergelijkbare manier doen als WAL-G. En we besloten om te experimenteren en te kijken hoe het er allemaal uit zou zien.
En in eerste instantie, zonder deze logica op enigerlei wijze te delen, schreven ze de code in de fork. Ze zagen dat we een soort werkmodel hebben en dat het kan vliegen. Toen dachten we dat onze belangrijkste gemeenschap uit postgresisten bestaat, zij gebruiken WAL-G. En daarom moeten we deze delen op de een of andere manier scheiden. Dat wil zeggen: als we code voor Postgres bewerken, breken we MySQL niet; als we MySQL bewerken, breken we Postgres niet.
Het eerste idee om dit te scheiden was het idee om dezelfde aanpak te gebruiken die wordt gebruikt in PostgreSQL-extensies. En om een MySQL-back-up te maken, moest je in feite een soort dynamische bibliotheek installeren.
Maar hier is de asymmetrie van deze benadering onmiddellijk zichtbaar. Wanneer u een back-up van Postgres maakt, plaatst u er een normale back-up voor Postgres op en alles is in orde. En voor MySQL blijkt dat je een backup voor Postgres installeert en daarvoor ook een dynamische bibliotheek voor MySQL installeert. Het klinkt nogal vreemd. Dat vonden wij ook en besloten dat dit niet de oplossing was die we nodig hadden.
Verschillende builds voor Postgres, MySQL, MongoDB, Redis
Maar dit stelde ons in staat, zo lijkt het, om tot de juiste beslissing te komen: om verschillende vergaderingen voor verschillende bases toe te wijzen. Dit maakte het mogelijk om de logica te isoleren die is gekoppeld aan back-ups van verschillende databases die toegang krijgen tot de gemeenschappelijke API die WAL-G implementeert.
Dit is het deel dat we zelf hebben geschreven voordat we de leerlingen de problemen gaven. Dat wil zeggen, dit is precies het deel waar ze iets verkeerd konden doen, dus besloten we dat we zoiets beters konden doen en dat alles goed zou komen.
Daarna gaven we problemen uit. Ze werden onmiddellijk gedemonteerd. Studenten moesten drie bases ondersteunen.
Dit is MySQL, waarvan we al ruim een jaar op deze manier een back-up maken met WAL-G.
En nu nadert MongoDB de productie, waar ze het afmaken met een bestand. In feite hebben wij het raamwerk voor dit alles geschreven. Vervolgens schreven de leerlingen een aantal werkbare dingen. En dan brengen we ze naar een staat die we in de productie kunnen accepteren.
Deze problemen leken er niet op dat studenten voor elk van deze databases volledige back-uptools moesten schrijven. Wij hadden niet zo'n probleem. Ons probleem was dat we herstel op een bepaald tijdstip wilden en dat we een back-up naar de cloud wilden maken. En ze vroegen de studenten om code te schrijven die dit zou oplossen. De studenten gebruikten reeds bestaande back-uptools, die op de een of andere manier back-ups maken, en plakten alles vervolgens aan elkaar met WAL-G, die het allemaal naar de cloud doorstuurde. En ze hebben hier ook point-in-time herstel aan toegevoegd.
Wat hadden de leerlingen nog meer meegenomen? Ze brachten ondersteuning voor Libsodium-codering naar WAL-G.
We hebben ook beleid voor back-upopslag. Nu kunnen back-ups als permanent worden gemarkeerd. En op de een of andere manier is het handiger voor uw service om het opslagproces te automatiseren.
Wat was het resultaat van dit experiment?
In eerste instantie hadden zich ruim 100 mensen aangemeld voor de cursus. In eerste instantie zei ik niet dat de universiteit in Jekaterinenburg de Federale Universiteit van de Oeral is. Daar hebben we alles aangekondigd. 100 mensen hebben zich aangemeld. In werkelijkheid zijn veel minder mensen iets gaan doen, ongeveer 30 mensen.
Nog minder mensen voltooiden de cursus, omdat het nodig was om tests te schrijven voor de codes die al bestaan. En repareer ook een bug of maak een functie. En sommige studenten sloten de cursus alsnog af.
Momenteel hebben studenten tijdens deze cursus ongeveer 14 problemen opgelost en 10 features van verschillende groottes gemaakt. En het lijkt mij dat dit een volwaardige vervanging is van een of twee ontwikkelaars.
We hebben onder meer diploma's en cursussen uitgereikt. En 12 ontvingen een diploma. 6 van hen hebben zich al verdedigd op “5”. Degenen die achterbleven hadden nog geen bescherming, maar ik denk dat ook voor hen alles goed zal komen.
Plannen voor de toekomst
Welke plannen hebben wij voor de toekomst?
In ieder geval die feature verzoeken die we al van gebruikers hebben gehoord en willen doen. Dit:
- Bewaken van de juistheid van het bijhouden van de tijdlijn in het back-uparchief van de HA-cluster. Dat kan met WAL-G. En ik denk dat we studenten zullen hebben die deze kwestie op zich zullen nemen.
- We hebben al een persoon die verantwoordelijk is voor het overbrengen van back-ups en WAL tussen clouds.
- En we hebben onlangs een idee gepubliceerd dat we WAL-G nog verder kunnen versnellen door incrementele back-ups uit te pakken zonder pagina's te herschrijven en door de archieven die we daarheen sturen te optimaliseren.
Je kunt ze hier delen
Waar was dit rapport voor? Bovendien hebben we nu, naast de 4 mensen die dit project steunen, extra handen, en dat zijn er best veel. Vooral als je ze een persoonlijk bericht schrijft. En maakt u een back-up van uw gegevens en doet u dit via WAL-G of wilt u overstappen naar WAL-G, dan kunnen wij vrij eenvoudig aan uw wensen voldoen.
Dit is een QR-code en een link. Je kunt ze doornemen en al je wensen opschrijven. We repareren bijvoorbeeld een bug niet. Of u wilt echt een functie, maar deze staat om de een of andere reden nog niet in een back-up, ook niet in de onze. Schrijf hier zeker over.
vragen
Hallo! Bedankt voor het rapport! Vraag over WAL-G, maar niet over Postgres. WAL-G maakt een back-up van MySQL en roept een extra back-up aan. Als we moderne installaties op CentOS nemen en als je MySQL installeert, wordt MariDB geïnstalleerd. Vanaf versie 10.3 wordt extra back-up niet ondersteund, MariDB-back-up wordt wel ondersteund. Hoe gaat het hiermee?
Op dit moment hebben we niet geprobeerd een back-up van MariDB te maken. We hebben verzoeken gehad voor ondersteuning door FoundationDB, maar over het algemeen kunnen we, als er een dergelijk verzoek is, mensen vinden die dit willen doen. Het is niet zo lang of zo moeilijk als ik denk.
Goedemiddag Bedankt voor het rapport! Vraag over mogelijke nieuwe functies. Bent u er klaar voor om WAL-G met tapes te laten werken, zodat u back-ups kunt maken op tapes?
Back-up op tape-opslag betekent blijkbaar?
Да.
Er is Andrei Borodin, die deze vraag beter kan beantwoorden dan ik.
(Andrey) Ja, bedankt voor de vraag! We hadden een verzoek om een back-up over te zetten naar tape vanuit de cloudopslag. En hiervoor overdracht tussen wolken. Omdat cloud-naar-cloud-overdracht een algemene versie van tape-overdracht is. Daarnaast hebben we een uitbreidbare architectuur op het gebied van opslag. Veel Storoges zijn trouwens door studenten geschreven. En als u Storage voor tape schrijft, wordt deze uiteraard ondersteund. We zijn klaar om pull-aanvragen te overwegen. Daar moet je een bestand schrijven, een bestand lezen. Als je deze dingen in Go doet, krijg je meestal 50 regels code. En dan wordt tape ondersteund in WAL-G.
Bedankt voor het rapport! Interessant ontwikkelingsproces. Back-up is een serieus stuk functionaliteit dat goed door tests moet worden gedekt. Toen u functionaliteit implementeerde voor nieuwe databases, schreven de studenten dan ook de tests, of schreef u de tests zelf en gaf u de implementatie vervolgens aan de studenten?
Studenten schreven ook tests. Maar studenten schreven meer voor functies zoals nieuwe databases. Ze schreven integratietesten. En ze schreven unit-tests. Als de integratie lukt, dat wil zeggen op dit moment, is dit een script dat je handmatig uitvoert of bijvoorbeeld cron laat doen. Dat wil zeggen, het script daar is heel duidelijk.
De studenten hebben nog niet veel ervaring. Kost het beoordelen veel tijd?
Ja, beoordelingen kosten behoorlijk wat tijd. Dat wil zeggen, meestal als meerdere committers tegelijk komen en zeggen: ik heb dit gedaan, ik heb dat gedaan, dan moet je nadenken en ongeveer een halve dag reserveren om erachter te komen wat ze daar hebben geschreven. Omdat de code zorgvuldig moet worden gelezen. Ze hebben geen interview gehad. We kennen ze niet zo goed, dus het kost veel tijd.
Bedankt voor het rapport! Eerder verklaarde Andrey Borodin dat archive_command in WAL-G rechtstreeks moet worden aangeroepen. Maar in het geval van een soort clustercartridge hebben we aanvullende logica nodig om te bepalen vanaf welk knooppunt de schachten moeten worden verzonden. Hoe los je dit probleem zelf op?
Wat is je probleem hier? Stel dat u een synchrone replica heeft waarmee u een back-up maakt? Of wat?
(Andrey) Feit is dat WAL-G inderdaad bedoeld is om gebruikt te worden zonder shellscripts. Als er iets ontbreekt, voegen we de logica toe die in WAL-G zou moeten zitten. Wat betreft de vraag waar archivering vandaan moet komen, zijn wij van mening dat archivering afkomstig moet zijn van de huidige master in het cluster. Archiveren vanaf een replica is een slecht idee. Er zijn verschillende mogelijke scenario's met problemen. In het bijzonder problemen met het archiveren van tijdlijnen en eventuele aanvullende informatie. Bedankt voor de vraag!
(Verduidelijking: we hebben shell-scripts verwijderd )
Goedeavond! Bedankt voor het rapport! Ik ben geïnteresseerd in de inhaalfunctie waar je het over had. We werden geconfronteerd met een situatie waarin een replica achterliep en niet kon inhalen. En ik heb geen beschrijving van deze functie gevonden in WAL-G-documenten.
Catchup verscheen letterlijk op 20 januari 2020. De documentatie heeft mogelijk wat meer werk nodig. We schrijven het zelf en we schrijven het niet supergoed. En misschien moeten we beginnen van studenten te eisen dat ze het schrijven.
Is het al vrijgegeven?
Het pull-verzoek is al dood, dat wil zeggen dat ik het heb gecontroleerd. Ik heb dit geprobeerd op een testcluster. Tot nu toe hebben we geen situatie gehad waarin we dit in een gevechtsvoorbeeld konden testen.
Wanneer te verwachten?
Ik weet het niet. Wacht een maand, we zullen het zeker controleren.
Bron: www.habr.com