¿Tienes algunos más detalles? Estoy viendo lo mismo
1 me gusta
Para quienes también estén viendo lo mismo, este es el resumen (IA) de lo que hice:
Iniciar temporalmente PG15 → Volcar la base de datos → Usar PG18 → Restaurar el volcado
1 me gusta
Así que, sí, esta actualización se basa en imágenes.
Entonces, ¿aunque elijas instalar una versión antigua de Discourse, la imagen forzará una actualización a la 18?
Entendido.
1 me gusta
Veo que lo has arreglado, pero el método que te dio ChatGPT, aunque solucionó el error, borró mi base de datos, por lo que esencialmente no hay cuentas, temas ni publicaciones.
Afortunadamente, era un foro de desarrollo relativamente nuevo, así que no se perdió demasiado.
2 Me gusta
Se tuvo mucho cuidado para asegurarse de que esto no ocurriera hoy. Después de cada paso, me informaba de que no se borraría nada, y tuve la impresión de que aseguramos en tres ocasiones que todos los datos se habían migrado antes de poder acordar eliminar lo que ya no necesitábamos.
Pero si algo hubiera salido mal, los únicos datos que me habrían faltado habrían sido la configuración del componente del tema.
1 me gusta
Hola, tengo un foro con una base de datos bastante grande (unos 80 GB). Para pasar de la versión 13 a la 15, cambié de servidor, hice una instalación nueva y restauré la base de datos.
¿Recomendáis hacer lo mismo? (he probado a actualizar directamente, pero me da errores de collation).
Anteriormente en el tema, el equipo declaró:
Así que, sí, es una opción.
Ya habías dicho:
¿Errores de ordenación? ¿Qué versión es la actual de Discourse?
Tal vez podrías publicar los errores que encontraste / la salida de la consola.
¿pero no te quedaste sin espacio (se recomienda 2 x el tamaño de la base de datos existente)?
Hola, tengo espacio (250 GB libres). El error era “collation mismatch”, pero creo que no tengo las cadenas utf en el archivo app.yml.
1 me gusta
Intentamos proporcionar valores predeterminados sensatos en las imágenes de discourse_docker, pero no es posible contemplar cada caso de uso posible. Siéntete libre de personalizar tus imágenes para mantener versiones anteriores si lo prefieres.
Hasta cierto punto, las versiones de las dependencias reflejan nuestros requisitos de alojamiento: utilizamos la imagen base internamente. Esto significa que no debería quedar demasiado desactualizada, pero también implica que solo podemos mantener un número limitado de combinaciones.
Ese es un método perfectamente válido si te resulta más cómodo.
Si la advertencia se genera mientras se prepara la volcado de la base de datos antigua, no hay nada de qué preocuparse. Solo estamos ejecutando el servidor contra el directorio de datos antiguo con el propósito de ejecutar pg_dump. Cuando se restaura el volcado en el nuevo servidor, los índices se recrean.
La razón por la que ves esto es que en los últimos días hemos lanzado una nueva versión de la imagen base que actualiza de Debian Bookworm a Trixie, cambiando la versión de glibc. Las configuraciones regionales basadas en el proveedor libc (que probablemente estabas usando) no son estables entre actualizaciones de glibc, por lo que cuando el script de actualización inicia un servidor Postgres para volcar tus datos antiguos, muestra advertencias de desajuste de ordenación.
El desajuste de ordenación es la razón principal por la que estamos haciendo volcado y restauración en lugar de ejecutar pg_upgrade. Una vez que tu base de datos use C.UTF-8 con el proveedor builtin, las actualizaciones de glibc ya no afectarán a las ordenaciones.
2 Me gusta
Realicé la actualización esta noche y todo salió según lo planeado. Obtuve las mismas advertencias de clasificación de base de datos, pero parece que deberíamos ignorarlas. Gracias.
2 Me gusta
Intenté agregar lo siguiente a app.yml
app.yml
templates:
- “templates/postgres.15.template.yml”
- “templates/redis.template.yml”
- “templates/web.template.yml”
- “templates/web.ratelimited.template.yml”
Para posponer la actualización, pero obtengo este error
Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/15/main/postgresql.conf
Ubicación del fallo: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/replace_command.rb:11:in ‘IO.read’
replace failed with the params {“filename” => “/etc/postgresql/15/main/postgresql.conf”, “from” => “data_directory = ‘/var/lib/postgresql/15/main’”, “to” => “data_directory = ‘/shared/postgres_data’”}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
Parece que el contenedor base no es el correcto, creo. ¿Ejecutaste ./launcher rebuild? Eso debería hacer un git pull, pero podrías intentar ejecutar un git pull para ver si eso cambia algo.
1 me gusta
Mismo error
Digest: sha256:837e8ed4b5916baa36856b842ad84fe262b6b1b5550701f8844b13cc7acad7a5
Estado: Se descargó una imagen más nueva para discourse/base:2.0.20260812-0036
docker.io/discourse/base:2.0.20260812-0036
Asegurando que el launcher esté actualizado
El launcher está actualizado
Deteniendo el contenedor anterior
- /usr/bin/docker stop -t 600 app
app
2.0.20260812-0036: Extrayendo de discourse/base
Digest: sha256:837e8ed4b5916baa36856b842ad84fe262b6b1b5550701f8844b13cc7acad7a5
Estado: La imagen está actualizada para discourse/base:2.0.20260812-0036
docker.io/discourse/base:2.0.20260812-0036
/usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups.rb
/usr/local/bin/pups --stdin
I, [2026-08-25T06:22:16.249062 #1] INFO – : Leyendo desde stdin
I, [2026-08-25T06:22:16.274434 #1] INFO – : Archivo > /etc/service/postgres/run chmod: +x chown:
I, [2026-08-25T06:22:16.281650 #1] INFO – : Archivo > /etc/service/postgres/log/run chmod: +x chown:
I, [2026-08-25T06:22:16.287846 #1] INFO – : Archivo > /etc/runit/3.d/99-postgres chmod: +x chown:
I, [2026-08-25T06:22:16.293208 #1] INFO – : Archivo > /root/install_postgres chmod: +x chown:
I, [2026-08-25T06:22:16.299851 #1] INFO – : Archivo > /root/upgrade_postgres chmod: +x chown:
FALLO
Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/15/main/postgresql.conf
Ubicación del fallo: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/replace_command.rb:11:in ‘IO.read’
replace failed with the params {“filename” => “/etc/postgresql/15/main/postgresql.conf”, “from” => “data_directory = ‘/var/lib/postgresql/15/main’”, “to” => “data_directory = ‘/shared/postgres_data’”}
bootstrap failed with exit code 1
** FALLO AL INICIALIZAR ** haz scroll hacia arriba y busca mensajes de error anteriores, puede haber más de uno.
./discourse-doctor puede ayudar a diagnosticar el problema.
2d15a756bfd82ed45debfbb4936784721293a3aeecabe8ba9b58c64d4bbe16e1
1 me gusta
Creo que he encontrado la causa.
La imagen base actual instala el servidor PostgreSQL 18, pero postgres.15.template.yml sigue asumiendo que los paquetes del servidor PostgreSQL 15 ya están presentes. Por lo tanto, llega a:
/etc/postgresql/15/main/postgresql.conf
anterior a que ese archivo exista, lo que produce el error ENOENT mencionado anteriormente.
He abierto un PR pequeño que hace que la plantilla de retención de PostgreSQL 15 elimine los paquetes del servidor PostgreSQL 18 e instale los paquetes del servidor PostgreSQL 15 antes de configurar PostgreSQL:
Esto debería restaurar la ruta prevista, donde cambiar postgres.template.yml a postgres.15.template.yml pospone la actualización a PostgreSQL 18.
4 Me gusta
¿Se ha publicado la actualización?
¿Cuándo podré intentarlo de nuevo? (solo por información)
He fusionado la corrección (¡gracias, @Ethsim2!), así que ya puedes intentarlo de nuevo.
2 Me gusta
¡Funciona, muchas gracias!
2 Me gusta
¿El proceso de actualización ha ido bien para quienes tienen varios contenedores en el mismo servidor? Si me sobra tiempo este fin de semana, podría actualizar el nuestro, pero pensé en consultar primero por aquí por si acaso debería esperar un poco más…
sí, hace unas semanas hice actualizaciones en contenedores duales en un servidor (también en un servidor ruso). No tuve ningún problema, pero asegúrate de tener suficiente espacio en disco primero.
3 Me gusta
Consejo para quien actualice Postgres fuera de Docker. Puedes usar --link en pg_upgrade para no tener que copiar los datos. Puedes enlazarlos directamente. Ahorra espacio en disco.
2 Me gusta