Migrar PostgreSQL local a una base de dades gestionada

Migrar una base de dades no és només copiar-ne les files. El servidor de destinació ha d’admetre l’esquema i les extensions d’origen, l’aplicació s’hi ha de connectar de manera segura i cal tenir una manera provada de tornar enrere si les comprovacions fallen. Aquesta guia explica com traslladar una base PostgreSQL des del teu ordinador o un servidor que administres fins a un servei gestionat. No tracta de canviar els models de Prisma ni d’executar una migració d’esquema: per a això tens la guia de migracions Prisma en producció.

Decideix qui administrarà PostgreSQL

Una base gestionada et pot estalviar instal·lar i actualitzar PostgreSQL, mantenir-ne el servidor i organitzar les còpies de rutina. Un VPS et dona més control del sistema, la configuració i les extensions, però també n’assumeixes les actualitzacions, els permisos, la monitorització, les còpies i les proves de restauració. Hostbrid ofereix bases de dades gestionades i VPS Cloud; això no vol dir que qualsevol aplicació o extensió sigui compatible amb totes dues opcions.

L’oferta pública de Hostbrid inclou PostgreSQL, MariaDB i Redis. Hi descriu còpies diàries i, al pla DB-HA, tres rèpliques PostgreSQL amb commutació automàtica. També especifica que una base no té IP pública per defecte i que s’hi accedeix des de serveis compatibles del compte; per entrar-hi des de fora cal autoritzar una IP. Consulta les prestacions i els límits actuals abans de crear la destinació. Una còpia diària és útil, però no demostra que hagis provat la teva restauració ni garanteix que l’aplicació canviï de servidor sense ajustos.

Mantén PostgreSQL en un VPS si necessites accés de superusuari, extensions o paràmetres que el pla gestionat no ofereix, o un model de desplegament que el producte no admet. Tria l’opció gestionada només després de comprovar la versió principal, les extensions disponibles, l’emmagatzematge, el límit de connexions i la ruta de xarxa autoritzada. La pàgina del producte descriu les prestacions comercials vigents; la documentació de PostgreSQL explica les eines d’exportació i restauració.

Fes inventari abans d’exportar

Anota la versió principal de PostgreSQL d’origen, la mida de la base, la codificació, la col·lació, les extensions instal·lades i els rols de l’aplicació. Consulta les extensions amb aquesta ordre SQL:

SELECT extname, extversion FROM pg_extension ORDER BY extname;

Confirma que cada extensió necessària existeixi a la destinació. Revisa propietaris, permisos, polítiques de seguretat per fila, seqüències, objectes grans i tasques programades. pg_dump exporta una base; no inclou automàticament tots els rols del clúster ni cada paràmetre del servidor. Si l’aplicació en depèn, planifica una equivalència explícita a la destinació en lloc de restaurar el clúster d’origen sense revisar-lo. No traslladis dades que no tinguis autorització per moure i, quan puguis, comença amb una mostra anonimitzada.

Crea la base de destinació i comprova que t’hi pots connectar abans de restaurar. A Hostbrid, consulta al panell l’host, el port, el nom de la base, l’usuari i les instruccions TLS. Per defecte el servei no accepta connexions públiques arbitràries. Fes la migració des d’un recurs autoritzat a connectar-s’hi o demana l’accés temporal més limitat que permeti el producte des d’una adreça de confiança. No obris PostgreSQL a tot Internet. Retira l’accés temporal de l’ordinador quan acabis.

Fes servir un client PostgreSQL capaç de llegir la versió del servidor d’origen i compatible amb la destinació. La referència oficial de pg_dump explica la compatibilitat: s’espera que un bolcat es pugui carregar en versions de servidor posteriors, però un client d’una versió principal més nova no és una tria segura per restaurar en un servidor anterior. Comprova la combinació concreta; no donis per fet que saltar de versió no té conseqüències.

Crea un arxiu protegit i restaura en una base buida

