pg_upgrade - Online en la nube

PROGRAMA:

NOMBRE

pg_upgrade: actualiza una instancia de servidor PostgreSQL

SINOPSIS

pg_actualizar -b viejobindir -B nuevobindir -d dir_datosantiguos -D nuevodatadir [opción...]

DESCRIPCIÓN

pg_upgrade (anteriormente llamado pg_migrator) permite que los datos almacenados en archivos de datos PostgreSQL sean
actualizado a una versión principal posterior de PostgreSQL sin el volcado / recarga de datos normalmente
requerido para actualizaciones de versiones principales, por ejemplo, de 8.4.7 a la versión principal actual de
PostgreSQL. No es necesario para actualizaciones de versiones menores, por ejemplo, de 9.0.1 a 9.0.4.

Las principales versiones de PostgreSQL agregan regularmente nuevas características que a menudo cambian el diseño del
tablas del sistema, pero el formato de almacenamiento de datos interno rara vez cambia. pg_upgrade usa esto
hecho de realizar actualizaciones rápidas creando nuevas tablas del sistema y simplemente reutilizando las antiguas
archivos de datos de usuario. Si una futura versión importante cambia el formato de almacenamiento de datos de alguna manera
que hace que el formato de datos antiguo sea ilegible, pg_upgrade no se podrá utilizar para tal
actualizaciones. (La comunidad intentará evitar tales situaciones).

pg_upgrade hace todo lo posible para asegurarse de que los clústeres nuevos y antiguos sean compatibles con binarios, p. ej.
comprobando la configuración de tiempo de compilación compatible, incluidos los binarios de 32/64 bits. Está
importante que cualquier módulo externo también sea compatible con binario, aunque esto no puede ser
comprobado por pg_upgrade.

pg_upgrade admite actualizaciones de 8.4.X y posteriores a la versión principal actual de
PostgreSQL, incluidas las versiones alfa y instantáneas.

OPCIONES

pg_upgrade acepta los siguientes argumentos de la línea de comandos:

-b ligar
--old-bindir =ligar
el antiguo directorio ejecutable de PostgreSQL; Variable ambiental PGBINOLD

-B ligar
--new-bindir =ligar
el nuevo directorio ejecutable de PostgreSQL; Variable ambiental PGBINNUEVO

-c
--cheque
verifique solo los clústeres, no cambie ningún dato

-d directorio de datos
--old-datadir =directorio de datos
el antiguo directorio de datos del clúster; Variable ambiental PGDATAOLD

-D directorio de datos
--new-datadir =directorio de datos
el nuevo directorio de datos del clúster; Variable ambiental PGDATOSNUEVO

-j
--trabajos
número de procesos o subprocesos simultáneos a utilizar

-k
--Enlace
use enlaces físicos en lugar de copiar archivos al nuevo clúster (use puntos de unión en
ventanas)

-o opciones
--opciones antiguas opciones
opciones que se pasarán directamente al antiguo Postgres mando; múltiples invocaciones de opciones
se adjuntan

-O opciones
--nuevas-opciones opciones
opciones que se pasarán directamente al nuevo Postgres mando; múltiples invocaciones de opciones
se adjuntan

-p Puerto
--old-port =Puerto
el antiguo número de puerto del clúster; Variable ambiental PGPORTOLD

-P Puerto
--nuevo-puerto =Puerto
el nuevo número de puerto del clúster; Variable ambiental PGPORTNUEVO

-r
--conservar
retener los archivos de registro y SQL incluso después de completarlos correctamente

-U nombre de usuario
--username =nombre de usuario
nombre de usuario de instalación del clúster; Variable ambiental PGUSER

-v
--verboso
habilitar el registro interno detallado

-V
--versión
mostrar información de la versión, luego salir

-?
--ayuda
mostrar ayuda, luego salir

USO

Estos son los pasos para realizar una actualización con pg_upgrade:

