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-runDe 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 41Die 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 offTussen 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 ziet | wat er staat | wat je doet |
|---|---|---|
| De opdracht weigert meteen | Niets is gestopt, niets geïnstalleerd | Lees de reden; meestal bestaat de doelversie al op deze server |
| De verhuizing zelf faalt | De oude versie draait weer, de instelling is niet veranderd | Kijk in /var/log/postgresql/; je server draait ondertussen door |
| De tellingen kloppen niet | Terug op de oude versie, en die draait | De opdracht noemt de tabel en beide getallen |
| Later blijkt iets stuk | De nieuwe draait, de oude staat gestopt klaar | Zet 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> mainWeet 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.