Desa les credencials d’origen i destinació en un fitxer de contrasenyes libpq amb permisos restringits o en un gestor de secrets. No escriguis les contrasenyes a l’historial del terminal, als registres ni a Git. Si fas servir .pgpass, deixa’l accessible només per al propietari (0600). Segueix el mode TLS i la comprovació de certificats que indica el servei de destinació; no desactivis la verificació per resoldre una connexió que falla.

Amb l’host, el port, la base i l’usuari d’origen disponibles per al client, crea un arxiu de format personalitzat:

pg_dump --format=custom --host="$SOURCE_HOST" --port="$SOURCE_PORT" \
  --username="$SOURCE_USER" \
  --dbname="$SOURCE_DB" --file=before-migration.dump
pg_restore --list before-migration.dump

pg_dump es connecta a una base i crea una exportació lògica coherent mentre el servidor continua actiu. El format personalitzat permet inspeccionar l’arxiu i restaurar objectes concrets. En aquest exemple, --no-owner --no-acl a la restauració evita arrossegar a la nova base els propietaris i permisos del servidor anterior; els objectes s’assignen a l’usuari de destinació. Com que els permisos canvien, comprova explícitament el rol de l’aplicació i els seus permisos. Si necessites conservar propietaris o rols de clúster, defineix aquesta part amb qui administra la base.

Crea una base buida de destinació amb les extensions requerides i restaura-hi l’arxiu:

pg_restore --exit-on-error --no-owner --no-acl \
  --host="$TARGET_HOST" --port="$TARGET_PORT" --username="$TARGET_USER" \
  --dbname="$TARGET_DB" before-migration.dump

No afegeixis --clean a una restauració de producció només per amagar errors: pot eliminar objectes. Restaura primer en una base buida i atura’t si pg_restore informa d’errors. La referència oficial de pg_restore explica les opcions de l’arxiu i com s’informen les fallades. Mantén el bolcat xifrat i protegit fins que hagis validat el destí; després aplica la política de conservació i eliminació.

Valida les dades abans de canviar l’aplicació

Compara la llista de taules i els recomptes aproximats de les més importants. Revisa restriccions, índexs, seqüències, permisos, zona horària i alguns valors amb accents o dades binàries. En un entorn de prova, connecta-hi l’aplicació i comprova l’inici de sessió, les escriptures, les tasques de fons i les referències a fitxers. El bolcat no trasllada fitxers que els usuaris hagin pujat, emmagatzematge d’objectes, dades de memòria cau Redis, correu, variables d’entorn ni integracions externes.

Per a una base de desenvolupament sense escriptures de producció pot ser suficient una exportació. En un servei actiu, planifica una finestra de manteniment: posa l’aplicació en mode de només lectura o manteniment, atura tots els processos que escriuen i les tasques, fes el bolcat final, restaura’l i canvia l’únic DATABASE_URL o secret equivalent. És una migració planificada, no una promesa de zero interrupcions. Fes una prova funcional abans de tornar a permetre escriptures. No deixis que totes dues bases acceptin escriptures si no tens replicació i una estratègia de conflictes provades.

Conserva l’origen intacte i en només lectura fins que el destí hagi superat les comprovacions. Si tornes enrere després que els usuaris hagin escrit a la base nova, aquests canvis no seran a l’origen. Decideix abans de la migració si acceptaries perdre les escriptures recents, les tornaries a reproduir o mantindries el servei en manteniment per reconciliar les dades. Una còpia només queda verificada quan n’has provat la restauració.

Després del canvi, observa els errors de connexió i l’ús de connexions i espai. Canvia les credencials si l’arxiu o l’accés temporal podrien haver quedat exposats. Les modificacions d’esquema posteriors són una altra feina; consulta la llista Prisma de migracions. Si el servei gestionat compleix els requisits de xarxa i extensions, compara les bases de dades Hostbrid. Si necessites administrar tu el servidor, revisa els plans VPS. Pregunta els dubtes de compatibilitat abans de moure dades de producció.