1. Mueva opcionalmente el clúster anterior: si está utilizando una instalación de versión específica
directorio, por ejemplo, /opt/PostgreSQL/9.1, no es necesario mover el clúster anterior. El
Todos los instaladores gráficos utilizan directorios de instalación específicos de la versión.

Si su directorio de instalación no es específico de la versión, por ejemplo, / usr / local / pgsql, es
necesario mover el directorio de instalación actual de PostgreSQL para que no interfiera
con la nueva instalación de PostgreSQL. Una vez que se apaga el servidor PostgreSQL actual,
es seguro cambiar el nombre del directorio de instalación de PostgreSQL; asumiendo el directorio antiguo
es / usr / local / pgsql, puede hacer:

mv / usr / local / pgsql /usr/local/pgsql.old

para cambiar el nombre del directorio.

2. Para instalaciones de código fuente, compile la nueva versión: compile la nueva fuente de PostgreSQL con
configurar banderas que son compatibles con el clúster anterior. pg_upgrade comprobará
pg_controldata para asegurarse de que todas las configuraciones sean compatibles antes de iniciar la actualización.

3. Instale los nuevos archivos binarios de PostgreSQL: instale los archivos binarios y el soporte del nuevo servidor
archivos. pg_upgrade se incluye en una instalación predeterminada.

Para instalaciones de origen, si desea instalar el nuevo servidor en una ubicación personalizada, utilice
la variable de prefijo:

hacer prefijo = / usr / local / pgsql.new install

4. Inicialice el nuevo clúster de PostgreSQL: inicialice el nuevo clúster usando initdb. Otra vez,
uso compatible initdb banderas que coinciden con el clúster antiguo. Muchos instaladores prediseñados hacen
este paso automáticamente. No es necesario iniciar el nuevo clúster.

5. Instale archivos de objetos compartidos personalizados: instale los archivos de objetos compartidos personalizados (o DLL)
utilizado por el antiguo clúster en el nuevo clúster, por ejemplo, pgcrypto.so, si son de
contrib o alguna otra fuente. No instale las definiciones de esquema, p. Ej.
pgcrypto.sql, porque se actualizarán desde el clúster anterior. Además, cualquier costumbre
Los archivos de búsqueda de texto completo (diccionario, sinónimo, diccionario de sinónimos, palabras vacías) también deben
copiado al nuevo clúster.

6. Ajustar la autenticación: pg_actualizar se conectará a los servidores nuevos y antiguos varios
veces, por lo que es posible que desee configurar la autenticación para peer en pg_hba.conf o usar un
~ / .pgpass archivo (consulte la Sección 31.15, “El archivo de contraseña”, en la documentación).

7. Detenga ambos servidores: asegúrese de que ambos servidores de bases de datos estén detenidos, en Unix, por ejemplo:

pg_ctl -D /opt/PostgreSQL/8.4 parada
pg_ctl -D /opt/PostgreSQL/9.0 parada

o en Windows, utilizando los nombres de servicio adecuados:

NET DETENER postgresql-8.4
NET DETENER postgresql-9.0

Los servidores en espera de transmisión de replicación y envío de registros pueden seguir funcionando hasta que
paso posterior.

8. Verifique los servidores en espera: si está actualizando Streaming Replication y Log-Shipping
servidores en espera, verifique que los antiguos servidores en espera se pongan al día ejecutando
pg_controldata contra los clústeres primarios y en espera antiguos. Verifique que el "Último
los valores de la ubicación del punto de control coinciden en todos los grupos. (Habrá un desajuste si es antiguo
los servidores en espera se cerraron antes que el antiguo primario).

9. Ejecute pg_upgrade: ejecute siempre el binario pg_upgrade del nuevo servidor, no del antiguo.
pg_upgrade requiere la especificación de los datos y ejecutables del clúster antiguo y nuevo
(bin) directorios. También puede especificar los valores de usuario y puerto, y si desea
datos vinculados en lugar de copiados (predeterminado).

