Begin dit jaar werd aangekondigd dat PostgreSQL 12 End-Of-Life zou gaan. Bij Topicus KeyHub is ons doel om altijd op een ondersteunde versie te zitten van de software die we gebruiken. Dit betekent dat er een migratie van PostgreSQL 12 naar PostgreSQL 16 moest plaatsvinden.
Afgelopen zomer hebben we samen met team Infra van Topicus Onderwijs plannen gemaakt om een in-place upgrade uit te voeren, met minder dan een seconde downtime in een HA-cluster. Deze geautomatiseerde aanpak is herbruikbaar voor toekomstige upgrades, zodat we eenvoudig bij kunnen blijven met nieuwe PostgreSQL-versies.
Bij Topicus KeyHub is het een belangrijk uitgangspunt dat alle onderdelen minimaal op een ondersteunde versie draaien, en zoveel mogelijk op de nieuwste versie. Dit geldt ook voor onze database.
Een major PostgreSQL-upgrade is echter niet zomaar uitgevoerd, zeker niet in een HA-cluster waar minimale downtime essentieel is. Een gebruikelijke manier om een database te upgraden, is door deze volledig offline te halen en vervolgens te migreren. Pas daarna wordt de nieuwe versie weer beschikbaar gemaakt.
Deze methode kan echter al snel leiden tot een downtime van een uur of meer, wat in een HA-cluster opzet onacceptabel is. In een HA-cluster opzet willen wij geen of enkele milliseconden downtime. Daar komt nog bij dat Topicus KeyHub bij klanten op eigen hardware draait, en de hele upgrade dus geautomatiseerd en in-place moet gebeuren omdat wij er niet zelf bij zijn.
Binnen Topicus Onderwijs waren ook de databases van ParnasSys en Somtoday aan een upgrade toe. In samenwerking met team Infra van Topicus Onderwijs hebben we een plan opgesteld op basis van logische replicatie. Door gebruik te maken van logische replicatie konden we de data uit een PostgreSQL 12-database in real-time streamen naar een PostgreSQL 16-database.
Bij standaard replicatie wordt gebruikgemaakt van een binair protocol, wat veel efficiënter is maar niet werkt tussen verschillende major versies. Logische replicatie daarentegen repliceert de data op basis van SQL-statements. Dit maakt het mogelijk om data tussen databases van verschillende versies te synchroniseren.
Na het opzetten van de replicatie hoefden we enkel de connecties van de oude database naar de nieuwe over te zetten.
Bij de upgrade in een HA-cluster halen we eerst één van de replica's offline, waarbij we onthouden tot welk punt op de tijdslijn deze replica data heeft ontvangen. Deze database wordt met de standaard PostgreSQL upgrade tooling (“pg_upgrade”) bijgewerkt van PostgreSQL 12 naar 16. Hierna starten we deze replica database weer op en werken de statistieken en indexen bij.
Nu hebben we een replica database op de normale manier geüpgraded en zijn we op het punt waarop de logische replicatie wordt ingezet om de downtime in het cluster te minimaliseren.
Vanaf de primaire database (die nog versie 12 draait) wordt logische replicatie gestart naar de PostgreSQL 16 database, waarbij we starten op het punt tot waar de replica voor de upgrade gebleven was. De gebruikers hebben ondertussen gewoon door kunnen werken, dus we moeten alle wijzigingen in de data repliceren naar de zojuist bijgewerkte database.
Zodra dit het geval is, leggen we alle connecties om naar de replica database, die hiermee de nieuwe primaire database wordt. Dit is het punt waarop de gebruikers in theorie een korte onderbreking zouden kunnen ervaren, maar deze omzet-actie gaat zo snel dat de kans klein is dat er ook maar één gebruiker iets merkt.
Na enkele milliseconden zijn de connecties omgelegd en draait KeyHub op PostgreSQL 16. De laatste stap in het proces is dan nog de andere 2 databases in het cluster te kopiëren van de nieuwe primaire database. Deze databases streamen vervolgens op de normale manier via een binair protocol vanaf de primaire database. Dit werkt verder op een vergelijkbare manier als wanneer een nieuwe server aan het cluster wordt toegevoegd.
Met deze aanpak hebben we een flexibele en herhaalbare oplossing ontwikkeld voor het upgraden van PostgreSQL-databases. Dankzij het gebruik van logische replicatie kunnen we downtime minimaliseren, zelfs in complexe HA-omgevingen.
In de toekomst blijven we deze methode inzetten om onze databases up-to-date te houden. Zo garanderen we dat Topicus KeyHub blijft draaien op een betrouwbare en moderne infrastructuur, zonder hinder voor onze gebruikers.