¿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