Si usa el modo de enlace, la actualización será mucho más rápida (sin copiar archivos) y usará menos
espacio en disco, pero no podrá acceder a su antiguo clúster una vez que inicie el nuevo
clúster después de la actualización. El modo de enlace también requiere que los datos del clúster nuevos y antiguos
los directorios deben estar en el mismo sistema de archivos. (Los espacios de tabla y pg_xlog pueden estar en diferentes
sistemas de archivos.) Consulte pg_upgrade --help para obtener una lista completa de opciones.

La característica --trabajos La opción permite utilizar varios núcleos de CPU para copiar / vincular archivos
y volcar y recargar esquemas de bases de datos en paralelo; un buen lugar para comenzar es el
máximo del número de núcleos de CPU y espacios de tabla. Esta opción puede dramáticamente
Reducir el tiempo de actualización de un servidor de bases de datos múltiples que se ejecuta en un multiprocesador.
maquina

Para los usuarios de Windows, debe iniciar sesión en una cuenta administrativa y luego iniciar una
shell como usuario de postgres y establezca la ruta adecuada:

RUNAS / USUARIO: postgres "CMD.EXE"
SET PATH =% PATH%; C: \ Archivos de programa \ PostgreSQL \ 9.0 \ bin;

y luego ejecute pg_upgrade con directorios citados, por ejemplo:

pg_upgrade.exe
--old-datadir "C: / Archivos de programa / PostgreSQL / 8.4 / data"
--new-datadir "C: / Archivos de programa / PostgreSQL / 9.0 / data"
--old-bindir "C: / Archivos de programa / PostgreSQL / 8.4 / bin"
--new-bindir "C: / Archivos de programa / PostgreSQL / 9.0 / bin"

Una vez iniciado, pg_actualizar Verificará que los dos clústeres sean compatibles y luego
ascender de categoría. Puedes usar pg_actualizar --cheque para realizar solo las comprobaciones, incluso si el antiguo
el servidor todavía se está ejecutando. pg_actualizar --cheque también describirá los ajustes manuales
que necesitará hacer después de la actualización. Si va a utilizar el modo de enlace,
debería usar el --Enlace opción con --cheque para habilitar comprobaciones específicas del modo de enlace.
pg_actualizar requiere permiso de escritura en el directorio actual.

Obviamente, nadie debería acceder a los clústeres durante la actualización. pg_upgrade
por defecto, ejecuta servidores en el puerto 50432 para evitar conexiones de cliente no deseadas. Ustedes
puede utilizar el mismo número de puerto para ambos clústeres al realizar una actualización porque el antiguo
y los nuevos clústeres no se ejecutarán al mismo tiempo. Sin embargo, al comprobar un viejo
servidor en ejecución, los números de puerto antiguo y nuevo deben ser diferentes.

Si ocurre un error al restaurar el esquema de la base de datos, pg_actualizar saldrá y tu
tendrá que volver al clúster anterior como se describe en el Paso 16 a continuación. Intentar pg_actualizar
nuevamente, deberá modificar el clúster anterior para que el esquema pg_upgrade se restaure
tiene éxito. Si el problema es un módulo contrib, es posible que deba desinstalarlo.
módulo del clúster anterior e instálelo en el nuevo clúster después de la actualización,
asumiendo que el módulo no se está utilizando para almacenar datos de usuario.

