Gör det enklare att hantera en PostgreSQL-produktionsdatabas

De senaste åren har ökat användningen av PostgreSQL. PostgreSQL är en fantastisk relationsdatabas. Funktionsmässigt är det där uppe med de bästa, om inte de bästa. Det finns många saker jag älskar med det – PL/PG SQL, smarta standardinställningar, replikering (som faktiskt fungerar direkt) och en aktiv och levande öppen källkodsgemenskap. Men utöver bara funktionerna finns det andra viktiga aspekter av en databas som måste beaktas. Om du planerar att bygga en stor 24/7-verksamhet blir möjligheten att enkelt använda databasen när den väl är i produktion en mycket viktig faktor. I denna aspekt håller PostgreSQL inte så bra. I det här blogginlägget kommer vi att beskriva några av dessa operativa utmaningar med PostgreSQL. Här finns inget som går att fixa i grunden, bara en fråga om prioritering. Förhoppningsvis kan vi skapa tillräckligt med intresse för öppen källkod för att prioritera dessa funktioner.

1. Ingen automatisk identifiering av klientdrivrutin för huvudfel

PostgreSQL-klientdrivrutinen upptäcker inte automatiskt när det har skett en master-failover (och en ny master har valts). För att komma runt detta måste administratörer distribuera ett proxylager på serversidan. De populära alternativen är DNS-mappning, virtuell IP-mappning, PgPool och HAProxy. Alla dessa alternativ kan fås att fungera bra, men det krävs en betydande extra inlärning och administratörsansträngning. I de fall där en proxy introduceras i datasökvägen finns det också en betydande prestandapåverkan. Detta är en inbyggd standardfunktion i många av de nya NoSQL-databaserna, och PostgreSQL skulle göra utmärkt för att ta ett blad ur sina böcker när det kommer till operationer.

2. Ingen inbyggd automatisk failover mellan master och standby

När en PostgreSQL-master misslyckas måste en av standby-servrarna väljas till master. Denna mekanism är inte inbyggd i PostgreSQL. Vanligtvis används mjukvaruverktyg från tredje part som Patroni, Pacemaker, etc. för att hantera detta scenario. Varför inte ha detta inbyggt i servern? Dessa tredjepartsverktyg ser bedrägligt enkla ut, men det kräver avsevärd ansträngning, kunskap och testning från administratörens sida för att få detta rätt. Genom att bygga in detta i databasen gör du en enorm tjänst för din databasadministratör.

3. Ingen större uppgradering av driftstopp

Det är inte möjligt att uppgradera din PostgreSQL-databas från en huvudversion till en annan utan driftstopp. Du måste i princip stänga av alla dina servrar och använda pg_upgrade för att uppgradera dina data till den nyare versionen. Driftstoppen är inte stor eftersom det inte finns någon datakopia inblandad, men det finns fortfarande driftstopp. Om du kör en 24/7-operation, kanske detta inte är ett alternativ för dig.

Med lanseringen av logisk replikering har vi ett alternativ för onlineuppgradering.

1. Bygg en helt ny PostgreSQL Master-Standby-inställning med den nya versionen.
2. Ställ in logisk replikering för att replikera från den äldre versionen till den nyare versionen.
3. När du är redo ändrar du din anslutningssträng så att den pekar från den äldre inställningen till den nya inställningen.

Återigen, detta kan fås att fungera, men omkostnaderna är enorma. Helst är det som behövs här ett sätt att uppgradera på plats på ett rullande sätt över en master standby-inställning. MySQL-uppgradering låter dig uppgradera dina slavar på plats till den nya versionen och sedan utlösa en failover.

4. Ingen på plats VAKUUM FULL

Autovacuum/VACUUM är mycket användbart och hjälper till att lösa problemet i viss utsträckning. Du bör regelbundet undersöka uppblåstheten på dina bord för att säkerställa att din autovakuuminställningar är lämpliga och fungerar bra för ditt bord. Autovacuum går dock inte hela vägen – det slutar faktiskt inte med att sidorna slås samman och tas bort. Om du har ett stort antal uppdateringar, infogar och tar bort arbetsbelastningar, kommer dina sidor att bli fragmenterade, vilket påverkar din prestanda. Det enda sättet runt detta är att köra VACUUM FULL som i princip kommer att bygga om alla sidor för att eliminera fragmentering. Denna process kan dock endast göras med stilleståndstid – ditt bord är nere under hela VACUUM FULL. För stora datamängder kan detta ta flera timmar och är inte ett praktiskt alternativ om du vill köra en 24/7-operation.

Obs! Gemenskapen har redan påbörjat arbetet med zheap-lagringsmotorn som övervinner denna begränsning.

Om det finns andra förbättringar som du tror skulle vara användbara, lämna gärna en kommentar.