De PostgreSQL-upgrade ontwarren

PostgreSQL 9.6 is zojuist uitgebracht en de meeste gebruikers van postgres zullen zich afvragen hoe ze kunnen upgraden naar de nieuwe hoofdversie. Dit bericht is bedoeld om verschillende procedures te tonen voor het upgraden van uw PostgreSQL-server.

Het upgraden naar een nieuwe hoofdversie is een taak met een hoge verhouding tussen voorbereiding en totale uitvoeringstijd. Zeker als je halverwege een release overslaat, bijvoorbeeld als je van versie 9.3 naar versie 9.5 springt.

Punten vrijgeven

Aan de andere kant hebben upgrades voor puntreleases niet zoveel voorbereiding nodig. Over het algemeen is de enige vereiste dat de postgres-service opnieuw wordt gestart. Er zijn geen wijzigingen in de onderliggende gegevensstructuur, dus dumpen en herstellen is niet nodig. In het ergste geval moet u mogelijk enkele van uw indexen opnieuw maken nadat u klaar bent met het upgraden van de puntrelease.

Het is heel verstandig om altijd bij de laatste puntrelease te blijven, zodat je niet struikelt over een bekende (en waarschijnlijk opgeloste) bug. Dit betekent dat zodra de nieuwste versie uit is, zo snel mogelijk tijd voor de upgrade moet plannen.

Belangrijke release-upgrade

Bij het uitvoeren van complexe taken zoals deze, is het goed om alle mogelijke opties te overwegen om het uiteindelijke resultaat te bereiken.

Voor grote release-upgrades zijn er drie mogelijke paden:

• Upgrade herstellen vanaf een logische dump
• Fysieke upgrade
• Online upgrade

Laat me ze allemaal in detail uitleggen:

1) Upgrade herstellen vanaf een logische dump

Dit is de eenvoudigste van alle mogelijke manieren om de gegevensstructuur van uw cluster te upgraden.

Om het kort te maken, vereist het proces hier een logische dump met pg_dump van de oude versie, en pg_restore op een schoon cluster gemaakt met de nieuw geïnstalleerde versie.

Belangrijke punten ten gunste van het gebruik van dit pad zijn:

• Het is het meest getest
• Compatibiliteit gaat terug naar 7.0-versies, dus je zou uiteindelijk kunnen upgraden van 7.x naar een van de recente releases

Redenen waarom u deze optie zou moeten vermijden:

• De totale uitvaltijd van grote databases kan een probleem zijn, omdat u de schrijfverbindingen moet stoppen voordat u pg_dump gaat uitvoeren;
• Als er veel grote objecten in de database staan, zal pg_dump traag zijn. Ook als je het parallel doet. Herstellen gaat zelfs langzamer dan pg_dump als er veel grote objecten in de database zijn opgeslagen;
• Het vereist dubbele schijfruimte of het verwijderen van het oude cluster voordat het kan worden hersteld;

Op servers met meerdere CPU-cores is het mogelijk om pg_dump parallel uit te voeren met behulp van de directory-indeling. Als het klaar is, herstelt u het ook parallel, met behulp van de -j-schakelaar in zowel pg_dump als pg_restore. Maar je kunt het herstelproces pas starten als de hele dump is voltooid.

2) Fysieke upgrade

Dit soort upgrades zijn beschikbaar sinds versie 9.0 om interne upgrades uit te voeren vanaf versies zo oud als 8.3. Ze worden "in-place" genoemd omdat ze via dezelfde server worden gedaan, en bij voorkeur in dezelfde gegevensmap.

Voordelen van dit soort upgrades:

• Je hebt geen ruimte nodig voor een ander exemplaar van het cluster.
• De uitvaltijd is veel lager in vergelijking met het gebruik van pg_dump.

Er zijn nogal wat nadelen:

• Zodra u de nieuwe versie van PostgreSQL start, kunt u niet meer terug naar de oude versie (cluster werkt vanaf dat moment alleen met de nieuwe versie).
• Statistieken worden na de upgrade op nul gezet, dus direct na het starten van de nieuwe versie van PostgreSQL moet een clusterbrede analyse worden uitgevoerd.
• Er zijn de afgelopen jaren veel bugs gevonden met betrekking tot pg_upgrade, waardoor sommige databasebeheerders terughoudend zijn om deze methode voor het upgraden te gebruiken.
• Sommige mensen hebben problemen gehad bij het overslaan van een grote release, bijvoorbeeld van versie 9.2 naar versie 9.4.
• Bij grote catalogi zal het slecht presteren (clusters met veel databases of databases met vele duizenden objecten).

U kunt pg_upgrade ook uitvoeren zonder de optie –link (in dit geval genereert pg_upgrade een tweede kopie op schijf van uw cluster), zodat u terug kunt gaan naar de oude versie. Maar u verliest beide bovengenoemde voordelen.

3) Online upgrade

De te volgen procedure voor deze methode ziet er als volgt uit:

