@@PRODUCT@@

De eigen database van een server verhuizen

Elke server houdt een eigen kleine database bij, los van die van je klanten. Daar staan twee dingen in: waar de e-mail van dat account heen moet, en welke DNS-records de server uitserveert. Die database draait op PostgreSQL en heeft één kee

Geschreven voor: Beheerder

Elke server houdt een eigen kleine database bij, los van die van je klanten. Daar staan twee dingen in: waar de e-mail van dat account heen moet, en welke DNS-records de server uitserveert. Die database draait op PostgreSQL en heeft één keer in de zoveel jaar aandacht nodig — precies zoals hieronder.

Dit gaat niet over de databases van je klanten. Die draaien op MariaDB of MySQL en verhuizen op een andere manier; zie Waar een website draait.

Waarom dit een handeling is en geen update

Ubuntu levert precies één PostgreSQL-hoofdversie voor de hele levensduur van de uitgave. PostgreSQL zelf ondersteunt een hoofdversie vijf jaar. Reken dat door en er komt een dag waarop je server een database draait waar niemand nog lekken in dicht, terwijl Ubuntu geen andere aanbiedt.

Een hoofdversie verhuist ook niet mee met een gewone update, en dat is met opzet: PostgreSQL schrijft zijn gegevens per hoofdversie in een eigen indeling. Een update zet de nieuwe versie ernáást neer en laat je gegevens staan. Ze verplaatsen is een beslissing, en die neem jij.

Wat je ziet voordat je iets doet

Vraag eerst wat er staat. Er verandert niets van kijken:

corectl node store status
corectl node store upgrade 19 --dry-run

De eerste regel zegt welke hoofdversie deze server nu draait. De tweede telt elke tabel en laat zien wat er zou gebeuren:

NODE STORE UPGRADE (dry run) — PostgreSQL 18 -> 19
  corecp_dns.domains                        3
  corecp_dns.records                      120
  corecp_mail.mailboxes                    41

Die tellingen zijn waar je straks tegen vergelijkt. Ze worden ook automatisch vergeleken — daarover zo meer — maar het is prettig om ze zelf gezien te hebben.

De verhuizing zelf

Zet de server eerst in onderhoudsmodus, zodat de meldingen gedempt zijn en er vooraf een momentopname wordt gemaakt:

corectl node maintenance-mode on --reason "PostgreSQL 18 -> 19"
corectl node store upgrade 19
corectl node maintenance-mode off

Tussen die twee regels gebeurt dit, in deze volgorde: de nieuwe versie wordt geïnstalleerd náást de oude, de mail- en DNS-diensten worden even gestopt, de gegevens verhuizen met het gereedschap van PostgreSQL zelf, de instellingen van CoreCP worden voor de nieuwe versie geschreven, elke tabel wordt opnieuw geteld, en de diensten starten weer.

Reken op een kwartier. De eigen database van een server is klein — op de testomgeving een paar tientallen megabytes — maar de e-mail en de DNS van díe server staan tijdens de verhuizing even stil.

De telling is de goedkeuring

Dit is het stuk dat het verschil maakt met "het leek te werken". De serverinstelling verhuist alleen mee als élke tabel op beide versies evenveel rijen telt. Niet "het cluster start", niet "het gereedschap gaf nul terug": een verhuizing die stilletjes een tabel kwijtraakt is niet van een geslaagde te onderscheiden tot de e-mail van iemand niet meer aankomt, en dat is precies wat niemand tussendoor opmerkt.

Klopt de telling niet, dan zet de opdracht de server terug op de oude versie, start die weer, en noemt de tabel en beide getallen.

Als er iets misgaat

De oude database blijft staan — gestopt, compleet, op schijf. Dat is de weg terug en het kost een kopie van enkele tientallen megabytes.

wat je zietwat er staatwat je doet
De opdracht weigert meteenNiets is gestopt, niets geïnstalleerdLees de reden; meestal bestaat de doelversie al op deze server
De verhuizing zelf faaltDe oude versie draait weer, de instelling is niet veranderdKijk in /var/log/postgresql/; je server draait ondertussen door
De tellingen kloppen nietTerug op de oude versie, en die draaitDe opdracht noemt de tabel en beide getallen
Later blijkt iets stukDe nieuwe draait, de oude staat gestopt klaarZet de nieuwe stil, de instelling terug op de oude versie, en start de oude

De oude opruimen

Niet meteen. Laat hem een paar weken staan; hij is je weg terug en kost bijna niets. Daarna:

pg_dropcluster <oude-versie> main

Weet je nu al dat je hem niet wilt bewaren, dan kan --drop-old mee bij de verhuizing zelf.

Vanaf de terminal

Alles hierboven is terminalwerk; er is geen scherm voor. Dat is met opzet: het is een handeling met een onderhoudsvenster eromheen, geen knop waar je per ongeluk op drukt. Wat het paneel wél laat zien is het resultaat — op de pagina van de server staat welke versie zijn eigen database draait.

Het volledige draaiboek, inclusief wat je vooraf wilt hebben liggen, staat in docs/operations/postgresql-hoofdversie.md.