5 respuestas

No hagas un pg_dump simple y restore en una base de datos vacía si no quieres estar con downtime de horas - en su lugar usa pg_upgrade que corre en el mismo servidor sin necesidad de exportar/importar, o si querés migrar a otro servidor usa replicación lógica para mantener la app corriendo mientras se sincroniza. Con 50GB vas a ahorrar un montón de tiempo y estrés haciéndolo de esa forma.

¿Tu aplicación puede estar un rato sin escribir a la BD o necesitás cero downtime absoluto? Si podés parar las escrituras aunque sea 5-10 minutos, pg_upgrade es tu mejor amiga porque convierte los archivos en el mismo disco sin exportar nada, así que con 50GB te ahorrás horas. Ahora, si necesitás evitar downtime por completo, hay un truco que pocas veces mencionan: podés usar replicación lógica (logical replication) para sincronizar la BD vieja con la nueva en paralelo mientras sigue corriendo, y luego switcheás cuando esté todo al día - es un poco más complicado de configurar pero es gold si no podés parar el servicio. Eso sí, antes de cualquier cosa testealo en un ambiente de staging aunque sea con un dump de algunos GB para ver cuánto tarda en tu setup específico.

DiegoHernandez asker Podemos parar escrituras 10 minutos tranquilamente. Voy a probar pg_upgrade entonces, gracias por el dato.

¿Ya verificaste que tu versión 12 es compatible directamente con la 15, o necesitás pasar por versiones intermedias? Lo que nadie menciona es que además de pg_upgrade, deberías considerar hacer un backup completo antes de cualquier cosa, porque aunque pg_upgrade es bastante confiable, tener ese respaldo te da paz mental - especialmente con 50GB. Si sí o sí necesitás evitar downtime total, existe replicación lógica (logical replication) donde configurás una instancia secundaria con la versión 15, la sincronizás en paralelo y luego hacés failover cuando esté lista, pero eso es más complejo. La mayoría de la gente que conozco termina eligiendo pg_upgrade con una ventana de mantenimiento corta porque es lo más práctico y rápido para un volumen así.

Con 50GB tienes que ser cuidadoso pero pg_upgrade sí es la opción correcta si puedes tolerar ese downtime de 5-10 minutos. Lo que la mayoría no menciona es que PostgreSQL 12 a 15 es un salto que pg_upgrade maneja sin problemas en una única pasada, así que no necesitas versiones intermedias. Mi consejo: antes de cualquier cosa, haz un backup completo con pg_basebackup o pg_dump en paralelo (usa pg_dump con la opción -j para paralelizar, reduce bastante el tiempo), y luego sí ejecuta pg_upgrade en tu servidor de producción durante una ventana de mantenimiento. Eso sí, después del upgrade corre ANALYZE en las tablas grandes porque cambian algunas estadísticas internas y podrías tener queries lentas si no lo haces.

Mirá, si podés tolerar aunque sea 10-15 minutos de downtime, pg_upgrade es definitivamente tu camino porque hace la migración en el mismo servidor sin exportar/importar toda la data (con 50GB eso te ahorra un montón de tiempo). Lo que nadie mencionó acá es que antes de cualquier cosa, tenés que revisar si hay extensiones instaladas que no sean compatibles entre versiones, porque eso puede frenar todo el proceso a último momento y dejarte con sorpresas desagradables cuando ya estés en la conversión. Mi recomendación: hacé un backup full con pg_basebackup igual (por si acaso), testea todo en un servidor de staging primero, y después sí lanzate con pg_upgrade en producción.

Tu respuesta

Iniciar sesiónpara responder.