1. Installeer beide versies zodat u ze parallel kunt laten werken. Dit kan op dezelfde server of met twee fysieke servers.
2. Maak een eerste kopie en repliceer de wijzigingen vanaf het moment dat u de kopie startte op het bronknooppunt (dit zou vergelijkbaar zijn met een eerste pg_dump).
3. Blijf de wijzigingen logisch repliceren totdat de vertraging bijna nul is.
4. Verwijs de verbindingsinformatie van de applicatieserver opnieuw om verbinding te maken met de nieuwe server.

Dit type upgrade is beschikbaar sinds de eerste op triggers gebaseerde replicatieoplossingen beschikbaar waren. Met andere woorden, sinds Slony-I in de buurt was.

Op triggers gebaseerde replicatie-oplossingen maakt het niet uit welke versie je aan de ene of de andere kant hebt, omdat het de wijzigingen kopieert met ondersteunde SQL-commando's.

De op triggers gebaseerde replicatietools die worden aanbevolen, in de volgorde waarin ze worden weergegeven, zijn:

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

Dit zou de beste manier moeten zijn om te upgraden. Laten we eens kijken wat de voordelen zijn van het gebruik van deze methode:

• Geen uitvaltijd!
• Ook geschikt voor het upgraden naar nieuwere hardware.
• Online testen van het cluster met de nieuwe versie (alleen-lezen query's, anders kunnen er conflicten ontstaan).
• Vermindert drastisch alle tabel- en indexbloats.

Er zijn enkele nadelen:

• Het heeft dubbele opslagruimte nodig, omdat het een tweede kopie van je gegevens moet opslaan.
• Omdat het gebaseerd is op triggers, moet het systeem elke wijziging twee keer schrijven, wat betekent dat er meer schijf-I/O op de bronserver (oude versie van het cluster) zal komen.
• Alle tabellen moeten een primaire sleutel hebben, zodat de replicatietool de tuples kan individualiseren die worden bijgewerkt of verwijderd
• Het repliceert geen catalogustabellen, dus het zal geen grote objecten repliceren.
• Basisgebruik dekt geen schemawijzigingen. Het kan wel, maar niet transparant.

Een nieuwe grens met pglogisch

Sinds PostgreSQL 9.4 hebben we logische decodering van de transactielogboeken. Dit betekent dat we nu de transacties van de WAL kunnen decoderen en de uitvoer kunnen manipuleren.

Er verscheen een hele nieuwe wereld van mogelijkheden op het gebied van replicatie. Triggers zijn niet langer nodig om logische replicatie tot stand te brengen!

Dit betekent in feite dat u geen afzonderlijke kopie meer hoeft op te slaan van alle invoegingen, updates en verwijderingen met behulp van triggers. U kunt die bewerkingen voor gegevensmanipulatie gewoon uit de transactielogboeken halen door deze te decoderen. Vervolgens is het de tool die u gebruikt die de uitvoer moet manipuleren en naar het geabonneerde downstream-knooppunt moet sturen. In dit geval is die tool pglogisch.

Dus, wat betekent dit allemaal?

Welnu, als u versie 9.4 of 9.5 van PostgreSQL gebruikt en u wilt upgraden naar 9.6, kunt u een online upgrade uitvoeren zoals hierboven beschreven, maar met pglogical in plaats van een van de triggergebaseerde replicatieoplossingen.

Ik zal niet verder in details treden omdat er andere blogs over dit specifieke onderwerp zijn, zoals deze geschreven door Petr Jelinek:PGLogical 1.1-pakketten voor PostgreSQL 9.6beta1

Conclusies

Afhankelijk van het schema van uw database, de gegevensgrootte, mogelijke uitvaltijd, versie van de huidige PostgreSQL-installatie, kunt u de ene optie boven de andere kiezen of wat het beste past.

• Als uw database klein is en er een geschikt onderhoudsvenster is dat u kunt gebruiken, kunt u ervoor kiezen om een ​​pg_dump en pg_restore uit te voeren. Afhankelijk van de grootte van de dataset is er een punt waarop de optie niet meer haalbaar is.
• Als je een grote database hebt (enkele honderden GB's of zelfs TB's aan gegevens), moet je naar andere opties zoeken, zoals een interne upgrade met pg_upgrade of een online upgrade.
  • Als u een upgrade uitvoert van versie 8.3 of hoger naar een 9.x-versie, kunt u pg_upgrade gebruiken.
  • Voor versies ouder dan 8.3 moet je kiezen voor een van de logische replicatie-oplossingen zoals londiste of slony.
  • Als je op een 9.4 of 9.5 database zit, kun je beter pglogical gebruiken.

Onthoud altijd dat voor logische replicatie de tabellen een primaire sleutel moeten hebben.

Met pglogical is die regel niet zo streng:je kunt tabellen die alleen invoegen zijn repliceren. Maar voor updates en verwijderingen is het nog steeds verplicht om een ​​primaire sleutel of een REPLICA IDENTITEIT op tafel te hebben.

Als u hulp nodig heeft bij het upgraden van uw PostgreSQL-database, kunt u de
2ndQuadrant Upgrade-services raadplegen.