Eine bestehende PostgreSQL-Datenbank zu klickops migrieren
Deine PostgreSQL-Datenbank läuft auf einer VM, einem Droplet oder einem Server im Rack, und du möchtest sie auf verwaltete Infrastruktur holen, ohne deine App umzuschreiben. Diese Anleitung zeigt den ganzen Weg: wie die Daten rüberkommen, was mit deinen Rollen und der Ownership passiert und wie du am Ende umschaltest. Alles mit dem gewohnten pg_dump und der klickops-CLI. Nichts Kompliziertes, und ausser einem kurzen Restore-Fenster keine Downtime.
Quelle → dein Rechner → klickops. Die Daten müssen nie ins offene Internet.
Welcher Weg passt: Erreicht der Cluster deine Datenbank?
Alles hängt an einer einzigen Frage, und die hat nichts mit der Grösse zu tun: Kann der klickops-Cluster übers Netzwerk eine Verbindung zu deiner Quelldatenbank aufbauen?
Eine private Adresse wie 10.x.x.x oder 192.168.x.x bedeutet „nur von meinem Rechner aus“. Das ist kein Nachteil, im Gegenteil: Für den Umzug muss deine Datenbank nie ins offene Netz.
Schau dir an, was du umziehst
Verbinde dich von einem Rechner aus, der die Quelle erreicht, und lass dir die Datenbanken auflisten, damit du genau weisst, was du kopierst. Am besten fragt psql nach dem Passwort, dann landet es nicht in deiner Shell-History.
Zurück kommen die vorhandenen Datenbanken samt Grösse, zum Beispiel eine App-Datenbank namens myapp mit ein paar hundert Megabyte. Merk dir die richtige, das ist unten deine <source-db>.
# verbindet sich mit der immer vorhandenen Wartungs-DB, nur zum Nachschauen
psql -h db.internal -U admin -d postgres -c \
"SELECT datname, pg_size_pretty(pg_database_size(datname)) AS size
FROM pg_database WHERE NOT datistemplate ORDER BY 2 DESC;"Die Daten umziehen
Leg in deinem klickops-Projekt zuerst eine verwaltete PostgreSQL-Datenbank an; die Vorgaben im Assistenten sind produktionsreif, du wählst nur die Grösse. Danach suchst du mit der CLI das Ziel und startest die Migration als eine einzige Pipe: auf der Quelle dumpen, direkt nach klickops streamen, und dort läuft der Restore im Cluster.
Du siehst den pg_restore-Fortschritt Zeile für Zeile, am Ende „Import complete“. Das Flag --skip-ownership ist standardmässig aktiv, und das ist wichtig, dazu gleich mehr.
Ist die Quelle öffentlich erreichbar? Dann sparst du dir den lokalen Dump komplett. Wähl im Reiter „Data & backups“ der Datenbank Import → From another server und füg den Connection-String der Quelle ein; klickops kopiert serverseitig, und du kannst den Browser dabei zumachen. Genau dieser Weg lohnt sich auch bei sehr grossen Datenbanken, wo ein Upload über den Browser sonst zum Flaschenhals wird.
klops databases list --project my-projectpg_dump -W --format=custom -h db.internal -U admin -d myapp \
| klops db import myapp-db --project my-project --file -Was mit Rollen und Ownership passiert
An diesem Punkt vertun sich viele, darum ganz klar: Deine Datenbank-Rollen wandern nicht mit, und das ist auch gut so. Ein pg_dump einer einzelnen Datenbank enthält gar keine Rollen, denn die gelten clusterweit, und --skip-ownership entfernt zusätzlich alle Verweise auf Ownership und Grants.
Das Ergebnis ist sauber: Jede Tabelle gehört danach der verwalteten app-Rolle von klickops, also genau der Rolle, mit der sich deine App ohnehin verbindet. Der Admin-User von deiner alten VM spielt für die neue Datenbank keine Rolle mehr. Nach dem Umzug trägst du in deiner App den Connection-String von klickops ein, mit Host, Port, Datenbank und dem User app. Das Passwort findest du im Reiter „Connect“ der Datenbank. Mehr ändert sich bei den „Usern“ nicht.
Brauchst du mehr als eine Login-Rolle, etwa einen Read-only-User fürs Reporting? Dann legst du sie in klickops als verwaltete Rolle neu an, statt sie zu importieren, und die Plattform kümmert sich um das Passwort. Für eine App mit einer einzelnen Datenbank brauchst du das nicht.
Kommt mit
- Tabellen & alle Datenzeilen
- Indexe & Constraints
- Sequences & ihre Werte
- Functions, Types, Extensions
Bleibt zurück
- Datenbank-Rollen / User
- Objekt-Ownership
- GRANTs & Privilegien
- Das alte Admin-Passwort
Wenn das Ziel nicht leer ist
Hast du deine App schon vor der Migration auf klickops deployt, hat sie wahrscheinlich ihre eigenen Migrationen ausgeführt und das Schema bereits angelegt. Ein Import obendrauf kollidiert dann beim ersten Objekt, das es schon gibt. Zwei Dinge lösen das. Erstens: Stopp die App und skalier sie auf null, damit während Drop und Reload nichts hineinschreibt, danach fährst du sie wieder hoch. Zweitens: Häng dem Import --clean an, dann droppt er jedes Objekt vor dem Neuanlegen in der richtigen Reihenfolge, und der Reload startet sauber.
pg_dump -W --format=custom -h db.internal -U admin -d myapp \
| klops db import myapp-db --project my-project --file - --cleanPrüfen und umschalten
Vergleich ein paar Zeilenzahlen mit der Quelle, damit du sicher bist, dass alles angekommen ist. Stimmen die Zahlen, schaltest du um: Trag in deiner App die app-Zugangsdaten von klickops aus dem vorherigen Abschnitt ein und starte sie wieder. Sie verbindet sich mit der gefüllten Datenbank, fertig.
Noch ein Hinweis zu einer sehr grossen Tabelle: Ein Upload über den Browser ist gedeckelt, und eine einzelne riesige Tabelle kann lange laufen. Bei Datenbanken jenseits von ein paar Gigabyte nimmst du besser die serverseitige Kopie „From another server“ (wenn erreichbar) oder einen Port-Forward mit lokalem pg_restore. Beide schieben die Daten als durchgehenden Stream, ohne Upload-Limit.
klops db query myapp-db --project my-project -- \
"SELECT count(*) FROM users;"Bereit für Schweizer Infrastruktur?
Private Beta, Gratis-Plan für einen kleinen Stack, keine Karte nötig.