Básicamente, existen tres formas de actualizar PostgreSQL desde diferentes versiones principales (por ejemplo, 9.1 a 9.3).
Actualización con pg_dump
El primero, y recomendado si es posible, es hacer un volcado de la versión anterior (9.1) utilizando el binario de la versión más reciente (9.3) y restaurarlo en un nuevo clúster creado con la versión más reciente.
Este enfoque es, en general, el más lento, pero también el más factible. Un consejo para hacerlo más rápido es usar la concurrencia. Para volcar con trabajos paralelos, puede hacer:
$ pg_dump --format=directory --jobs=4 --no-synchronized-snapshots --file=/path/to/mydump mydatabase
Tendrá que hacerlo para cada base de datos que tenga, ajustar el --jobs=4
valor a cualquier valor (pruebe algunos valores desde 2 hasta el número de núcleos, y vea cuál proporciona una mejor velocidad). Además, durante esta fase, nadie debe estar conectado a la base de datos, cualquier modificación resultará en un volcado corrupto (debido a la opción no segura --no-synchronized-snapshots
).
Después de eso, puede restaurar su volcado en la nueva instancia usando pg_restore
:
$ createdb <options> -T template0 mydatabase
$ pg_restore --exit-on-error --jobs=4 --dbname=mydatabase /path/to/mydump
Después de eso, se recomienda ejecutar ANALYZE
en su base de datos:
$ vacuumdb --analyze-only mydatabase
(si usted puede permitirse el tiempo, ejecutar sólo --analyze
a también VACUUM
la base de datos y actualizar los mapas de la visibilidad)
Actualización con pg_upgrade
Otra opción, es usar el contribpg_upgrade
. Usando el --link
método, proporciona una forma realmente rápida de actualizar PostgreSQL.
Antes de usarlo, debe hacer una copia de seguridad de todo el directorio de datos, porque en el --link
modo, si algo sale mal, puede perder ambos datos (nuevos y antiguos). Además, lea los documentos completos y especialmente las notas en la parte inferior (existen algunas limitaciones para pg_upgrade).
ACTUALIZACIÓN: utilice la --check
opción antes de ejecutar el comando definitivo. Además, para bases de datos grandes es recomendable ejecutar este comando en una sesión de pantalla.
Actualice utilizando una herramienta de replicación basada en disparador
Otra opción para actualizar una versión es usar una herramienta de replicación basada en el disparador. Como Slony, Bucardo y Londiste.
Esta es la opción que requiere el menor tiempo de inactividad posible, pero es la más difícil de trabajar.
Para hacerlo, debe crear un maestro-esclavo donde el maestro sea su versión actual (9.1) y el esclavo sea la nueva versión (9.3). Luego, espera la primera sincronización (con el sistema aún en producción), luego cierra todos los conectados a la base de datos (el tiempo de inactividad comienza aquí), espera a que el esclavo se ponga al día, promueve (el esclavo) para dominar y redirigir todos los clientes / aplicaciones a esta nueva versión. Y tu estas listo.
La documentación de Slony proporciona un paso a paso para actualizar PostgreSQL usando Slony .
Cuál elegir
Bueno, como siempre depende, resumiendo:
- El volcado + restauración es el más confiable, pero generalmente el más lento (el paralelismo puede dar resultados bastante buenos)
- Pg_upgrade es una de las mejores opciones para poco tiempo de inactividad (si puede usarlo, vea las limitaciones), a menudo solo lleva unos minutos, incluso para grandes bases de datos
- La replicación desencadenante es, sin duda, la que proporciona el menor tiempo de inactividad posible (casi cero), pero es realmente difícil de lograr y lo recomiendo solo para personas con experiencia (tanto en PostgreSQL como en la herramienta de replicación).
Espero poder ayudar Buena suerte.