Ik stel voor dat u het transcript van het rapport van begin 2019 van Andrey Borodin leest: "Back-ups met WAL-G. Wat is er in 2019?"
Dag Allemaal! Mijn naam is Andrey Borodin. Ik ben een ontwikkelaar bij Yandex. Ik ben sinds 2016 geïnteresseerd in PostgreSQL, nadat ik met de ontwikkelaars had gesproken en zij zeiden dat alles eenvoudig is: je neemt de broncode en bouwt deze, en alles komt goed. En sindsdien kan ik niet meer stoppen – ik schrijf allerlei verschillende dingen.
Een van de dingen waar ik aan werk is een back-upsysteem. . Over het algemeen werken we bij Yandex al heel lang aan back-upsystemen in PostgreSQL. En op internet vindt u een serie van zes rapporten over hoe wij back-upsystemen maken. En elk jaar evolueren ze een beetje, ontwikkelen ze een beetje en worden ze betrouwbaarder.
Maar vandaag gaat het rapport niet alleen over wat we hebben gedaan, maar ook over hoe eenvoudig het is en wat het is. Hoeveel van jullie hebben mijn reportages over WAL-G al bekeken? Het is goed dat er niet veel mensen hebben gekeken, want ik zal met het eenvoudigste beginnen.
Als je plotseling een PostgreSQL-cluster hebt, en ik denk dat iedereen er een paar bij zich heeft, en er plotseling nog geen back-upsysteem is, dan heb je S3-opslag of Google Cloud-compatibele opslag nodig.
U kunt bijvoorbeeld naar onze stand komen en een promotiecode voor Yandex Object Storage meenemen, die S3-compatibel is.
Maak vervolgens een emmer aan. Het is slechts een container voor informatie.
Maak een servicegebruiker aan.
Maak een toegangssleutel voor de servicegebruiker: aws-s3-key.
Download de nieuwste stabiele release van WAL-G.
Waarin verschillen onze pre-releases van releases? Ik word vaak gevraagd om vervroegd vrij te komen. En als er gedurende een voldoende tijd, bijvoorbeeld een maand, geen bug in de versie zit, dan geef ik deze vrij. Hier is deze release van november. En dit betekent dat we elke maand een bug vonden, meestal in niet-kritieke functionaliteit, maar dat we nog geen release hebben uitgebracht. De vorige versie is pas november. Er zijn bij ons geen bugs in bekend, d.w.z. bugs zijn toegevoegd naarmate het project vorderde.
Nadat u WAL-G heeft gedownload, kunt u een eenvoudige opdracht 'back-uplijst' uitvoeren, waarbij u de omgevingsvariabelen doorgeeft. En het zal verbinding maken met Object Storage en u vertellen welke back-ups u heeft. In eerste instantie zou u natuurlijk geen back-ups moeten hebben. Het doel van deze dia is om te laten zien dat alles vrij eenvoudig is. Dit is een consoleopdracht die omgevingsvariabelen accepteert en subopdrachten uitvoert.
Hierna kunt u uw eerste back-up maken. Zeg “backup-push” in WAL-G en specificeer in WAL-G de pgdata-locatie van uw cluster. En hoogstwaarschijnlijk zal PostgreSQL u vertellen dat, als u nog geen back-upsysteem heeft, u de "archiefmodus" moet inschakelen.
Dit betekent dat je naar de instellingen moet gaan en “archive_mode = on” moet inschakelen en “archive_command” moet toevoegen, wat ook een subcommando is in WAL-G. Maar om de een of andere reden gebruiken mensen vaak barscripts over dit onderwerp en wikkelen het rond WAL-G. Doe dit alsjeblieft niet. Gebruik de functionaliteit van WAL-G. Als je iets mist, schrijf dan naar . WAL-G gaat ervan uit dat dit het enige programma is dat in archive_command draait.
We gebruiken WAL-G voornamelijk om een High Availability-cluster te creëren in Yandex Database-beheer.
En het wordt meestal gebruikt in een topologie van één master en meerdere replicaties. Tegelijkertijd maakt het een back-up in Yandex Object Storage.
De meest voorkomende scenario's zijn het maken van kopieën van een cluster met behulp van herstel naar een bepaald tijdstip. Maar in dit geval zijn de prestaties van het back-upsysteem voor ons niet zo belangrijk. We hoeven alleen maar een nieuw cluster vanuit de back-up te uploaden.
Normaal gesproken hebben we back-upsysteemprestaties nodig bij het toevoegen van een nieuw knooppunt. Waarom is het belangrijk? Normaal gesproken voegen mensen een nieuw knooppunt toe aan een cluster omdat het bestaande cluster de leesbelasting niet aankan. Ze moeten een nieuwe replica toevoegen. Als we de belasting van pg_basebackup aan de Master toevoegen, kan de Master instorten. Daarom was het voor ons erg belangrijk dat we snel een nieuw knooppunt uit het archief konden uploaden, waardoor de Master minimaal werd belast.
En nog een soortgelijke situatie. Dit is de noodzaak om de oude Master opnieuw op te starten nadat de Cluster Master is overgeschakeld van het datacenter waarmee de connectiviteit is verloren.
- Hierdoor hebben we bij het formuleren van de eisen aan het kopieersysteem beseft dat pg_basebackup niet geschikt is voor ons als we in de cloud opereren.
- We wilden onze gegevens kunnen comprimeren. Maar bijna elk ander back-upsysteem dan wat in de doos zit, biedt datacompressie.
- We wilden alles parallelliseren omdat een gebruiker in de cloud een groot aantal processorcores koopt. Maar als we bij een bepaalde bewerking geen parallellisme hebben, wordt een groot aantal kernen nutteloos.
- We hebben encryptie nodig omdat de gegevens vaak niet van ons zijn en niet in leesbare tekst kunnen worden opgeslagen. Onze bijdrage aan WAL-G begon trouwens met encryptie. We voltooiden de encryptie in WAL-G, waarna ons werd gevraagd: “Misschien wil een van ons het project ontwikkelen?” En sindsdien werk ik al ruim een jaar met WAL-G.
- We hadden ook middelenbeperking nodig, omdat we na verloop van tijd door het gebruik van de cloud ontdekten dat mensen soms 's nachts een belangrijke boodschappenlading hebben en dat er niet met deze lading kan worden ingegrepen. Daarom hebben we resourcebeperking toegevoegd.
- Evenals notering en beheer.
- En verificatie.
We hebben veel verschillende tools bekeken. Gelukkig hebben we een enorme selectie in PostgreSQL. En overal misten we iets, de een een kleine functie, de ander een kleine feature.
En nadat we de bestaande systemen hadden onderzocht, kwamen we tot de conclusie dat we WAL-G gaan ontwikkelen. Het was toen een nieuw project. Het was vrij eenvoudig om de ontwikkeling naar de cloudinfrastructuur van het back-upsysteem te beïnvloeden.
De belangrijkste ideologie die wij aanhangen is dat WAL-G zo simpel moet zijn als een balalaika.
WAL-G heeft 4 commando's. Dit:
WAL-PUSH – archiveer de schacht.
WAL-FETCH – pak een schacht.
BACKUP-PUSH – maak een back-up.
BACKUP-FETCH – haal een back-up op van het back-upsysteem.
WAL-G heeft feitelijk ook het beheer over deze backups, d.w.z. het inventariseren en verwijderen van records en backups in de historie die op dit moment niet meer nodig zijn.
Een van de belangrijke functies voor ons is de functie van het maken van deltakopieën.
Delta-kopieën houden in dat we geen volledige back-up maken van het hele cluster, maar alleen van de gewijzigde pagina's van de gewijzigde bestanden in het cluster. Het lijkt erop dat dit functioneel sterk lijkt op de mogelijkheid om te herstellen met behulp van WAL. Maar we kunnen parallel een WAL single-threaded delta backup oprollen. Als we dus op zaterdag een basisback-up hebben gemaakt, dagelijks delta-back-ups, en op donderdag falen we, dan moeten we vier delta-back-ups en 4 uur WAL optellen. Het duurt ongeveer even lang omdat de deltaback-ups parallel worden uitgevoerd.
Op LSN gebaseerde delta's - dit betekent dat we bij het maken van een back-up elke pagina moeten combineren en de LSN ervan moeten controleren met de LSN van de vorige back-up om te begrijpen dat deze is gewijzigd. Elke pagina die mogelijk gewijzigde gegevens kan bevatten, moet aanwezig zijn in de deltaback-up.
Zoals ik al zei, werd er behoorlijk wat aandacht besteed aan parallellisme.
Maar de archief-API in PostgreSQL is consistent. PostgreSQL archiveert één WAL-bestand en vraagt bij het herstellen één WAL-bestand aan. Maar wanneer de database één WAL-bestand opvraagt met behulp van de opdracht "WAL-FETCH", roepen we de opdracht "WAL-PREFETCH" aan, die de volgende acht bestanden voorbereidt om parallel gegevens uit de objectopslag op te halen.
En als de database ons vraagt één bestand te archiveren, kijken we naar archive_status en kijken of er nog andere WAL-bestanden zijn. En we proberen ook WAL parallel te downloaden. Dit levert een aanzienlijke prestatiewinst op en verkleint de afstand in het aantal niet-gearchiveerde WAL's aanzienlijk. Veel ontwikkelaars van back-upsystemen zijn van mening dat dit zo'n riskant systeem is, omdat we vertrouwen op onze kennis van de interne onderdelen van code die niet de PostgreSQL API is. PostgreSQL garandeert voor ons niet de aanwezigheid van de map archive_status en garandeert niet de semantiek, de aanwezigheid van gereedheidssignalen voor WAL-bestanden daar. Niettemin bestuderen we de broncode, we zien dat dit zo is en we proberen deze te exploiteren. En wij bepalen de richting waarin PostgreSQL zich ontwikkelt; als dit mechanisme plotseling wordt verbroken, zullen we stoppen met het gebruik ervan.
In zijn pure vorm vereist de op LSN gebaseerde WAL delta het lezen van elk clusterbestand waarvan de modustijd in het bestandssysteem is veranderd sinds de vorige back-up. We hebben hier lang mee geleefd, bijna een jaar. En uiteindelijk kwamen we tot de conclusie dat we WAL-delta’s hebben.
Dit betekent dat elke keer dat we WAL op de Master archiveren, we deze niet alleen comprimeren, coderen en naar het netwerk sturen, maar we deze tegelijkertijd ook lezen. We analyseren en lezen de records daarin. We begrijpen welke blokken zijn veranderd en verzamelen deltabestanden.
Een deltabestand beschrijft een bepaald bereik van WAL-bestanden en beschrijft informatie over welke blokken in dit bereik van WAL zijn gewijzigd. En dan worden deze deltabestanden ook gearchiveerd.
Hier worden we geconfronteerd met het feit dat we alles vrij snel hebben geparallelliseerd, maar we kunnen geen opeenvolgende geschiedenis parallel lezen, omdat we in een bepaald segment het einde van het vorige WAL-record kunnen tegenkomen, waar we nog niets mee te maken hebben, omdat parallelle lezing leidde ertoe dat we eerst de toekomst analyseren, die nog geen verleden kent.
Als gevolg hiervan moesten we onbegrijpelijke stukken in _delta_partial-bestanden plaatsen. Als gevolg hiervan zullen we, wanneer we terugkeren naar het verleden, de stukjes van het WAL-record in één lijm plakken, daarna zullen we het analyseren en begrijpen wat erin is veranderd.
Als er in de geschiedenis van onze schachtparsering minstens één punt is waarop we niet begrijpen wat er gebeurde, dan zullen we tijdens de volgende back-up dienovereenkomstig gedwongen worden om het hele cluster opnieuw te lezen, net zoals we deden met een gewone LSN -gebaseerde delta.
Als gevolg hiervan leidde al ons lijden ertoe dat we de WAL-G-parseringsbibliotheek opensourceden. Voor zover ik weet, gebruikt nog niemand het, maar als iemand het wil schrijven en gebruiken, bevindt het zich in het publieke domein. (Bijgewerkte link )
Als gevolg hiervan zien alle informatiestromen er behoorlijk ingewikkeld uit. Onze Meester archiveert de schacht en archiveert deltabestanden. En de replica die de back-up maakt, moet deltabestanden ontvangen gedurende de tijd die tussen de back-ups is verstreken. In dit geval zullen delen van de geschiedenis in bulk moeten worden toegevoegd en geparseerd, omdat niet de gehele geschiedenis in grote segmenten past. En pas daarna kan de replica een volledige deltaback-up archiveren.
Op de grafieken ziet alles er veel eenvoudiger uit. Dit is een download van een van onze echte clusters. Wij hebben LSN-gebaseerd, gemaakt in één dag. En we zien dat de op LSN gebaseerde deltaback-up liep van drie uur 's ochtends tot vijf uur' s ochtends. Dit is de belasting van het aantal processorkernen. WAL-delta kostte ons hier ongeveer 20 minuten, dat wil zeggen, het werd aanzienlijk sneller, maar tegelijkertijd was er een intensere uitwisseling via het netwerk.
Omdat we informatie hebben over welke blokken zijn gewijzigd en op welk tijdstip in de geschiedenis van de database, zijn we verder gegaan en besloten om functionaliteit te integreren: een PostgreSQL-extensie genaamd “pg_prefaulter”
Dit betekent dat wanneer de stand-by basis de herstelopdracht uitvoert, deze WAL-G vertelt het volgende WAL-bestand op te halen. We begrijpen ongeveer tot welke datablokken het WAL-herstelproces in de nabije toekomst toegang zal krijgen en starten een leesoperatie op deze blokken. Dit werd gedaan om de prestaties van SSD-controllers te verbeteren. Omdat de WAL-rol de pagina bereikt die moet worden gewijzigd. Deze pagina staat op schijf en bevindt zich niet in de paginacache. En hij zal synchroon wachten tot deze pagina arriveert. Maar vlakbij is WAL-G, die weet dat we in de komende paar honderd megabytes WAL bepaalde pagina's nodig zullen hebben en ze tegelijkertijd begint op te warmen. Initieert meerdere schijftoegangen, zodat deze parallel worden uitgevoerd. Dit werkt goed op SSD-schijven, maar helaas absoluut niet van toepassing op een harde schijf, omdat we ons er alleen mee bemoeien met onze aanwijzingen.
Dit is wat er nu in de code staat.
Er zijn functies die we graag willen toevoegen.
Deze foto laat zien dat WAL-delta relatief kort duurt. En dit is het lezen van de veranderingen die gedurende de dag in de database hebben plaatsgevonden. We zouden de WAL-delta niet alleen 's nachts kunnen doen, omdat het niet langer een belangrijke bron van belasting is. We kunnen WAL-delta elke minuut lezen omdat het goedkoop is. Binnen één minuut kunnen we alle wijzigingen in het cluster scannen. En dit zou "instant WAL-delta" kunnen worden genoemd.
Het punt is dat wanneer we het cluster herstellen, we het aantal verhalen verminderen dat we opeenvolgend moeten oprollen. Dat wil zeggen dat de hoeveelheid WAL die PostgreSQL rolt moet worden verminderd, omdat dit veel tijd kost.
Maar dat is niet alles. Als we weten dat een blok zal worden gewijzigd tot het punt van back-upconsistentie, kunnen we dit in het verleden niet wijzigen. Dat wil zeggen, nu hebben we bestands-voor-bestand optimalisatie van WAL-delta forwarding. Dit betekent dat als bijvoorbeeld op dinsdag een tabel volledig is verwijderd of sommige bestanden volledig uit de tabel zijn verwijderd, wanneer delta op maandag doorrolt en de pg_basebackup van zaterdag wordt hersteld, we deze gegevens niet eens zullen aanmaken.
We willen deze technologie uitbreiden naar paginaniveau. Dat wil zeggen, als een deel van het bestand op maandag verandert, maar op woensdag wordt overschreven, hoeven we bij het herstellen naar een punt op donderdag de eerste paar versies van pagina's niet naar schijf te schrijven.
Maar dit is nog steeds een idee dat binnen ons actief wordt besproken, maar het heeft de code nog niet bereikt.
We willen nog een functie toevoegen aan WAL-G. We willen het uitbreidbaar maken omdat we verschillende databases moeten ondersteunen en het back-upbeheer graag op dezelfde manier willen kunnen benaderen. Maar het probleem is dat de MySQL API's radicaal verschillend zijn. In MySQL is PITR niet gebaseerd op het fysieke WAL-logboek, maar op de binlog. En we hebben geen archiveringssysteem in MySQL dat een extern systeem vertelt dat deze binlog klaar is en gearchiveerd moet worden. We moeten ergens in cron gaan staan met de database en controleren of er iets klaar is?
En op dezelfde manier is er tijdens een MySQL-herstel geen herstelopdracht die het systeem kan vertellen dat ik bepaalde bestanden nodig heb. Voordat u begint met het opnieuw opbouwen van uw cluster, moet u weten welke bestanden u nodig heeft. Je moet zelf raden welke bestanden je nodig hebt. Maar deze problemen kunnen op de een of andere manier worden omzeild. (Verduidelijking: MySQL wordt al ondersteund)
In het rapport wilde ik het ook hebben over de gevallen waarin WAL-G niet geschikt voor u is.
Als u niet over een synchrone replica beschikt, garandeert WAL-G niet dat het laatste segment behouden blijft. En als de archivering achterblijft bij de laatste paar delen van de geschiedenis, is dat een risico. Als er geen synchrone replica is, zou ik het gebruik van WAL-G niet aanbevelen. Toch is het vooral ontworpen voor een cloudinstallatie, wat een High Availability-oplossing impliceert met een synchrone replica, die verantwoordelijk is voor de veiligheid van de laatste vastgelegde bytes.
Ik zie vaak dat mensen zowel WAL-G als WAL-E tegelijkertijd proberen te gebruiken. We ondersteunen achterwaartse compatibiliteit in de zin dat WAL-G een bestand van WAL-E kan herstellen en een back-up gemaakt in WAL-E kan herstellen. Maar omdat beide systemen parallelle wal-push gebruiken, beginnen ze bestanden van elkaar te stelen. Als we het in WAL-G repareren, blijft het nog steeds in WAL-E. In WAL-E kijkt het naar de archiefstatus, ziet het de voltooide bestanden en archiveert ze, terwijl andere systemen simpelweg niet weten dat dit WAL-bestand bestond, omdat PostgreSQL niet zal proberen het een tweede keer te archiveren.
Wat gaan we hier aan de WAL-G-kant oplossen? We zullen PostgreSQL niet informeren dat dit bestand parallel is overgedragen, en wanneer PostgreSQL ons vraagt om het te archiveren, zullen we al weten dat een dergelijk bestand met deze modustijd en met deze md5 al is gearchiveerd en we zullen eenvoudigweg zeggen: PostgreSQL - Oké, alles is klaar zonder feitelijk iets te doen.
Maar het is onwaarschijnlijk dat dit probleem aan de WAL-E-kant zal worden opgelost, dus het is momenteel onmogelijk om een archiefopdracht te maken die het bestand zowel in WAL-G als WAL-E archiveert.
Daarnaast zijn er gevallen waarin WAL-G nu niet geschikt is voor u, maar wij gaan dit zeker oplossen.
Ten eerste hebben we momenteel geen ingebouwde back-upverificatie. We hebben geen verificatie tijdens back-up of herstel. Uiteraard wordt dit in de cloud geïmplementeerd. Maar dit wordt eenvoudigweg geïmplementeerd door vooraf te controleren, simpelweg door het cluster te herstellen. Ik wil deze functionaliteit graag aan gebruikers geven. Maar door verificatie ga ik ervan uit dat het in WAL-G mogelijk zal zijn om het cluster te herstellen en te starten, en rooktests uit te voeren: pg_dumpall naar /dev/null en amcheck indexverificatie.
Momenteel is er in WAL-G geen manier om één back-up van WAL uit te stellen. Dat wil zeggen, we ondersteunen een venster. Bijvoorbeeld het opslaan van de afgelopen zeven dagen, het opslaan van de laatste tien back-ups, het opslaan van de laatste drie volledige back-ups. Heel vaak komen mensen en zeggen: “We hebben een back-up nodig van wat er met Nieuwjaar is gebeurd en die willen we voor altijd bewaren.” WAL-G kan dit nog niet. (Opmerking - Dit is al opgelost. Lees meer - Back-upmarkeringsoptie in )
En we hebben geen paginacontrolesommen en integriteitscontroles voor alle schachtsegmenten bij het valideren van PITR.
Van dit alles heb ik een project samengesteld voor Google Summer of Code. Als je slimme studenten kent die iets in Go willen schrijven en enkele duizenden dollars willen krijgen van één bedrijf met de letter “G”, beveel hen dan ons project aan. Ik zal als mentor optreden voor dit project, zij kunnen het. Als er geen studenten zijn, dan neem ik het over en doe het zelf in de zomer.
En we hebben nog veel meer kleine problemen waar we geleidelijk aan aan werken. En er gebeuren behoorlijk vreemde dingen.
Geef je WAL-G bijvoorbeeld een lege backup, dan valt deze gewoon om. Als u hem bijvoorbeeld vertelt dat hij een back-up moet maken van een lege map. Het pg_control-bestand zal er niet zijn. En hij zal denken dat hij iets niet begrijpt. In theorie moet je in dit geval een normaal bericht naar de gebruiker schrijven om hem uit te leggen hoe hij de tool moet gebruiken. Maar dit is niet eens een kenmerk van programmeren, maar een kenmerk van een goede, begrijpelijke taal.
We weten niet hoe we offline back-ups moeten maken. Als de database liegt, kunnen we er geen back-up van maken. Maar alles is hier heel eenvoudig. We bellen back-ups via LSN toen het begon. Het LSN van de onderliggende basis moet uit het controlebestand worden gelezen. En dit is zo'n ongerealiseerde functie. Veel back-upsystemen kunnen een back-up maken van een onderliggende database. En het is handig.
Momenteel kunnen we het gebrek aan back-upruimte niet goed opvangen. Omdat wij thuis meestal met grote backups werken. En daar kwamen ze niet aan toe. Maar als iemand nu in Go wil programmeren, voeg dan de afhandeling voor fouten door onvoldoende ruimte toe aan de bucket. Ik ga de pull request zeker bekijken.
En het belangrijkste dat ons zorgen baart, is dat we zoveel mogelijk docker-integratietests willen die verschillende scenario's controleren. Op dit moment testen we alleen basisscenario's. Bij elke commit, maar we willen commit voor commit alle functionaliteit controleren die we ondersteunen. In het bijzonder zullen we bijvoorbeeld voldoende ondersteuning hebben voor PostgreSQL 9.4-9.5. We ondersteunen ze omdat de community PostgreSQL ondersteunt, maar we controleren niet commit per commit om er zeker van te zijn dat alles niet kapot is. En het lijkt mij dat dit een tamelijk ernstig risico is.
We hebben WAL-G draaiend op meer dan duizend clusters in Yandex Database-beheer. En het maakt elke dag een back-up van honderden terabytes aan gegevens.
We hebben veel TODO in onze code. Als je wilt programmeren, kom dan, we wachten op pull-aanvragen, we wachten op vragen.
vragen
Goedeavond! Bedankt! Ik vermoed dat als je WAL-delta gebruikt, je waarschijnlijk sterk afhankelijk bent van schrijven op volledige pagina's. En zo ja, heb je testen uitgevoerd? Je liet een prachtige grafiek zien. Hoeveel mooier wordt het als FPW uitgeschakeld wordt?
Schrijven op volledige pagina's is voor ons ingeschakeld, we hebben niet geprobeerd dit uit te schakelen. Dat wil zeggen dat ik als ontwikkelaar niet heb geprobeerd het uit te schakelen. Systeembeheerders die onderzoek hebben gedaan, hebben dit probleem waarschijnlijk onderzocht. Maar we hebben FPW nodig. Bijna niemand schakelt het uit, omdat het anders onmogelijk is om een backup te maken van een replica.
Bedankt voor het rapport! Ik heb twee vragen. De eerste vraag is: wat gebeurt er met tabelruimten?
We wachten op een pull-verzoek. Onze databases staan op SSD- en NMVE-schijven en we hebben deze functie niet echt nodig. Ik ben er momenteel niet klaar voor om er serieus tijd aan te besteden om het goed te doen. Ik pleit er van harte voor dat wij dit steunen. Er zijn mensen die het steunden, maar steunden het op een manier die bij hen past. Ze hebben een fork gemaakt, maar ze doen geen pull-verzoeken. (Toegevoegd in versie 0.2.13)
En de tweede vraag. U zei helemaal aan het begin dat WAL-G ervan uitgaat dat het alleen werkt en dat er geen wikkels nodig zijn. Ik gebruik zelf wikkels. Waarom mogen ze niet worden gebruikt?
We willen dat het zo simpel is als een balalaika. Dit betekent dat je helemaal niets nodig hebt behalve een balalaika. Wij willen dat het systeem eenvoudig is. Als u functionaliteit heeft die u in een script moet doen, kom het ons dan vertellen - wij doen het in Go.
Goedeavond! Bedankt voor het rapport! We konden WAL-G niet laten werken met GPG-decodering. Het codeert normaal, maar wil niet decoderen. Is het iets wat bij ons niet gelukt is? De situatie is deprimerend.
Maak een probleem op GitHub en laten we het uitzoeken.
Dat wil zeggen: je bent dit nog niet tegengekomen?
Er is een kenmerk van het foutrapport dat wanneer WAL-G niet begrijpt wat voor soort bestand het is, het vraagt: "Misschien is het gecodeerd?" Misschien is het probleem helemaal niet de encryptie. Ik wil de logboekregistratie over dit onderwerp verbeteren. Hij moet het ontcijferen. We werken momenteel aan dit onderwerp in de zin dat we niet echt tevreden zijn met de manier waarop het systeem voor het verkrijgen van publieke en private sleutels is georganiseerd. Omdat we externe GPG bellen zodat deze ons zijn sleutels geeft. En dan nemen we deze sleutels en dragen ze over naar de interne GPG, wat een open PGP is, die voor ons is samengesteld binnen WAL-G, en daar noemen we encryptie. In dit opzicht willen we het systeem verbeteren en de Libsodium-codering ondersteunen (Toegevoegd in versie 0.2.15). Natuurlijk zou het decoderen moeten werken, laten we het uitzoeken - je hebt meer een symptoom nodig dan een paar woorden. Je kunt een keer samenkomen in de kamer van de spreker en het systeem bekijken. (PGP-codering zonder externe GPG - v0.2.9)
Hallo! Bedankt voor het rapport! Ik heb twee vragen. Ik heb een vreemde wens om pg_basebackup en WAL in te loggen bij twee providers, d.w.z. ik wil de ene cloud en de andere doen. Is er een manier om dit te doen?
Dit bestaat nu niet, maar het is een interessant idee.
Ik vertrouw de ene aanbieder gewoon niet, ik wil hetzelfde bij een andere aanbieder hebben, voor het geval dat.
Het idee is interessant. Technisch gezien is dit helemaal niet moeilijk om te implementeren. Om te voorkomen dat het idee verloren gaat, mag ik je vragen een issue te maken op GitHub?
Ja, natuurlijk.
En als leerlingen dan naar Google Summer of Code komen, voegen we ze toe aan het project, zodat er meer werk is om meer uit ze te halen.
En de tweede vraag. Er is een probleem op GitHub. Ik denk dat het al gesloten is. Er is paniek tijdens het herstel. En om het te verslaan, heb je een aparte vergadering gemaakt. Het klopt in kwesties. En er is een optie om een variabele omgeving in één thread te doen. En daarom werkt het heel langzaam. En we zijn dit probleem tegengekomen en het is nog niet opgelost.
Het probleem is dat de opslag (CEPH) om de een of andere reden de verbinding opnieuw instelt als we er met hoge gelijktijdigheid bij komen. Wat kan hieraan gedaan worden? De logica voor opnieuw proberen ziet er als volgt uit. We proberen het bestand opnieuw te downloaden. In één keer hadden we een aantal bestanden niet gedownload, we zullen een tweede maken voor iedereen die niet heeft ingelogd. En zolang er minimaal één bestand per iteratie wordt geladen, herhalen we en herhalen en herhalen. We hebben de logica van opnieuw proberen verbeterd: exponentiële uitstel. Maar het is niet helemaal duidelijk wat we moeten doen met het feit dat de verbinding eenvoudigweg kapot gaat aan de kant van het opslagsysteem. Dat wil zeggen dat wanneer we naar één stream uploaden, deze verbindingen niet worden verbroken. Wat kunnen we hier verbeteren? We hebben netwerkbeperking, we kunnen elke verbinding beperken door het aantal bytes dat wordt verzonden. Anders weet ik niet hoe ik moet omgaan met het feit dat objectopslag ons niet toestaat er parallel van te downloaden of te downloaden.
Geen SLA? Is het niet voor hen geschreven hoe zij zich laten kwellen?
Het punt is dat mensen die met deze vraag komen, meestal hun eigen kluis hebben. Dat wil zeggen, niemand komt van Amazon of Google Cloud of Yandex Object Storage.
Misschien is de vraag niet langer voor jou?
De vraag doet er in dit geval niet toe aan wie. Als er ideeën zijn om hiermee om te gaan, laten we dat dan in WAL-G doen. Maar tot nu toe heb ik geen goede ideeën over hoe hiermee om te gaan. Er zijn enkele Object Storage die back-ups op een andere manier ondersteunen. Je vraagt ze om objecten op te sommen, en ze voegen daar een map toe. WAL-G wordt hier bang van - er is hier iets dat geen bestand is, ik kan het niet herstellen, wat betekent dat de back-up niet is hersteld. Dat wil zeggen dat u in feite een volledig hersteld cluster heeft, maar u krijgt een onjuiste status terug omdat Object Storage vreemde informatie heeft geretourneerd die niet volledig werd begrepen.
Dit is iets dat gebeurt in de Mail-cloud.
Als je een reproductie kunt maken...
Het wordt consequent herhaald...
Als er sprake is van een reproductie, denk ik dat we zullen experimenteren met strategieën voor opnieuw proberen en uitzoeken hoe we het opnieuw kunnen proberen en begrijpen wat de cloud van ons vraagt. Misschien is het voor ons stabiel op drie verbindingen en wordt de verbinding niet verbroken, dan bereiken we er voorzichtig drie. Omdat we nu de verbinding heel snel verbreken, d.w.z. als we een herstel starten met 16 threads, dan zullen er na de eerste nieuwe poging 8 threads, 4 threads, 2 threads en één zijn. En dan wordt het bestand in één stream verzameld. Als er enkele magische waarden zijn, zoals 7,5 threads, die het beste zijn om te pompen, dan zullen we daar bij stilstaan en proberen nog eens 7,5 threads te maken. Hier is een idee.
Bedankt voor het rapport! Hoe ziet een complete workflow voor het werken met WAL-G eruit? Bijvoorbeeld in het stomme geval dat er geen delta is tussen de pagina's. En we nemen en verwijderen de eerste back-up, en archiveren vervolgens de schacht totdat we blauw in het gezicht zijn. Hier is, zoals ik het begrijp, sprake van een storing. Op een gegeven moment moet u een deltaback-up van pagina's maken, dat wil zeggen dat een extern proces dit aanstuurt, of hoe gebeurt dit?
De delta-back-up-API is vrij eenvoudig. Daar staat een getal: maximale deltastappen, zo heet het. Standaard staat deze op nul. Dit betekent dat elke keer dat u een back-up-push uitvoert, er een volledige back-up wordt gedownload. Als u dit wijzigt in een positief getal, bijvoorbeeld 3, wordt er de volgende keer dat u een back-up-push uitvoert, gekeken naar de geschiedenis van eerdere back-ups. Hij ziet dat je de keten van 3 delta’s niet overschrijdt en maakt een delta.
Dat wil zeggen: elke keer dat we WAL-G starten, probeert het een volledige back-up te maken?
Nee, we gebruiken WAL-G en het probeert een delta te maken als uw beleid dit toestaat.
Grof gezegd: als u het elke keer met nul uitvoert, zal het zich dan gedragen als pg_basebackup?
Nee, het werkt nog steeds sneller omdat het compressie en parallellisme gebruikt. Pg_basebackup zal de schacht naast je plaatsen. WAL-G gaat ervan uit dat u archivering heeft geconfigureerd. En het zal een waarschuwing geven als het niet is geconfigureerd.
Pg_basebackup kan zonder schachten worden uitgevoerd.
Ja, dan zullen ze zich vrijwel hetzelfde gedragen. Pg_basebackup kopieert naar het bestandssysteem. We hebben trouwens een nieuwe functie die ik vergat te vermelden. We kunnen nu een back-up maken naar het bestandssysteem vanaf pg_basebackup. Ik weet niet waarom dit nodig is, maar het is er.
Bijvoorbeeld op CephFS. Niet iedereen wil Object Storage configureren.
Ja, dat is waarschijnlijk de reden waarom ze een vraag over deze functie stelden, zodat we het konden doen. En wij hebben het gedaan.
Bedankt voor het rapport! Er is alleen een vraag over het kopiëren naar het bestandssysteem. Ondersteunt u nu het kopiëren naar externe opslag, bijvoorbeeld als er een plank in het datacenter is of iets anders?
In deze formulering is dit een moeilijke vraag. Ja, wij ondersteunen, maar deze functionaliteit is nog niet in een release opgenomen. Dat wil zeggen dat alle pre-releases dit ondersteunen, maar de releaseversies niet. Deze functionaliteit is toegevoegd in versie 0.2. Het zal zeker binnenkort worden uitgebracht, zodra we alle bekende bugs hebben opgelost. Maar op dit moment kan dit alleen in pre-release worden gedaan. Er zitten twee bugs in de pre-release. Probleem met WAL-E-herstel, we hebben het niet opgelost. En in de laatste pre-release is een bug over delta-backup toegevoegd. Daarom raden wij iedereen aan de releaseversies te gebruiken. Zodra er geen bugs meer in de pre-release zitten, kunnen we zeggen dat we Google Cloud, S3-compatibele zaken en bestandsopslag ondersteunen.
Hallo, bedankt voor het rapport. Zoals ik het begrijp, is WAL-G niet een soort gecentraliseerd systeem zoals barmannen? Bent u van plan om deze richting op te gaan?
Het probleem is dat we van deze richting zijn afgeweken. WAL-G leeft op de basishost, op de clusterhost en op alle hosts in het cluster. Toen we naar enkele duizenden clusters verhuisden, hadden we veel bartenderinstallaties. En elke keer dat er iets in hen uiteenvalt, is het een groot probleem. Omdat ze gerepareerd moeten worden, moet je begrijpen welke clusters nu geen back-ups hebben. Ik ben niet van plan WAL-G te ontwikkelen in de richting van fysieke hardware voor back-upsystemen. Als de community hier wat functionaliteit wil, vind ik dat helemaal niet erg.
We hebben teams die verantwoordelijk zijn voor de opslag. En we voelen ons zo goed dat wij het niet zijn, dat er speciale mensen zijn die onze bestanden op een veilige plek plaatsen. Ze voeren daar allerlei slimme codering uit om het verlies van een bepaald aantal bestanden te weerstaan. Zij zijn verantwoordelijk voor de netwerkbandbreedte. Als u een barman heeft, komt u er misschien plotseling achter dat er op dezelfde server kleine databases met veel verkeer zijn verzameld. Het lijkt erop dat je er veel ruimte op hebt, maar om de een of andere reden past niet alles door het netwerk. Het kan andersom uitpakken. Er zijn daar veel netwerken, er zijn processorkernen, maar er zijn hier geen schijven. En we waren de noodzaak om met iets te jongleren beu, en we zijn overgegaan op het feit dat gegevensopslag een aparte dienst is, waarvoor aparte speciale mensen verantwoordelijk zijn.
PS Er is een nieuwe versie uitgebracht , waarin u het configuratiebestand .walg.json kunt gebruiken, dat zich standaard in de homedirectory van postgres bevindt. Je kunt bash-scripts achterwege laten. Voorbeeld .walg.json staat in dit nummer
Video:
Bron: www.habr.com