Bör en utvecklare lagra databaser på beräkningsnoden eller lagringsnoden?

Eva Wong är teknisk skribent och händig hemmabyggare på ZimaSpace. Som tekniknörd sedan barnsben med ett brinnande intresse för hemlabb och programvara med öppen källkodspecialiserar hon sig på att göra komplexa tekniska koncept begripliga genom praktiska, praktiska guider. Eva tycker att självhosting ska vara roligt, inte avskräckande. Genom sina handledningar hjälper hon communityn att göra hårdvaruinstallationer mindre mystiska, från att bygga sin första NAS till att bemästra Docker-containrar.

Lagra som standard aktiva databasfiler på låglatent lagring nära beräkningsresurserna och använd sedan lagringsnoden för säkerhetskopior, dumpfiler, repliker och arkiv.

Den utgångspunkten ändras när lagringsnoden erbjuder en särskilt utformad blocklagringslösning med uppmätt latens, korrekta hållbarhetsgarantier och en återställningsfördel som motiverar det extra beroendet. Beslutet handlar inte bara om lokal eller nätverksbaserad kapacitet: transaktionsloggar, datafiler, säkerhetskopior, uppladdningar till applikationen och databaser för tillfälliga tester har olika skrivmönster och olika konsekvenser vid fel.

Håll databastillstånd åtskilt från dumpfiler och säkerhetskopior

Kartlägg alla databasrelaterade sökvägar innan du väljer nod. Den primära datakatalogen och transaktionsloggen är aktivt tillstånd; de kräver konsekvent skrivordning och förutsägbar latens. Logiska dumpfiler, fullständiga säkerhetskopior, arkiverade loggar, exporter och filer som laddats upp via applikationen har andra åtkomstmönster och kan ofta överföras säkert via nätverket.

Montera inte en enda NAS-resurs och lägg allt i den. Håll den aktiva databasvolymen åtskild från säkerhetskopieringsmål och stora mängder applikationsdata. Då kan du justera, övervaka, fylla, ta ögonblicksbilder av, återställa och migrera varje funktion separat, i stället för att låtsas att alla beständiga data behöver samma lagringsmedium.

För kortlivade förgreningsdatabaser eller CI-tester kan tiden för att återskapa dem vara viktigare än hållbarheten. Lägg dem på snabb lokal temporär lagring och återskapa dem från migreringar eller sanerade startdata. För en utvecklares dagliga tjänstdatabas bör ett fel på en lokal SSD betraktas som en återställningshändelse, och fjärrkopian bör vara tillräckligt aktuell för att uppfylla den angivna återställningspunkten.

Mät skrivvägen innan du väljer nod

Databasprestanda handlar om mer än sekventiell överföringshastighet. Mät latensen för synkrona transaktioner, slumpmässiga läsningar och skrivningar, ködjupet vid säkerhetskopieringstrafik och beteendet när nätverksanslutningen stannar upp. En 10GbE-länk kan överföra stora filer snabbt, men ändå tillföra latens och ytterligare en felkälla för varje transaktion.

En publicerad PostgreSQL-jämförelse visade att lokal NVMe gav lägre och mer förutsägbar latens än de testade nätverksanslutna molntjänsterna, samtidigt som den noterade nätverkslagringens fördelar vad gäller elasticitet och hållbarhet. Dessa PostgreSQL-riktmärken för lokal och nätverksansluten lagring är ingen garanti för ett hemmalabb, men de visar varför databasplacering behöver mätningar av arbetsbelastningen snarare än enbart gränssnittshastighet.

Kör ett representativt test med samma filsystem, synkroniseringsinställningar, databasversion, datamängd och samtidighet som planeras för tjänsten. Starta en stor säkerhetskopiering eller medieöverföring via lagringsnätverket under testet. Om svanslatensen eller bekräftelsetiden blir ojämn kompenserar den centrala kapaciteten inte för den delade vägen.

Placera primära databasfiler nära beräkningen som standard

För en utvecklare, en beräkningsnod och måttliga databaser ger lokala speglade SSD-enheter eller en återställningsbar lokal volym vanligtvis den tydligaste ansvarsfördelningen. Databasprocessen, dess datafiler och dess skrivförhandslogg fallerar tillsammans, medan lagringsnoden tar emot säkerhetskopior via en databasmedveten process i stället för att vara värd för ett fjärrmonterat, alltid öppet filsystem.