10. Actualizar el modo de espera de replicación de transmisión y envío de registros
servidores: si tiene Streaming Replication (consulte la Sección 25.2.5, “Streaming
Replicación ”, en la documentación) o Envío de registros (consulte la Sección 25.2,“ Envío de registros
Servidores en espera ”, en la documentación) servidores en espera, siga estos pasos para actualizar
ellos. No ejecutará pg_upgrade en los servidores en espera, sino rsync. Hacer
aún no ha iniciado ningún servidor. Instale los nuevos binarios de PostgreSQL en servidores en espera:
Asegúrese de que los nuevos archivos binarios y de soporte estén instalados en todos los servidores en espera.
Asegúrese de que los nuevos directorios de datos en espera No
existen: asegúrese de que los nuevos directorios de datos en espera No existen o están vacíos. Si
initdb, elimine los directorios de datos del servidor en espera. Instalar compartido personalizado
archivos de objeto: instale los mismos archivos de objeto compartidos personalizados en los
instalado en el nuevo clúster maestro. Detenga los servidores en espera: si los servidores en espera
aún en ejecución, deténgalos ahora siguiendo las instrucciones anteriores. Guarde los archivos de configuración:
Guarde los archivos de configuración de los standbys que necesite mantener, p. Ej.
postgresql.conf, recovery.conf, ya que estos se sobrescribirán o eliminarán en el próximo
paso. Iniciar y detener el nuevo clúster maestro: en el nuevo clúster maestro, cambie
nivel_wal a hot_standby en el archivo postgresql.conf y luego iniciar y detener el
grupo. Ejecute rsync: desde un directorio que esté encima del clúster de base de datos nuevo y antiguo
directorios, ejecute esto para cada esclavo:

rsync --archive --delete --hard-links --solo tamaño old_pgdata new_pgdata remote_dir

dónde datos_página_antiguos y nuevo_pgdata son relativas al directorio actual, y directorio_remoto
is above los directorios del clúster antiguo y nuevo en el servidor en espera. Lo viejo y lo nuevo
Las rutas relativas del clúster deben coincidir en el servidor maestro y en el servidor en espera. Consultar el rsync
página de manual para obtener detalles sobre cómo especificar el directorio remoto, p. ej.
standbyhost: / opt / PostgreSQL /. rsync será rápido cuando pg_upgrade's --Enlace el modo es
utilizado porque creará enlaces duros en el servidor remoto en lugar de transferir
datos del usuario.

Si tiene espacios de tabla, deberá ejecutar un comando rsync similar para cada
directorio de espacio de tabla. Si ha reubicado pg_xlog fuera de los directorios de datos,
rsync también debe ejecutarse en esos directorios. Configure la replicación de transmisión y
espera de envío de registros
servidores: configure los servidores para el trasvase de registros. (No necesitas correr
pg_start_backup () y pg_stop_backup () o realizar una copia de seguridad del sistema de archivos, ya que los esclavos están
todavía sincronizado con el maestro.)

11. Restaurar pg_hba.conf: si modificó pg_hba.conf, restaure su configuración original. Eso
También puede ser necesario ajustar otros archivos de configuración en el nuevo clúster para
coincidir con el antiguo clúster, por ejemplo, postgresql.conf.

12. Inicie el nuevo servidor: el nuevo servidor ahora se puede iniciar de forma segura, y luego cualquier rsync'ed
servidores en espera.

13. Procesamiento posterior a la actualización: si se requiere algún procesamiento posterior a la actualización, pg_upgrade
emitir advertencias a medida que se completa. También generará archivos de script que deben ser ejecutados por
el administrador. Los archivos de script se conectarán a cada base de datos que necesite
procesamiento posterior a la actualización. Cada secuencia de comandos debe ejecutarse usando:

psql --nombre de usuario postgres --file script.sql postgres

Los scripts se pueden ejecutar en cualquier orden y se pueden eliminar una vez que se hayan ejecutado.

Precaución
En general, no es seguro acceder a las tablas a las que se hace referencia en los scripts de reconstrucción hasta que
Los scripts de reconstrucción se han ejecutado hasta el final; hacerlo podría producir resultados incorrectos o
bajo rendimiento. Se puede acceder a las tablas a las que no se hace referencia en los scripts de reconstrucción
inmediatamente.

14. Estadísticas: debido a que las estadísticas del optimizador no se transfieren pg_actualizar, va a
recibir instrucciones para ejecutar un comando para regenerar esa información al final de la
ascender de categoría. Es posible que deba configurar los parámetros de conexión para que coincidan con su nuevo clúster.

