Jag föreslår att du läser utskriften av rapporten från början av 2019 av Andrey Borodin "Backups with WAL-G. What's there in 2019?"
Hej alla! Jag heter Andrey Borodin. Jag är utvecklare på Yandex. Jag har varit intresserad av PostgreSQL sedan 2016, efter att jag pratat med utvecklarna och de sa att allt är enkelt – du tar källkoden och bygger den, så löser sig allt. Och sedan dess kan jag inte sluta – jag skriver alla möjliga olika saker.
En av de saker jag jobbar med är ett backupsystem. . Generellt sett har vi på Yandex arbetat med säkerhetskopieringssystem i PostgreSQL under mycket lång tid. Och du kan hitta på Internet en serie med sex rapporter om hur vi gör backup-system. Och varje år utvecklas de lite, utvecklas lite och blir mer pålitliga.
Men idag handlar rapporten inte bara om vad vi har gjort, utan också om hur enkelt det är och vad som är. Hur många av er har redan sett mina rapporter om WAL-G? Det är bra att ganska många inte tittade, för jag börjar med det enklaste.
Om du plötsligt har ett PostgreSQL-kluster, och jag tror att alla har ett par av dem med sig, och plötsligt inte finns något backupsystem än, måste du skaffa valfri S3-lagring eller Google Cloud-kompatibel lagring.
Du kan till exempel komma till vår monter och ta en kampanjkod för Yandex Object Storage, som är S3-kompatibel.
Skapa sedan en hink. Det är bara en behållare för information.
Skapa en tjänstanvändare.
Skapa en åtkomstnyckel för tjänstanvändaren: aws-s3-key.
Ladda ner den senaste stabila versionen av WAL-G.
Hur skiljer sig våra pre-releases från releaser? Jag blir ofta ombedd att släppa tidigt. Och om det inte finns någon bugg i versionen under en tillräcklig tid, till exempel en månad, släpper jag den. Här är denna release från november. Och det betyder att vi varje månad hittade någon form av bugg, vanligtvis i icke-kritisk funktionalitet, men vi har ännu inte släppt någon release. Den tidigare versionen är bara november. Det finns inga buggar kända för oss i den, det vill säga buggar lades till allt eftersom projektet fortskred.
När du har laddat ner WAL-G kan du köra ett enkelt "backup list"-kommando och skicka in miljövariablerna. Och den kommer att ansluta till Object Storage och berätta vilka säkerhetskopior du har. Till en början bör du naturligtvis inte ha säkerhetskopior. Poängen med denna bild är att visa att allt är ganska enkelt. Detta är ett konsolkommando som accepterar miljövariabler och exekverar underkommandon.
Efter detta kan du göra din första säkerhetskopia. Säg "backup-push" i WAL-G och ange i WAL-G pgdata-platsen för ditt kluster. Och troligtvis kommer PostgreSQL att berätta för dig, om du inte redan har ett backupsystem, att du måste aktivera "arkivläge".
Det betyder att du måste gå till inställningar och slå på "archive_mode = on" och lägga till "archive_command", som också är ett underkommando i WAL-G. Men av någon anledning använder folk ofta stapelskript om detta ämne och lindar det runt WAL-G. Snälla gör inte det här. Använd funktionen som finns i WAL-G. Om du saknar något, skriv till . WAL-G antar att det är det enda programmet som körs i archive_command.
Vi använder WAL-G främst för att skapa ett High Availability-kluster i Yandex Database Management.
Och det används vanligtvis i en topologi av en Master och flera replikeringar. Samtidigt gör den en säkerhetskopia i Yandex Object Storage.
De vanligaste scenarierna är att skapa kopior av ett kluster med Point in time recovery. Men i det här fallet är prestandan för backupsystemet inte så viktig för oss. Vi behöver bara ladda upp ett nytt kluster från säkerhetskopian.
Vanligtvis behöver vi backupsystemprestanda när vi lägger till en ny nod. Varför är det viktigt? Vanligtvis lägger folk till en ny nod till ett kluster eftersom det befintliga klustret inte kan hantera läsbelastningen. De måste lägga till en ny replik. Om vi lägger till laddningen från pg_basebackup till Mastern kan Mastern kollapsa. Därför var det mycket viktigt för oss att vi snabbt kunde ladda upp en ny nod från arkivet, vilket skapade minimal belastning på Mastern.
Och en annan liknande situation. Detta är behovet av att starta om den gamla mastern efter att ha bytt klustermaster från datacentret som anslutningen förlorades med.
- Som ett resultat, när vi formulerade kraven för kopieringssystemet, insåg vi att pg_basebackup inte är lämpligt för oss när vi arbetar i molnet.
- Vi ville kunna komprimera vår data. Men nästan alla säkerhetskopieringssystem förutom det som kommer i lådan kommer att ge datakomprimering.
- Vi ville parallellisera allt eftersom en användare i molnet köper ett stort antal processorkärnor. Men om vi inte har parallellitet i någon operation, blir ett stort antal kärnor värdelösa.
- Vi behöver kryptering eftersom uppgifterna ofta inte är vår och inte kan lagras i klartext. Förresten, vårt bidrag till WAL-G började med kryptering. Vi slutförde krypteringen i WAL-G, varefter vi fick frågan: "Kanske kommer någon av oss att utveckla projektet?" Och sedan dess har jag arbetat med WAL-G i mer än ett år.
- Vi behövde också resursstrypning, för med tiden när vi använde molnet fick vi reda på att ibland har människor en viktig matvarubelastning på natten och denna belastning kan inte störas. Det var därför vi lade till resursstrypning.
- Samt notering och förvaltning.
- Och verifiering.
Vi tittade på många olika verktyg. Som tur är har vi ett stort urval i PostgreSQL. Och överallt saknade vi något, någon liten funktion, någon liten funktion.
Och efter att ha undersökt de befintliga systemen kom vi fram till att vi kommer att utveckla WAL-G. Det var ett nytt projekt då. Det var ganska enkelt att påverka utvecklingen mot backupsystemets molninfrastruktur.
Den huvudsakliga ideologin som vi håller fast vid är att WAL-G ska vara så enkelt som en balalajka.
WAL-G har 4 kommandon. Detta:
WAL-PUSH – arkivera skaftet.
WAL-FETCH – skaffa ett skaft.
BACKUP-PUSH – gör en säkerhetskopia.
BACKUP-FETCH – få en backup från backupsystemet.
Faktum är att WAL-G också hanterar dessa säkerhetskopior, det vill säga listar och raderar poster och säkerhetskopior i historiken som inte längre behövs för tillfället.
En av de viktiga funktionerna för oss är funktionen att skapa deltakopior.
Deltakopior gör att vi inte skapar en fullständig säkerhetskopia av hela klustret, utan endast de ändrade sidorna av de ändrade filerna i klustret. Det verkar som att detta funktionellt sett är väldigt likt möjligheten att återställa med WAL. Men vi kan rulla upp en WAL enkeltrådad delta backup parallellt. Följaktligen, när vi gör en grundläggande säkerhetskopia på lördag, delta backup dagligen och på torsdag misslyckas vi, då måste vi rulla upp 4 delta backuper och 10 timmar WAL. Det kommer att ta ungefär samma tid eftersom delta-backuperna rullar parallellt.
LSN-baserade deltas - detta betyder att när vi skapar en säkerhetskopia måste vi kombinera varje sida och kontrollera dess LSN med LSN för den tidigare säkerhetskopian för att förstå att den har ändrats. Alla sidor som eventuellt kan innehålla ändrade data bör finnas i deltabackupen.
Som sagt ägnades ganska stor uppmärksamhet åt parallellitet.
Men arkiv-API:et i PostgreSQL är konsekvent. PostgreSQL arkiverar en WAL-fil och begär en WAL-fil när den återställs. Men när databasen begär en WAL-fil med kommandot "WAL-FETCH" anropar vi kommandot "WAL-PREFETCH", som förbereder nästa 8 filer för att hämta data från objektlagret parallellt.
Och när databasen ber oss att arkivera en fil tittar vi på archive_status och ser om det finns andra WAL-filer. Och vi försöker också ladda ner WAL parallellt. Detta ger en betydande prestandavinst och minskar avsevärt avståndet i antalet oarkiverade WAL. Många utvecklare av backupsystem tror att detta är ett så riskabelt system eftersom vi förlitar oss på vår kunskap om insidan av kod som inte är PostgreSQL API. PostgreSQL garanterar inte närvaron av mappen archive_status för oss och garanterar inte semantiken, närvaron av beredskapssignaler för WAL-filer där. Ändå studerar vi källkoden, vi ser att det är så och vi försöker utnyttja den. Och vi kontrollerar i vilken riktning PostgreSQL utvecklas; om den här mekanismen plötsligt bryts kommer vi att sluta använda den.
I sin rena form kräver LSN-baserad WAL delta läsning av alla klusterfiler vars lägestid i filsystemet har ändrats sedan föregående säkerhetskopiering. Vi levde med det här länge, nästan ett år. Och till slut kom vi fram till att vi har WAL-delta.
Det betyder att varje gång vi arkiverar WAL på Mastern komprimerar vi det inte bara, krypterar det och skickar det till nätverket, utan vi läser det också samtidigt. Vi analyserar och läser protokollen i den. Vi förstår vilka block som har ändrats och samlar in deltafiler.
En deltafil beskriver ett visst intervall av WAL-filer, beskriver information om vilka block som ändrades i detta intervall av WAL. Och sedan arkiveras även dessa deltafiler.
Här står vi inför det faktum att vi parallelliserade allt ganska snabbt, men vi kan inte läsa en sekventiell historia parallellt, eftersom vi i ett visst segment kan stöta på slutet av den tidigare WAL-posten, som vi inte har något att koppla ihop med ännu, eftersom parallellläsning ledde till att vi först analyserar framtiden, som ännu inte har ett förflutet.
Som ett resultat var vi tvungna att lägga in obegripliga delar i _delta_partial-filer. Som ett resultat, när vi återvänder till det förflutna, kommer vi att limma delarna av WAL-posten till en, efter det kommer vi att analysera den och förstå vad som förändrades i den.
Om det i historien om vår axelanalys finns åtminstone en punkt där vi inte förstår vad som hände, så kommer vi följaktligen att under nästa säkerhetskopiering tvingas läsa hela klustret igen, precis som vi gjorde med ett vanligt LSN -baserat delta.
Som ett resultat ledde allt vårt lidande till att vi öppnade WAL-G-analysbiblioteket. Så vitt jag vet är det ingen som använder det än, men om någon vill, skriva och använda det är det allmän egendom. (Uppdaterad länk )
Som ett resultat ser alla informationsflöden ganska komplicerade ut. Vår Master arkiverar schaktet och arkiverar deltafiler. Och repliken som gör säkerhetskopian måste ta emot deltafiler under tiden som har gått mellan säkerhetskopieringarna. I det här fallet kommer delar av historiken att behöva läggas till i bulk och analyseras, eftersom inte hela historiken passar in i stora segment. Och först efter detta kan repliken arkivera en fullständig deltabackup.
På graferna ser allt mycket enklare ut. Detta är en nedladdning från ett av våra riktiga kluster. Vi har LSN-baserade, gjorda på en dag. Och vi ser att den LSN-baserade deltabackupen körde från tre på morgonen till fem på morgonen. Detta är belastningen i antalet processorkärnor. WAL-delta tog oss ca 20 minuter här, det vill säga det blev betydligt snabbare, men samtidigt blev det ett mer intensivt utbyte över nätet.
Eftersom vi har information om vilka block som ändrats och vid vilken tidpunkt i databasens historia, gick vi längre och bestämde oss för att integrera funktionalitet - en PostgreSQL-tillägg som heter "pg_prefaulter"
Detta betyder att när beredskapsbasen kör återställningskommandot, säger den åt WAL-G att hämta nästa WAL-fil. Vi förstår ungefär vilka datablock som WAL-återställningsprocessen kommer att komma åt inom en snar framtid och initierar en läsoperation på dessa block. Detta gjordes för att öka prestandan hos SSD-kontroller. Eftersom WAL-rullen kommer att nå sidan som behöver ändras. Den här sidan finns på disk och finns inte i sidcachen. Och han kommer att vänta synkront på att den här sidan ska komma. Men i närheten finns WAL-G, som vet att vi under de närmaste hundra megabyte WAL kommer att behöva vissa sidor och samtidigt börjar värma upp dem. Initierar flera diskåtkomster så att de exekveras parallellt. Detta fungerar bra på SSD-enheter, men tyvärr är det absolut inte tillämpligt för en hårddisk, eftersom vi bara stör det med våra uppmaningar.
Detta är vad som står i koden nu.
Det finns funktioner som vi skulle vilja lägga till.
Denna bild visar att WAL-delta tar relativt kort tid. Och det här är att läsa förändringarna som inträffade i databasen under dagen. Vi skulle kunna göra WAL-delta inte bara på natten, eftersom det inte längre är en betydande källa till belastning. Vi kan läsa WAL-delta varje minut eftersom det är billigt. På en minut kan vi skanna alla ändringar som har skett i klustret. Och detta kan kallas "instant WAL-delta".
Poängen är att när vi återställer klustret minskar vi antalet berättelser som vi måste rulla upp sekventiellt. Det vill säga mängden WAL som PostgreSQL rullar bör minskas, eftersom det tar betydande tid.
Men det är inte allt. Om vi vet att något block kommer att ändras till punkten för säkerhetskopiering, kan vi inte ändra det tidigare. Det vill säga, nu har vi fil-för-fil-optimering av WAL-delta-vidarebefordran. Detta betyder att om, till exempel på tisdag, en tabell raderades helt eller några filer raderades helt från tabellen, kommer vi inte ens att skapa denna data när delta rullar över på måndag och lördagens pg_basebackup återställs.
Vi vill utöka denna teknik till sidnivå. Det vill säga, om någon del av filen ändras på måndag, men kommer att skrivas över på onsdag, behöver vi inte skriva de första versionerna av sidorna till disken när vi återställer till en punkt på torsdagen.
Men detta är fortfarande en idé som diskuteras aktivt inom oss, men den har ännu inte nått koden.
Vi vill göra ytterligare en funktion i WAL-G. Vi vill göra det utbyggbart eftersom vi behöver stödja olika databaser och skulle vilja kunna närma oss backuphantering på samma sätt. Men problemet är att MySQL API:erna är radikalt annorlunda. I MySQL är PITR inte baserad på den fysiska WAL-loggen, utan på binloggen. Och vi har inte ett arkiveringssystem i MySQL som skulle tala om för något externt system att den här binloggen är klar och måste arkiveras. Vi måste stå någonstans i cron med databasen och kolla om det finns något klart?
Och på samma sätt, under en MySQL-återställning, finns det inget återställningskommando som kan tala om för systemet att jag behöver sådana och sådana filer. Innan du börjar bygga om ditt kluster måste du veta vilka filer du behöver. Du måste själv gissa vilka filer du behöver. Men dessa problem kanske går att kringgå på något sätt. (Förtydligande: MySQL stöds redan)
I rapporten ville jag också prata om de fall då WAL-G inte passar dig.
Om du inte har en synkron replika garanterar inte WAL-G att det sista segmentet kommer att bevaras. Och om arkivering släpar efter de senaste delarna av historien är det en risk. Om det inte finns någon synkron replika skulle jag inte rekommendera att använda WAL-G. Ändå är den huvudsakligen designad för en molninstallation, vilket innebär en High Availability-lösning med en synkron replika, som ansvarar för säkerheten för de sista byten som begåtts.
Jag ser ofta människor som försöker köra både WAL-G och WAL-E samtidigt. Vi stöder bakåtkompatibilitet i den meningen att WAL-G kan återställa en fil från WAL-E och kan återställa en säkerhetskopia gjord i WAL-E. Men eftersom båda dessa system använder parallell wal-push, börjar de stjäla filer från varandra. Om vi fixar det i WAL-G kommer det fortfarande att finnas kvar i WAL-E. I WAL-E tittar den på arkivstatus, ser de färdiga filerna och arkiverar dem, medan andra system helt enkelt inte kommer att veta att denna WAL-fil existerade, eftersom PostgreSQL inte kommer att försöka arkivera den en andra gång.
Vad ska vi fixa här på WAL-G-sidan? Vi kommer inte att informera PostgreSQL om att den här filen överfördes parallellt, och när PostgreSQL ber oss att arkivera den kommer vi redan att veta att en sådan fil med denna lägestid och med denna md5 redan har arkiverats och vi säger helt enkelt PostgreSQL - OK, allt är klart utan att göra någonting.
Men det här problemet kommer sannolikt inte att åtgärdas på WAL-E-sidan, så det är för närvarande omöjligt att skapa ett arkivkommando som kommer att arkivera filen i både WAL-G och WAL-E.
Dessutom finns det fall där WAL-G inte passar dig nu, men vi kommer definitivt att fixa det.
För det första har vi för närvarande ingen inbyggd säkerhetskopieringsverifiering. Vi har ingen verifiering vare sig under säkerhetskopiering eller återställning. Naturligtvis är detta implementerat i molnet. Men detta implementeras helt enkelt genom förkontroll, helt enkelt genom att återställa klustret. Jag skulle vilja ge den här funktionen till användarna. Men genom verifiering antar jag att det i WAL-G kommer att vara möjligt att återställa klustret och starta det, och köra röktester: pg_dumpall till /dev/null och amcheck indexverifiering.
För närvarande i WAL-G finns det inget sätt att skjuta upp en säkerhetskopiering från WAL. Det vill säga, vi stöder något fönster. Till exempel, lagring av de senaste sju dagarna, lagring av de senaste tio säkerhetskopiorna, lagring av de senaste tre fullständiga säkerhetskopiorna. Ganska ofta kommer folk och säger: "Vi behöver en säkerhetskopia av vad som hände på nyår och vi vill behålla det för alltid." WAL-G vet ännu inte hur man gör detta. (Obs - Detta har redan åtgärdats. Läs mer - Backup-mark option i )
Och vi har inte sidkontrollsummor och integritetskontroller för alla axelsegment när vi validerar PITR.
Av allt detta har jag satt ihop ett projekt för Google Summer of Code. Om du känner smarta studenter som skulle vilja skriva något i Go och få flera tusen dollar från ett företag med bokstaven "G", rekommendera då vårt projekt till dem. Jag kommer att fungera som mentor för det här projektet, de kan göra det. Blir det inga elever så tar jag det och gör det själv på sommaren.
Och vi har många andra små problem som vi successivt jobbar på. Och några ganska konstiga saker händer.
Till exempel, om du ger WAL-G en tom säkerhetskopia, kommer den helt enkelt att falla. Till exempel, om du säger till honom att han behöver säkerhetskopiera en tom mapp. Filen pg_control kommer inte att finnas där. Och han kommer att tro att han inte förstår något. I teorin måste du i det här fallet skriva ett normalt meddelande till användaren för att förklara för honom hur man använder verktyget. Men det här är inte ens en funktion för programmering, utan en egenskap hos ett bra, begripligt språk.
Vi vet inte hur man gör offline backup. Om databasen ljuger kan vi inte säkerhetskopiera den. Men allt är väldigt enkelt här. Vi kallar backup av LSN när det startade. LSN för den underliggande basen måste läsas från kontrollfilen. Och detta är en sådan orealiserad funktion. Många säkerhetskopieringssystem kan säkerhetskopiera en underliggande databas. Och det är bekvämt.
Vi kan för närvarande inte hantera bristen på backuputrymme ordentligt. För vi jobbar oftast med stora backuper hemma. Och de kom inte fram till det. Men om någon vill programmera i Go just nu, lägg till hantering för out-of-space-fel i hinken. Jag ska definitivt undersöka pull-begäran.
Och det viktigaste som oroar oss är att vi vill ha så många docker-integreringstester som möjligt som kontrollerar olika scenarier. Just nu testar vi bara grundläggande scenarier. På varje commit, men vi vill kontrollera commit-by-commit all funktionalitet vi stödjer. I synnerhet kommer vi till exempel att ha tillräckligt med stöd för PostgreSQL 9.4-9.5. Vi stöder dem eftersom communityn stöder PostgreSQL, men vi kontrollerar inte commit-by-commit för att se till att allt inte är trasigt. Och det förefaller mig som att detta är en ganska allvarlig risk.
Vi har WAL-G som körs på mer än tusen kluster i Yandex Database Management. Och den säkerhetskopierar flera hundra terabyte data varje dag.
Vi har många TODO i vår kod. Vill du programmera, kom, vi väntar på pull-förfrågningar, vi väntar på frågor.
frågor
God kväll! Tack! Min gissning är att om du använder WAL-delta så förlitar du dig antagligen mycket på helsidesskrivningar. Och i så fall, körde du tester? Du visade en vacker graf. Hur mycket vackrare blir det om FPW stängs av?
Helsidesskrivning är aktiverat för oss, vi har inte försökt inaktivera det. Det vill säga att jag som utvecklare inte har försökt stänga av den. Systemadministratörer som har undersökt har förmodligen undersökt denna fråga. Men vi behöver FPW. Nästan ingen inaktiverar det, för annars är det omöjligt att ta en säkerhetskopia från en replik.
Tack för rapporten! Jag har två frågor. Den första frågan är vad som kommer att hända med tabellutrymmen?
Vi väntar på en pull-förfrågan. Våra databaser lever på SSD- och NMVE-diskar och vi behöver egentligen inte den här funktionen. Jag är inte redo att lägga seriös tid just nu på att göra det bra. Jag förespråkar helhjärtat att vi stöder detta. Det finns människor som stöttat det, men stöttat det på ett sätt som passar dem. De gjorde en gaffel, men de gör inte pull-förfrågningar. (Tillagt i version 0.2.13)
Och den andra frågan. Du sa redan i början att WAL-G förutsätter att det fungerar ensamt och att inga omslag behövs. Jag använder själv omslag. Varför ska de inte användas?
Vi vill att det ska vara så enkelt som en balalaika. Det betyder att du inte behöver något alls förutom en balalaika. Vi vill att systemet ska vara enkelt. Om du har funktioner som du behöver göra i ett skript, kom och berätta för oss - vi gör det i Go.
God kväll! Tack för rapporten! Vi kunde inte få WAL-G att fungera med GPG-dekryptering. Den krypterar normalt, men vill inte dekryptera. Är det något som inte fungerade för oss? Situationen är deprimerande.
Skapa ett problem på GitHub och låt oss ta reda på det.
Det vill säga, du har inte stött på detta?
Det finns en funktion i felrapporten att när WAL-G inte förstår vilken typ av fil det är frågar den: "Kanske är den krypterad?" Kanske är problemet inte kryptering alls. Jag vill förbättra loggningen i detta ämne. Han måste dechiffrera det. Vi arbetar för närvarande med detta ämne i den meningen att vi inte riktigt gillar hur systemet för att erhålla offentliga och privata nycklar är organiserat. Eftersom vi kallar extern GPG så att den ger oss sina nycklar. Och så tar vi dessa nycklar och överför dem till den interna GPG, som är öppen PGP, som är kompilerad åt oss inuti WAL-G, och där kallar vi kryptering. I detta avseende vill vi förbättra systemet och vill stödja Libsodium-kryptering (Lägg till i version 0.2.15). Naturligtvis ska avkodning fungera, låt oss ta reda på det - du behöver mer av ett symptom än ett par ord. Du kan samlas i talarens rum någon gång och titta på systemet. (PGP-kryptering utan extern GPG - v0.2.9)
Hallå! Tack för rapporten! Jag har två frågor. Jag har en konstig önskan att göra pg_basebackup och WAL-logga in två leverantörer, dvs jag vill göra ett moln och ett annat. Finns det något sätt att göra detta?
Detta finns inte nu, men det är en intressant idé.
Jag litar bara inte på en leverantör, jag vill ha samma i en annan, för säkerhets skull.
Tanken är intressant. Tekniskt sett är detta inte alls svårt att genomföra. För att förhindra att idén försvinner, kan jag be dig att göra ett problem på GitHub?
Ja visst.
Och sedan, när eleverna kommer till Google Summer of Code, kommer vi att lägga till dem i projektet så att det blir mer arbete för att få ut mer av dem.
Och den andra frågan. Det finns ett problem på GitHub. Jag tror att det redan är stängt. Det uppstår panik under återställning. Och för att besegra den gjorde du en separat sammansättning. Det är rätt i frågor. Och det finns ett alternativ att göra en variabel miljö i en tråd. Och det är därför det fungerar väldigt långsamt. Och vi stötte på det här problemet, och det har inte åtgärdats än.
Problemet är att lagringen (CEPH) av någon anledning återställer anslutningen när vi kommer till det med hög samtidighet. Vad kan man göra åt detta? Logiken för att försöka igen ser ut så här. Vi försöker ladda ner filen igen. I ett pass hade vi ett antal filer som inte laddats ner, vi kommer att göra en andra för alla som inte loggat in. Och så länge som minst en fil laddas per iteration, upprepar vi och upprepar och upprepar. Vi förbättrade logiken för ett nytt försök - exponentiell backoff. Men det är inte helt klart vad man ska göra med det faktum att anslutningen helt enkelt bryts på lagringssystemsidan. Det vill säga när vi laddar upp till en stream bryter den inte dessa kopplingar. Vad kan vi förbättra här? Vi har nätverksstrykning, vi kan begränsa varje anslutning med antalet byte den skickar. Annars vet jag inte hur jag ska hantera det faktum att objektlagring inte tillåter oss att ladda ner eller ladda ner från det parallellt.
Inget SLA? Är det inte skrivet för dem hur de låter sig plågas?
Poängen är att personer som kommer med den här frågan vanligtvis har ett eget valv. Det vill säga, ingen kommer från Amazon eller Google Cloud eller Yandex Object Storage.
Kanske är frågan inte längre för dig?
Frågan här i det här fallet spelar ingen roll för vem. Om det finns några idéer om hur man ska hantera detta, låt oss göra det i WAL-G. Men än så länge har jag inga bra idéer om hur jag ska hantera detta. Det finns vissa objektlagringar som stödjer listning av säkerhetskopior på olika sätt. Du ber dem att lista objekt, och de lägger till mapp där. WAL-G blir rädd för det här - det finns någon sorts sak här som inte är en fil, jag kan inte återställa den, vilket betyder att säkerhetskopian inte återställdes. Det vill säga att du faktiskt har ett helt återställt kluster, men det ger dig en felaktig status eftersom Object Storage returnerade en del konstig information som den inte helt förstod.
Det här är en sak som händer i Mail-molnet.
Om du kan bygga en reproduktion...
Den återges konsekvent...
Om det finns en reproduktion tror jag att vi kommer att experimentera med strategier för att försöka igen och ta reda på hur vi ska försöka igen och förstå vad molnet kräver av oss. Kanske blir det stabilt för oss på tre anslutningar och kommer inte att bryta kopplingen, då når vi försiktigt tre. För nu släpper vi anslutningen väldigt snabbt, d.v.s. om vi startade en återställning med 16 trådar, kommer det efter det första försöket att finnas 8 trådar, 4 trådar, 2 trådar och en. Och sedan drar den filen till en ström. Om det finns några magiska värden som 7,5 trådar är bäst för att pumpa, då kommer vi att uppehålla oss vid dem och försöka skapa ytterligare 7,5 trådar. Här är en idé.
Tack för rapporten! Hur ser ett komplett arbetsflöde för att arbeta med WAL-G ut? Till exempel i det dumma fallet när det inte finns något delta över sidor. Och vi tar och tar bort den första säkerhetskopian, arkiverar sedan skaftet tills vi är blå i ansiktet. Här finns, som jag förstår det, ett haveri. Vid något tillfälle behöver du göra en delta-backup av sidor, d.v.s. någon extern process driver detta eller hur händer detta?
Delta backup API är ganska enkelt. Det finns ett nummer där – max deltasteg, så heter det. Den är som standard noll. Det betyder att varje gång du gör en backup-push laddar den ner en fullständig säkerhetskopia. Om du ändrar det till ett positivt tal, till exempel 3, så tittar den på historiken för tidigare säkerhetskopior nästa gång du gör en backup-push. Han ser att du inte överskrider kedjan av 3 delta och gör ett delta.
Det vill säga, varje gång vi startar WAL-G försöker den göra en fullständig säkerhetskopia?
Nej, vi kör WAL-G och den försöker skapa ett delta om dina policyer tillåter det.
Grovt sett, om du kör den med noll varje gång, kommer den att bete sig som pg_basebackup?
Nej, det kommer fortfarande att köras snabbare eftersom det använder komprimering och parallellitet. Pg_basebackup kommer att lägga axeln bredvid dig. WAL-G förutsätter att du har arkivering konfigurerad. Och den kommer att utfärda en varning om den inte är konfigurerad.
Pg_basebackup kan köras utan axlar.
Ja, då kommer de att bete sig nästan likadant. Pg_basebackup kopierar till filsystemet. Vi har förresten en ny funktion som jag glömde nämna. Vi kan nu säkerhetskopiera till filsystemet från pg_basebackup. Jag vet inte varför detta behövs, men det finns där.
Till exempel på CephFS. Alla vill inte konfigurera objektlagring.
Ja, det var förmodligen därför de ställde en fråga om den här funktionen så att vi kunde göra det. Och vi gjorde det.
Tack för rapporten! Det är bara en fråga om kopiering till filsystemet. Stöder du nu direkt kopiering till fjärrlagring, till exempel om det finns någon hylla i datacentret eller något annat?
I den här formuleringen är detta en svår fråga. Ja, vi stöder, men den här funktionen ingår inte i någon version ännu. Det vill säga alla pre-releases stöder detta, men release-versionerna gör det inte. Denna funktion lades till i version 0.2. Det kommer definitivt att släppas snart, så snart vi fixat alla kända buggar. Men just nu kan detta bara göras i pre-release. Det finns två buggar i pre-releasen. Problem med WAL-E-återställning, vi har inte fixat det. Och i den senaste förutgåvan lades en bugg om delta-backup till. Därför rekommenderar vi alla att använda releaseversionerna. Så fort det inte finns fler buggar i pre-releasen kan vi säga att vi stödjer Google Cloud, S3-kompatibla saker och fillagring.
Hej, tack för rapporten. Som jag förstår det är WAL-G inte något slags centraliserat system som barmen? Planerar du att gå i denna riktning?
Problemet är att vi har gått bort från detta håll. WAL-G lever på basvärden, på klustervärden och på alla värdar i klustret. När vi flyttade till flera tusen kluster hade vi många bartenderinstallationer. Och varje gång något faller sönder i dem är det ett stort problem. Eftersom de behöver repareras måste du förstå vilka kluster som nu inte har säkerhetskopior. Jag planerar inte att utveckla WAL-G i riktning mot fysisk hårdvara för backupsystem. Om samhället vill ha lite funktionalitet här har jag inget emot det alls.
Vi har team som ansvarar för lagring. Och vi mår så bra att det inte är vi, att det finns speciella personer som lägger våra filer där filerna är säkra. De gör alla möjliga smarta kodningar där för att motstå förlusten av ett visst antal filer. De ansvarar för nätverkets bandbredd. När du har en bartender kan du plötsligt få reda på att små databaser med mycket trafik har samlats på samma server. Du verkar ha mycket utrymme på den, men av någon anledning passar inte allt via nätverket. Det kan bli tvärtom. Det finns många nätverk där, det finns processorkärnor, men det finns inga diskar här. Och vi tröttnade på det här behovet av att jonglera med något, och vi gick över till att datalagring är en separat tjänst, som separata speciella personer ansvarar för.
PS En ny version har släppts , där du kan använda konfigurationsfilen .walg.json, som finns i postgres hemkatalog som standard. Du kan överge bash-skript. Exempel .walg.json finns i det här numret
videor:
Källa: will.com