Att reda ut PostgreSQL-uppgraderingen

PostgreSQL 9.6 har precis släppts och de flesta av postgres-användarna kommer att börja fråga sig själva hur man uppgraderar till den nya huvudversionen. Detta inlägg har för avsikt att visa olika procedurer för att uppgradera din PostgreSQL-server.

Att uppgradera till en ny huvudversion är en uppgift som har ett högt förhållande mellan förberedelser och total körningstid. Specifikt när du hoppar över en version i mitten, till exempel när du hoppar från version 9.3 till version 9.5.

Punktsläpp

Å andra sidan behöver uppgraderingar av punktsläpp inte lika mycket förberedelser. I allmänhet är det enda kravet att postgres-tjänsten ska startas om. Det finns inga ändringar i den underliggande datastrukturen, så det finns inget behov av att dumpa och återställa. I värsta fall kan du behöva återskapa några av dina index efter att du har uppgraderat punktversionen.

Det är mycket klokt att alltid stanna kvar på den senaste punktutgåvan, så att du inte snubblar över en känd (och troligen fixad) bugg. Detta innebär att när den senaste versionen är ute, schemalägg tid för uppgraderingen så snart som möjligt.

Större versionsuppgradering

När du gör komplexa uppgifter som den här är det bra att överväga alla möjliga alternativ för att uppnå det slutliga resultatet.

För större versionsuppgraderingar finns det tre möjliga vägar du kan ta:

• Uppgradera återställning från en logisk dump
• Fysisk uppgradering
• Online-uppgradering

Låt mig förklara var och en i detalj:

1) Uppgradera återställning från en logisk dump

Detta är det enklaste av alla möjliga sätt att uppgradera ditt klusters datastruktur.

För att göra det kort kräver processen här en logisk dump med pg_dump från den gamla versionen och pg_restore på ett rent kluster skapat med den nyinstallerade versionen.

Nyckelpunkter för att använda den här sökvägen är:

• Det är det mest testade
• Kompatibiliteten går tillbaka till 7.0-versioner så att du så småningom kan uppgradera från 7.x till en av de senaste versionerna

Skäl till varför du bör undvika att använda det här alternativet:

• Den totala stilleståndstiden på stora databaser kan vara ett problem, eftersom du måste stoppa skrivanslutningar innan du börjar köra pg_dump;
• Om det finns många stora objekt i databasen kommer pg_dump att vara långsam. Även när man gör det parallellt. Återställning kommer att gå ännu långsammare än pg_dump när många stora objekt lagras i databasen;
• Det kräver dubbelt diskutrymme eller borttagning av det gamla klustret innan det återställs;

På servrar med flera CPU-kärnor är det möjligt att köra pg_dump parallellt med katalogformatet. När det är klart återställer du också parallellt med -j-växeln i både pg_dump och pg_restore. Men du kan inte starta återställningsprocessen förrän hela dumpningen är klar.

2) Fysisk uppgradering

Den här typen av uppgraderingar har varit tillgängliga sedan version 9.0 för att utföra uppgraderingar på plats från versioner så gamla som 8.3. De kallas "på plats" eftersom de görs på samma server och helst på samma datakatalog.

Fördelar med den här typen av uppgraderingar:

• Du behöver inte utrymme för ytterligare en kopia av klustret.
• Nedtid är mycket lägre jämfört med att använda pg_dump.

Det finns en hel del nackdelar:

• När du startar den nya versionen av PostgreSQL går det inte att gå tillbaka till den gamla versionen (klustret fungerar bara med den nya versionen därifrån).
• Statistiken nollställs efter uppgraderingen, så direkt efter att den nya versionen av PostgreSQL har startat måste en klusteromfattande analys utföras.
• Det har hittats många buggar de senaste åren angående pg_upgrade, vilket gör att vissa databasadministratörer är ovilliga att använda den här metoden för att uppgradera.
• Vissa personer har haft problem med att hoppa över en större version, till exempel att gå från version 9.2 till version 9.4.
• Med stora kataloger kommer det att fungera dåligt (kluster med många databaser eller databaser med många tusen objekt).

Du kan också köra pg_upgrade utan alternativet –link (i det här fallet genererar pg_upgrade en andra kopia på disken av ditt kluster) så att du kan gå tillbaka till den gamla versionen. Men du kommer att förlora båda fördelarna som anges ovan.

3) Uppgradering online

Proceduren att följa för denna metod skulle vara så här:

1. Installera båda versionerna så att du kan få dem att fungera parallellt. Detta kan göras på samma server eller med två fysiska servrar.
2. Skapa en initial kopia och replikera ändringarna från det ögonblick du startade kopian på källnoden (detta skulle likna en initial pg_dump).
3. Fortsätt att replikera logiskt ändringarna tills fördröjningen är nära noll.
4. Återpeka anslutningsinformationen från applikationsservern för att ansluta till den nya servern.

Denna typ av uppgradering har varit tillgänglig sedan de första triggerbaserade replikeringslösningarna fanns. Med andra ord, sedan Slony-I var där.

Triggerbaserade replikeringslösningar bryr sig inte om vilken version du har på den ena eller andra sidan, eftersom de kopierar ändringarna med hjälp av SQL-kommandon som stöds.

De triggerbaserade replikeringsverktygen som rekommenderas, i den ordning de visas är:

1. skytools:PgQ + londiste
2. Slony-I

Detta bör vara det bästa sättet att uppgradera. Låt oss se fördelarna med att använda den här metoden:

• Noll driftstopp!
• Utmärkt för att uppgradera till nyare hårdvara också.
• Onlinetestning av klustret med den nya versionen (skrivskyddade frågor, annars kan du få konflikter).
• Reducerar drastiskt alla tabell- och indexuppsvällningar.

Det finns några nackdelar:

• Den behöver dubbelt lagringsutrymme, eftersom den måste lagra en andra kopia av dina data.
• Eftersom det är baserat på utlösare måste systemet skriva varje ändring två gånger, vilket innebär att det kommer mer disk I/O på källservern (gammal version av klustret).
• Alla tabeller måste ha en primärnyckel, så replikeringsverktyget kan individualisera de tupler som uppdateras eller tas bort
• Den replikerar inte katalogtabeller, så den replikerar inte stora objekt.
• Grundläggande användning omfattar inte schemaändringar. Det kan göras, men inte öppet.

En ny gräns med pglogical

Sedan PostgreSQL 9.4 har vi logisk avkodning av transaktionsloggarna. Det betyder att vi nu kan avkoda transaktionerna från WAL och manipulera utdata.

En helt ny värld av möjligheter dök upp i replikeringsfältet. Utlösare är inte längre nödvändiga för att åstadkomma logisk replikering!

Detta betyder i princip att du inte behöver spara en separat kopia av alla infogningar, uppdateringar och raderingar med utlösare längre. Du kan bara få dessa datamanipuleringsoperationer från transaktionsloggarna genom att avkoda dem. Sedan är det verktyget du använder som måste manipulera utdata och skicka det till den prenumererade nedströmsnoden. I det här fallet är verktyget pglogiskt.

Så, vad betyder allt detta?

Tja, om du använder en version 9.4 eller 9.5 av PostgreSQL och du vill uppgradera till 9.6, kan du utföra en onlineuppgradering som den som beskrivs ovan, men med pglogical istället för en av de triggerbaserade replikeringslösningarna.

Jag kommer inte gå närmare in på detaljer eftersom det finns andra bloggar om just detta ämne, som den här skriven av Petr Jelinek:PGLogical 1.1-paket för PostgreSQL 9.6beta1

Slutsatser

Beroende på schemat för din databas, datastorleken, eventuellt nedläggningstidsfönster, version av den aktuella PostgreSQL-installationen kan du välja ett alternativ framför ett annat eller vad som passar bäst.

• Om din databas är liten och det finns ett lämpligt underhållsfönster du kan använda, kan du välja att köra en pg_dump och pg_restore. Beroende på storleken på datamängden finns det en punkt där alternativet inte längre är genomförbart.
• Om du har en stor databas (flera hundratals GB, eller till och med TB med data) måste du leta efter andra alternativ som en platsuppgradering med pg_upgrade eller en onlineuppgradering.
  • Om du uppgraderar från version 8.3 eller senare till någon 9.x-version kan du använda pg_upgrade.
  • För versioner äldre än 8.3 måste du välja en av de logiska replikeringslösningarna som londiste eller slony.
  • Om du använder en 9.4- eller 9.5-databas är det bättre att använda pglogical.

Kom alltid ihåg att för logisk replikering måste tabellerna ha en primärnyckel.

Med pglogical är den regeln inte så strikt:Du kan replikera tabeller som endast infogas. Men för uppdatering och borttagning är det fortfarande obligatoriskt att ha en primärnyckel eller en REPLICA IDENTITET på bordet.

Om du behöver hjälp med att uppgradera din PostgreSQL-databas kan du kolla
2ndQuadrant Upgrade-tjänsterna.