Durante la actualización, estaba recibiendo
\u003e Deteniendo el servidor de base de datos PostgreSQL 15: mainError: El propietario de la configuración (postgres:101) y el propietario de los datos (runit-log:999) no coinciden, y el propietario de la configuración no es root … ¡falló!
¡falló!
no se pudo abrir el archivo de versión «/shared/postgres_data/PG_VERSION»: Permiso denegado
Fallo, saliendo
Lo cual se resolvió con
\u003e sudo ./launcher enter app
y luego
\u003e chown -R postgres:postgres /shared/postgres_data
chown -R postgres:postgres /shared/postgres_run
chmod -R 700 /shared/postgres_data
Estoy en un bucle infinito, la base de datos se actualizó bien pero cuando ejecuto ./launcher rebuild app simplemente se repite, lo único que puedo ver es lo siguiente
EDITADO: Encontré este mensaje…
mv: el movimiento entre dispositivos falló: '/shared/postgres_data_new' a '/shared/postgres_data/postgres_data_new'; imposible eliminar el destino: Directorio no vacío
Tu instalación contiene extensiones que deben actualizarse
con el comando ALTER EXTENSION. El archivo
update_extensions.sql
al ser ejecutado por psql por el superusuario de la base de datos actualizará
estas extensiones.
Por favor, aconséjame
Actualización Completa
----------------
Las estadísticas del optimizador no son transferidas por pg_upgrade.
Una vez que inicies el nuevo servidor, considera ejecutar:
/usr/lib/postgresql/15/bin/vacuumdb --all --analyze-in-stages
Ejecutar este script eliminará los archivos de datos del clúster antiguo:
./delete_old_cluster.sh
-------------------------------------------------------------------------------------
ACTUALIZACIÓN DE POSTGRES COMPLETA
La base de datos antigua 13 se almacena en /shared/postgres_data_old
Para completar la actualización, reconstruye de nuevo usando:
./launcher rebuild app
-------------------------------------------------------------------------------------
Ok, así que parece que este es el problema aquí:
Estos se encuentran en shared/standalone/ y ya se han movido manualmente…
mv: no se puede mover '/shared/postgres_data' a '/shared/postgres_data_old': Dispositivo o recurso ocupado
mv: el movimiento entre dispositivos falló: '/shared/postgres_data_new' a '/shared/postgres_data/postgres_data_new'; imposible eliminar el destino: Directorio no vacío
I, [2025-02-08T15:22:42.078189 #1] INFO -- : Generando locales (esto puede tardar un poco)...
Ninguna solución parece funcionar. Es muy frustrante.
Sería muy inusual que alguien ofreciera tal servicio sin que se lo pidieran primero.
Si deseas contratar a alguien, este es el lugar al que ir: Marketplace - Discourse Meta
Nuestra instancia multisitio está caída después de la actualización. Decía:
Su instalación contiene extensiones que deben actualizarse
con el comando ALTER EXTENSION. El archivo
update_extensions.sql
cuando sea ejecutado por psql por el superusuario de la base de datos, actualizará
estas extensiones.
No encuentro el archivo update_extensions.sql en ningún sitio. ¿Dónde podría estar ubicado?
Verifica esto
mv: no se puede mover '/shared/postgres_data' a '/shared/postgres_data_old': Dispositivo o recurso ocupado
mv: error al mover entre dispositivos: '/shared/postgres_data_new' a '/shared/postgres_data/postgres_data_new'; imposible eliminar destino: el directorio no está vacío
I, [2025-02-08T15:22:42.078189 #1] INFO -- : Generando locales (esto podría tardar un tiempo)...
Fui yo. Ofrezco ayuda cuando parece que alguien está en una situación que será difícil de resolver con la ayuda aquí.
Pregunta de curiosidad.
¿Existe algún estándar o estrategia relacionada con las actualizaciones de componentes clave, como Postgres?
Veo que el soporte de Postgres 13 se extendió hasta el 25/11, y que la versión 15 se extiende hasta 2027, y la versión actual es la 17.
Realmente solo busco aprender y entender. Cambiar de versión de base de datos generalmente es un gran problema y un gran esfuerzo.
¡Gracias!
He estado desde PostgreSQL 10. Por lo general, actualizan cada dos versiones, aunque pasaron del 12 al 13 porque tenía algunas mejoras que hicieron que un cambio anticipado valiera la pena. Me sorprendió un poco que no pasaran al 16.
Normalmente van bastante bien si tienes suficiente espacio en disco y Docker reciente.
He vuelto a la plantilla 13 hasta que haya una solución, gracias.
He resuelto el problema que tuve con la actualización de PostgreSQL de 13 a 15, después de restaurar el servidor con la actualización fallida a partir de copias de seguridad, los siguientes pasos me funcionaron con una configuración regional de PostgreSQL en_GB.UTF-8:
sudo -i
su - discourse
cd /var/discourse
git stash
git stash drop
git pull
./launcher stop app
docker run --rm \
--entrypoint=/bin/bash \
-e LANG='en_GB.UTF-8' \
-v /var/discourse/shared/standalone/postgres_data:/var/lib/postgresql/13/data \
-v /var/discourse/shared/standalone/postgres_data_new:/var/lib/postgresql/15/data \
tianon/postgres-upgrade:13-to-15 \
-c 'sed -i "s/^# $LANG/$LANG/" /etc/locale.gen && locale-gen &&
apt-get update && apt-get install -y postgresql-13-pgvector postgresql-15-pgvector &&
docker-upgrade'
exit
mv /var/discourse/shared/standalone/postgres_data /var/discourse/shared/standalone/postgres_data_old
mv /var/discourse/shared/standalone/postgres_data_new /var/discourse/shared/standalone/postgres_data
chown -R 101:104 /var/discourse/shared/standalone/postgres_data
su - discourse
cd /var/discourse
docker run --rm -v /var/discourse/shared/standalone:/shared \
local_discourse/app chown -R postgres:postgres /shared/postgres_data
./launcher rebuild app
Tuve que eliminar los cambios locales que se habían realizado anteriormente para el LANG de PostgreSQL usando git stash; git stash drop y mover los directorios de datos de PostgreSQL tuvo que hacerse como root y se necesitó un chown.
¿Se requiere git pull esta vez? Normalmente no es así.
Hoy en día nunca es necesario, porque la reconstrucción lo hace.
El mensaje final Device or resource busy del primer error implica que algo más está bloqueando ese directorio postgres_data para que no se pueda mover.
Dado que ese es el directorio de la base de datos, una explicación probable es que postgres_data podría ser un punto de montaje. Esto es aún más probable ya que vemos inter-device move failed en el segundo comando mv, lo que implica que shared/postgres_data_new y shared/postgres_data están en discos/particiones diferentes.
Si confirmas que postgres_data es un punto de montaje, tendrás que mover manualmente todos los archivos de postgres_data a otro directorio de copia de seguridad, y luego mover todos los archivos de postgres_data_new al directorio postgres_data (ahora vacío). Ambos movimientos deben realizarse después de que la primera reconstrucción se complete con UPGRADE OF POSTGRES COMPLETE pero antes de emitir la segunda.
Si postgres_data no es un punto de montaje, lsof es tu amigo. Puedes usarlo para intentar identificar qué está causando el bloqueo.
Por supuesto, haz las copias de seguridad necesarias primero.
Esto es perfecto, gracias.
Los archivos estaban en la siguiente carpeta:
/var/postgres_data_discourse como postgres_data_new
Lo siguiente lo solucionó.
Moví postgres_data_new a /var
Renombré postgres_data_discourse a postgres_data_discourse_old
Renombré postgres_data_new a postgres_data_discourse
Emití ./launcher rebuild app
Gracias de nuevo 
Tengo 62 GB de base de datos, ¿qué sugieres para realizar la mejor actualización?
62 GB /var/discourse/shared/standalone/postgres_data
Te recomiendo que te muevas a una nueva VM, inicies un nuevo Discourse, con una base de datos vacía (copiando los directorios ssl y letsencrypt si deseas un cambio sin tiempo de inactividad) y restaura la base de datos actual en el nuevo servidor. Esto te permite realizar la actualización sin tiempo de inactividad y sin riesgo de que algo salga mal.
Probablemente no sea demasiado pronto para actualizar tu sistema operativo de todos modos.
Esa es una buena idea.
¿Puedo mover la copia de seguridad de ### 3.4.0.beta4-dev ### a la última versión de una instalación nueva?
Si estás preguntando si puedes restaurar cualquier versión antigua de Discourse a la versión nueva de Discourse que puedas obtener, la respuesta es sí.