Lokal placering betyder inte en enda oskyddad startenhet. Separera databasvolymen från operativsystemet där det är praktiskt, övervaka ledigt utrymme och enheternas hälsa, reservera kapacitet för underhållsåtgärder och exportera säkerhetskopior före uppgraderingar. Lås fast placeringen av containrar eller virtuella maskiner så att en schemaläggare inte startar databasen på en annan nod utan dess tillstånd.

Använd endast lokal lagring när återställningsvägen är verklig. Om det krävs gissningar kring en inaktuell kopia för att ersätta beräkningsnoden kan centraliserad lagring blottlägga ett befintligt säkerhetskopieringsfel i stället för att orsaka det. Åtgärda arbetsflödet för säkerhetskopiering och återställning innan du optimerar datavägen.

Single board computer zimaboard2

Använd lagringsnoden för säkerhetskopior, repliker och arkiv

En lagringsnod är värdefull när den tar emot programkonsistenta dumpningar, basbackuper, arkiverade transaktionsloggar, oföränderliga ögonblicksbilder eller en databasreplik med ett eget återställningssyfte. Den kan också lagra stora bilagor eller analytiska exporter, medan den latenskänsliga databaskatalogen och loggarna förblir lokala.

Datafunktion Standardplats Varför Obligatoriskt test
Primärdata och transaktionslogg SSD för beräkningsnod Lägsta och mest förutsägbara skrivväg Bekräftelselatens och kraschåterställning
Logiska dumpfiler Lagringsnod Portabel återställningskälla med versionshantering Återställ till en tom databas
Grundsäkerhetskopia och arkiverade loggar Lagringsnod Återställning till en viss tidpunkt Återställ till en angiven tidpunkt
Läsreplika Valfri nod med egen volym Skalning av läsningar eller återställningsalternativ Fördröjning och procedur för uppflyttning
Uppladdningar, exporter och kall analys Lagringsnod Kapacitet är viktigare än transaktionslatens Påverkan av samtidiga överföringar

Communitytester av PostgreSQL över NFS på en lagringsserver gav kontraintuitiva resultat och konfigurationsfrågor snarare än ett universellt svar. Därför bör fjärrlagring som primär lagring ses som ett specialfall som kräver teknisk utformning: verifiera synkroniseringsbeteende, felhantering, monteringsalternativ, cachesemantik och återställning på den exakta stacken.

Verifiera felåterställning och när migrering bör ske

Testa fyra händelser: starta om databasen korrekt, krascha beräkningsnoden under skrivningar, avbryt lagringslänken under en säkerhetskopiering och återställ till en tom värd. Bekräfta återställningspunkten, återställningstiden, databasens integritetskontroller och hur programmet återansluter. Ett snabbt normalt prestandatest bevisar inte att skrivningar hanteras säkert vid avbrott.

Installationen är godkänd när aktiva data har förutsägbar latens, säkerhetskopior inte kan skriva över eller låsa den primära lagringen och en ersättningsnod för beräkning kan återställa systemet utan odokumenterade lagringsantaganden. Flytta primärfiler till en specialutvecklad lagringstjänst endast när de uppmätta fördelarna för återställning eller mobilitet väger tyngre än nätverksberoendet; flytta tillbaka dem lokalt när svanslatens eller länkavbrott blir den främsta orsaken till incidenter.

För det större arkitekturvalet hjälper ZimaSpaces jämförelse av en lagringsfokuserad NAS och en beräkningsfokuserad hemmaserver dig att avgöra vilken roll som bör förbli stabil när utvecklararbetsbelastningen förändras.

Slutlig installationsregel

Använd som standard lokal, skyddad SSD-lagring för aktiva databasfiler och använd lagringsnoden för verifierade säkerhetskopior, arkiv och utvalda repliker. Välj fjärrlagring som primär lagring först efter att du har mätt dess skrivsemantik, svanslatens, avbrottsbeteende och återställningsfördelar.

Installation av NAS och server

Mer att läsa

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.