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

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Should a Developer Keep Databases on the Compute Node or the Storage Node? - Zima Store Online

Ha aktiva databasfiler på lagring med låg latens nära beräkningsresurser som standard, och använd sedan lagringsnoden för säkerhetskopior, dumpfiler, repliker och arkiv.

Den standarden ändras när lagringsnoden tillhandahåller en medvetet konstruerad blocklagringsväg, uppmätt latens, korrekta hållbarhetssemantiker och en återställningsfördel som är värd den extra beroendeställningen. Beslutet handlar inte bara om lokal kapacitet kontra nätverkskapacitet: transaktionsloggar, datafiler, säkerhetskopior, programuppladdningar och tillfälliga testdatabaser har olika skrivmönster och konsekvenser vid fel.

Separera databasstatus från dumpfiler och säkerhetskopior

Kartlägg alla databaserelaterade sökvägar innan du väljer nod. Den primära datakatalogen och transaktionsloggen är aktiv status; de kräver konsekvent skrivordning och förutsägbar latens. Logiska dumpfiler, bassäkerhetskopior, arkiverade loggar, exporter och filer som laddats upp av program har andra åtkomstmönster och kan ofta passera nätverket säkert.

Montera inte en enda NAS-resurs och placera allt i den. Håll den aktiva databasvolymen åtskild från säkerhetskopieringsmål och stora mängder programdata. Då kan du justera, övervaka, fylla, ta ögonblicksbilder av, återställa och migrera varje roll utan att låtsas att alla beständiga byte behöver samma medium.

För kortlivade databaser för grenar eller CI-tester kan återskapandetiden vara viktigare än hållbarheten. Lägg dem på snabbt lokalt temporärt lagringsutrymme och återskapa dem från migreringar eller sanerade startdata. För en utvecklares dagliga tjänstedatabas ska ett fel på en lokal SSD behandlas som en återställningshändelse, och den fjärrbaserade kopian ska vara tillräckligt aktuell för att uppfylla den deklarerade återställningspunkten.

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

Databasprestanda beror på mer än sekventiell genomströmning. Mät latens för synkrona bekräftelser, slumpmässiga läsningar och skrivningar, ködjup under säkerhetskopieringstrafik samt beteendet när nätverksvägen stannar. En 10GbE-länk kan flytta stora filer snabbt, men ändå lägga till latens och ytterligare en felpunkt i 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-mätningar av lokal och nätverksansluten lagring är ingen garanti för ett hemmalabb, men de visar varför databasplacering behöver arbetsbelastningsmätningar och inte bara information om gränssnittets hastighet.

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

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

För en utvecklare, en beräkningsnod och måttliga databaser skapar lokala speglade SSD:er eller en återställningsbar lokal volym vanligtvis det tydligaste ägarskapet. Databasprocessen, dess datafiler och dess WAL-logg fallerar tillsammans, medan lagringsnoden tar emot säkerhetskopior genom en databasmedveten process i stället för att vara värd för ett fjärrmonterat filsystem som alltid är öppet.

Lokal placering innebär 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 container- eller VM-placeringen så att en schemaläggare inte startar databasen på en annan nod utan dess status.

Använd lokal lagring endast när återställningsvägen är verklig. Om ett byte av beräkningsnod skulle kräva gissningar kring en inaktuell kopia kan centraliserad lagring avslöja ett befintligt fel i säkerhetskopieringen i stället för att skapa det. Åtgärda arbetsflödet för säkerhetskopiering och återställning innan du optimerar datavägen.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

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 dumpfiler, bassäkerhetskopior, arkiverade transaktionsloggar, oföränderliga ögonblicksbilder eller en databasreplik med ett eget återställningssyfte. Den kan också lagra stora bilagor eller analytiska exporter, medan det latenskänsliga databaskatalogen och loggarna förblir lokala.

Dataroll	Standardplats	Varför	Nödvändigt test
Primära data och transaktionslogg	SSD i beräkningsnoden	Lägsta och mest förutsägbara skrivväg	Bekräftelselatens och kraschåterställning
Logiska dumpfiler	Lagringsnod	Portabel återställningskälla med versionsmedvetenhet	Återställ till en tom databas
Bassäkerhetskopia och arkiverade loggar	Lagringsnod	Återställning till en tidpunkt	Återställ till en angiven tidsstämpel
Läsreplik	Valfri nod med egen volym	Skalning av läsningar eller återställningsalternativ	Fördröjning och procedur för befordran
Uppladdningar, exporter och kall analysdata	Lagringsnod	Kapacitet är viktigare än transaktionslatens	Påverkan av samtidiga överföringar

Tester utförda av communityn av PostgreSQL över NFS på en lagringsserver gav kontraintuitiva resultat och konfigurationsfrågor snarare än ett universellt svar. Därför ska fjärrbaserad primärlagring behandlas som ett konstruerat undantag: validera synkroniseringsbeteende, felhantering, monteringsalternativ, cachesemantik och återställning på exakt den aktuella stacken.

Validera felåterställning och migreringsutlösaren

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, integritetskontrollerna av databasen och programmets beteende vid återanslutning. Ett snabbt normalt prestandatest bevisar inte att en avbruten skrivväg är säker.

Konfigurationen är godkänd när aktiva data har förutsägbar latens, säkerhetskopior inte kan skriva över eller låsa den primära databasen och en ersättande beräkningsnod kan återställa utan odokumenterade lagringsantaganden. Flytta primära filer till en konstruerad lagringstjänst endast när uppmätta fördelar i återställning eller mobilitet överväger nätverksberoendet; flytta tillbaka dem lokalt när svanslatens eller länkavbrott blir den dominerande incidentkällan.

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

Slutlig installationsregel

Utgå från lokal, skyddad SSD-lagring för aktiva databasfiler och använd lagringsnoden för verifierade säkerhetskopior, arkiv och utvalda repliker. Välj fjärrbaserad primärlagring först efter att du har mätt dess skrivsemantik, svanslatens, beteende vid avbrott och återställningsfördel.