15. Eliminar el clúster antiguo: una vez que esté satisfecho con la actualización, puede eliminar el antiguo
directorios de datos del clúster ejecutando el script mencionado cuando pg_actualizar completa
(La eliminación automática no es posible si tiene espacios de tabla definidos por el usuario dentro del
directorio de datos antiguo.) También puede eliminar los directorios de instalación antiguos (por ejemplo, bin,
Cuota).

16. Volviendo al clúster anterior: si, después de ejecutar pg_actualizar, desea volver a lo antiguo
cluster, hay varias opciones:

· Si corriste pg_actualizar con --cheque, no se realizaron modificaciones en el clúster antiguo
y puedes reutilizarlo en cualquier momento.

· Si corriste pg_actualizar con --Enlace, los archivos de datos se comparten entre los antiguos y
nuevo clúster. Si inició el nuevo clúster, el nuevo servidor ha escrito a esos
archivos compartidos y no es seguro utilizar el clúster anterior.

· Si corriste pg_actualizar sin --Enlace o no inició el nuevo servidor, el antiguo
el clúster no se modificó, excepto que, si se iniciaba la vinculación, se usaba un sufijo .old
adjunto a $ PGDATA / global / pg_control. Para reutilizar el clúster antiguo, posiblemente elimine
el sufijo .old de $ PGDATA / global / pg_control; A continuación, puede reiniciar el antiguo
racimo.

NOTAS

pg_upgrade no admite la actualización de bases de datos que contienen estos registros de referencias * OID
tipos de datos del sistema: regproc, regprocedure, regoper, regoperator, regconfig y
regdictionary. (el tipo de registro se puede actualizar).

Pg_upgrade informará de todos los casos de falla, reconstrucción y reindexación si afectan su
instalación; Se generarán scripts posteriores a la actualización para reconstruir tablas e índices.
automáticamente. Si está intentando automatizar la actualización de muchos clústeres, debería encontrar
que los clústeres con esquemas de base de datos idénticos requieren los mismos pasos posteriores a la actualización para todos
actualizaciones de clústeres; esto se debe a que los pasos posteriores a la actualización se basan en la base de datos
esquemas y no datos de usuario.

Para las pruebas de implementación, cree una copia de solo esquema del clúster anterior, inserte datos ficticios,
y actualizar eso.

Si está actualizando un clúster anterior a PostgreSQL 9.2 que usa un archivo de configuración
directorio, debe pasar la ubicación del directorio de datos real a pg_upgrade, y pasar el
ubicación del directorio de configuración al servidor, por ejemplo, -d / directorio-de-datos-reales -o '-D
/ directorio-de-configuración '.

Si usa un servidor anterior a 9.1 que usa un directorio de socket de dominio Unix no predeterminado o
un valor predeterminado que difiere del valor predeterminado del nuevo clúster, establecer PHOST para apuntar a lo viejo
ubicación del socket del servidor. (Esto no es relevante en Windows).

Si desea utilizar el modo de enlace y no desea que se modifique su antiguo clúster cuando
se inicia el nuevo clúster, haga una copia del clúster anterior y actualícelo en el modo de enlace. A
haz una copia válida del clúster anterior, usa rsync para crear una copia sucia del clúster antiguo
mientras el servidor se está ejecutando, apague el servidor anterior y ejecute rsync - suma de comprobación de nuevo
para actualizar la copia con cualquier cambio para que sea coherente. (- suma de comprobación es necesario
because rsync solo tiene una granularidad de tiempo de modificación de archivo de un segundo).
para excluir algunos archivos, por ejemplo, postmaster.pid, como se documenta en la Sección 24.3.3, “Cómo hacer un
Copia de seguridad base utilizando la API de bajo nivel ”, en la documentación. Si su sistema de archivos admite
instantáneas del sistema de archivos o copias de archivos de copia en escritura, puede usar eso para hacer una copia de seguridad de
el clúster y los espacios de tabla antiguos, aunque la instantánea y las copias deben crearse
simultáneamente o mientras el servidor de la base de datos está inactivo.

Use pg_upgrade en línea usando los servicios de onworks.net