Den nya Hot Standby-funktionen i kommande PostgreSQL 9.0 gör det möjligt att köra frågor mot standby-noder som tidigare inte gjort annat än att köra en återställningsprocess. Två vanliga förväntningar jag har hört från användare som förutser den här funktionen är att den kommer att tillåta att antingen distribuera korta frågor över båda noderna, eller tillåta att köra långa rapporter mot standby utan att använda resurser på mastern. Dessa är båda möjliga att göra just nu, men om du inte förstår de avvägningar som är involverade i hur Hot Standby fungerar, kan det uppstå något oväntat beteende här.
Standard långvariga frågor
Ett av de traditionella problemen i en databas som använder MVCC, som PostgreSQL, är att en långvarig fråga måste hålla en resurs öppen – kallad en ögonblicksbild i den nuvarande Postgres-implementeringen – för att förhindra databasen från att ta bort data som frågan behöver för att fungera. Till exempel, bara för att en annan klient har tagit bort en rad och begått, om en redan körande fråga behöver den raden för att slutföra kan du faktiskt inte radera de fysiska diskblocken relaterade till den raden ännu. Du måste vänta tills det inte finns några öppna frågor som förväntar sig att den raden ska vara synlig.
Begränsningar för varm standby
Om du har en långvarig fråga som du vill att Hot Standby ska köra, finns det ett par typer av dåliga saker som kan hända när återställningsprocessen tillämpar uppdateringar. Dessa beskrivs i detalj i Hot Standby-dokumentationen. Vissa av dessa dåliga saker kommer att göra att frågor som körs i vänteläge avbryts av skäl som kanske inte är intuitivt uppenbara:
- En HET uppdatering eller VACUUM-relaterad uppdatering kommer för att radera något som frågan förväntar sig att vara synligt
- En B-trädradering visas
- Det finns ett låsningsproblem mellan frågan du kör och vilka lås som krävs för att uppdateringen ska kunna bearbetas.
Låssituationen är svår att hantera, men inte särskilt sannolikt att hända i praktiken så länge om du bara kör skrivskyddade frågor i vänteläge, eftersom de kommer att isoleras via MVCC. De andra två är inte svåra att stöta på. Det grundläggande att förstå är att alla UPPDATERA eller DELETE på mastern kan leda till att alla frågor i vänteläge avbryts; spelar ingen roll om ändringarna ens relaterar till vad frågan gör.
Bra, snabbt, billigt:välj två
I huvudsak finns det tre saker som folk kanske vill prioritera:
- Undvik masterbegränsning:Tillåt xids och associerade ögonblicksbilder att förflyttas obegränsat på mastern, så att VACUUM och liknande rengöring inte hålls tillbaka av vad standby-läget gör
- Obegränsade frågor:Kör frågor i vänteläge under en godtycklig tidsperiod
- Aktuell återställning:Håll återställningsprocessen i vänteläge uppdaterad med vad som händer på mastern, vilket möjliggör snabb fail-over för HA
I alla situationer med Hot Standby är det bokstavligen omöjligt att ha alla tre samtidigt. Du kan bara välja din avvägning. De avstämbara parametrarna som finns tillgängliga låter dig redan optimera ett par sätt:
- Om du inaktiverar alla dessa fördröjnings-/uppskjutningsinställningar optimerar du för alltid aktuell återställning, men då kommer du att upptäcka att det är mer sannolikt att frågor avbryts än du kan förvänta dig.
- max_standby_delay optimerar för längre frågor, på bekostnad av att hålla återställningen aktuell. Detta fördröjer tillämpningen av uppdateringar i vänteläget när en som kommer att orsaka ett problem (HOT, VACUUM, B-tree delete, etc.) visas.
- vacuum_defer_cleanup_age och vissa snapshot-hack kan introducera vissa master-begränsningar för att förbättra de andra två frågorna, men med ett svagt användargränssnitt för att göra det. vacuum_defer_cleanup_age är i enheter av transaktions-ID. Du måste ha en aning om den genomsnittliga mängden xid-churn på ditt system per tidsenhet för att vända hur folk tänker om detta problem ("skjut upp med minst 1 timme så att mina rapporter körs") till en inställning för detta värde. xid konsumtionshastighet är helt enkelt inte en vanlig eller ens rimlig sak att mäta/förutsäga. Alternativt kan du öppna en ögonblicksbild på den primära innan du startar en långvarig fråga i vänteläget. dblink föreslås i Hot Standby-dokumentationen som ett sätt att åstadkomma det. Teoretiskt kan en demon i standby-läge skrivas i användarland, som bor på den primära, för att också lösa detta problem (Simon har en grundläggande design för en). I grund och botten startar du en serie processer som var och en skaffar en ögonblicksbild och sedan sover under en period innan du släpper den. Genom att fördela hur länge de sovit kan du säkerställa att xid ögonblicksbilder aldrig flyttas framåt för snabbt på mastern. Det borde redan låta självklart hur mycket av ett fruktansvärt hack detta skulle vara.
Möjliga förbättringar
Den enda av dessa du verkligen kan göra något åt är att skärpa och förbättra gränssnittet för masterbegränsningen. Det förvandlar detta till det traditionella problemet som redan finns i databasen:en långvarig fråga håller en ögonblicksbild öppen (eller begränsar åtminstone framflyttningen av synlighetsrelaterade transaktions-ID:n) på mastern, vilket hindrar mastern från att ta bort saker som behövs för att frågan ska komplett. Du kan alternativt tänka på detta som en autotuning vacuum_defer_cleanup_age.
Frågan är hur man gör den primära respektera behoven hos långvariga frågor i vänteläge . Detta kan vara möjligt om mer information om kraven för transaktionssynlighet för vänteläget delas med mastern. Att göra den typen av utbyte skulle verkligen vara något mer lämpligt för den nya Streaming Replication-implementeringen att dela. Sättet som en enkel Hot Standby-server tillhandahålls ger ingen feedback till mastern som är lämplig för att dessa data ska utbytas, förutom metoder som det redan nämnda dblink-hacket.
Med PostgreSQL 9.0 som precis har nått en fjärde alfa-release, kan det hända att det är fortfarande dags att se några förbättringar på detta område innan 9.0-släppet. Det skulle vara trevligt att se Hot Standby och Streaming Replication verkligen integreras tillsammans på ett sätt som åstadkommer saker som ingen av dem helt kan göra på egen hand innan kodningen på den här utgåvan helt fryser.