buena idea, ¡gracias, Ed! He actualizado mi publicación. 
2 Me gusta
Con este cambio, se observa una reducción general del consumo de memoria de aproximadamente el 4%. Buen trabajo.
2 Me gusta
Gracias, Lilly. Hice la actualización un poco antes y todo parece haber salido bien 
1 me gusta
No es infrecuente que las tablas y los índices reescritos sean mucho más compactos.
1 me gusta
Eso está dentro del ruido operativo de Postgres (depende de si se observa antes o después de vacuum, reconstrucción de tablas, etc.)
Desde entonces no he notado que falte nada, así que, por lo que puedo ver, todo está bien.
1 me gusta
Estoy ejecutando Discourse en un contenedor Docker independiente en /var/discourse.
Intenté actualizar la base de datos PostgreSQL integrada de la versión 15 a la 18. La actualización pareció completarse, y el directorio de datos activo ahora informa:
/shared/postgres_data/PG_VERSION
18
Sin embargo, el contenedor de Discourse reconstruido aún contiene solo los binarios de PostgreSQL 15:
/usr/lib/postgresql/15/bin/postgres
postgres (PostgreSQL) 15.18
El servicio de PostgreSQL está configurado para ejecutar:
/usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main
mientras que el directorio de datos real de Discourse está montado en:
/shared/postgres_data
En consecuencia, PostgreSQL falla con:
FATAL: database files are incompatible with server
DETAIL: The data directory was initialized by PostgreSQL version 18,
which is not compatible with this version 15.18
(Debian 15.18-1.pgdg12+1).
Entiendo que las imágenes Docker recientes de Discourse deberían incluir los binarios de PostgreSQL 18. Cambié app.yml para usar la plantilla de PostgreSQL 18 y reconstruí la aplicación, pero el contenedor resultante aún tiene los binarios de PostgreSQL 15 y el script del servicio aún apunta a /etc/postgresql/15/main.
La parte relevante de mi configuración actual del servicio es:
HOME=/var/lib/postgresql USER=postgres exec thpoff \
chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert \
/usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main
Mis preguntas son:
-
¿Cuál es la forma correcta de reconstruir o actualizar el contenedor de Discourse para que realmente contenga los binarios de PostgreSQL 18?
-
¿Existe alguna plantilla o etiqueta de imagen específica que deba usarse en
app.yml? -
Una vez que PostgreSQL 18 esté disponible, ¿cuál es el procedimiento compatible para iniciarlo contra el directorio existente
/shared/postgres_data?
No he eliminado ni reinitializado el directorio de datos de PostgreSQL 18. Preferiría recuperar el clúster actualizado en lugar de restaurar los datos antiguos de PostgreSQL 15.
1 me gusta
basado en las instrucciones del OP, eso parece haber sido un paso innecesario, a menos que me esté perdiendo algo.
simplemente reconstruir una instalación estándar debería haber descargado la imagen más reciente y haber iniciado la migración.
a menos que de alguna forma optes por no usar la imagen más reciente, ¿no estaban garantizadas las nuevas binarias? Muy extraño…
¿estás seguro de que no has fijado una imagen concreta?
3 Me gusta
¿No intencionadamente? Estoy en el repositorio git regular y en la rama correspondiente, y no hay nada en mi app.yml que me indique que he fijado algo. Solo cambié a la plantilla de postgres 18 para ver si ayudaba; sí, ese fue un paso innecesario que no sirvió de nada, así que puedo revertirlo.
¿Alguna sugerencia sobre cómo obtener las nuevas binarias? Realmente no están ahí, sin importar las veces que lo reconstruyo:
root@hostname-app:/usr/lib/postgresql# ls -la
total 12
drwxr-xr-x 1 root root 4096 May 21 00:47 .
drwxr-xr-x 1 root root 4096 May 21 00:48 ..
drwxr-xr-x 1 root root 4096 May 21 00:47 15
root@hostname-app:/usr/lib/postgresql#
1 me gusta
Para ahorrarte tiempo y molestias, consideraría usar tu última copia de seguridad para crear un nuevo servidor, lo cual te ahorraría mucho trabajo.
1 me gusta
¡Vale, supongo que sí! A veces no vale la pena perder el tiempo intentando arreglar las cosas. Gracias.
2 Me gusta
¿Cómo puedes acceder a la base de datos mediante root@ para subirla a una nueva instancia, cuando no puedes acceder al panel de administración porque tu Discourse ha decidido perder la cabeza? (¿Quizás otra guía?)
¿O cuál es el comando de línea para ejecutar lo mismo que se haría a través del panel de administración?
Vale, y más al grano, necesito reconstruir la app para solucionar un error de certificado que parece haber surgido de la nada (ningún cambio previo anticipaba el aparente fallo). Está apareciendo el error de que el puerto 443 no es accesible (el asistente indica: “Verificación DNS fallida”). No sé si Cloudflare o DigitalOcean cambiaron algo, pero, de nuevo, no hice ningún cambio en mi lado. Bueno, no puedo reconstruir debido a posiblemente estos dos errores, incluido el de abajo, a diferencia de la última vez, que fue un error de espacio insuficiente. ¿Alguna idea de cómo superar este error de abajo?
Para añadir, también obtuve este mismo error exacto antes y después de aumentar el tamaño del disco principal (teniendo en cuenta las necesidades de postgres 15 > 18).
FAILED
--------------------
Pups::ExecError: if [ -f /root/install_postgres ]; then
/root/install_postgres && rm -f /root/install_postgres
elif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then
socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1
fi
failed with return #<Process::Status: pid 17 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in 'Pups::ExecCommand#spawn'
exec failed with the params {"tag" => "db", "cmd" => "if [ -f /root/install_postgres ]; then\n /root/install_postgres && rm -f /root/install_postgres\nelif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then\n socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1\nfi\n"}
Ah, de acuerdo, encontré lo que creo que necesito, publicado por @Lilly hace mucho tiempo en este tema.
cd /var/discourse
./launcher enter web_only
discourse backup
exit
A partir de esto, asumo que puedo generar una copia de seguridad de la base de datos utilizable que pueda subir a una nueva instancia de Discourse y evitar todos los problemas.
¿Ese comando generará una copia de seguridad completa, es decir, publicaciones + cargas/imagenes?
Recomendaría hacer una copia de seguridad solo de la base de datos y usar rsync para mover todo lo demás. Mover un sitio de Discourse a otro VPS con rsync. También puedes usar rsync para transferir los certificados SSL, de modo que puedas poner en marcha el nuevo sitio antes de cambiar el DNS.
Así es como lo hago yo: Changing Digital Ocean droplets with doctl (resize, floating ip, rename, etc) - Howto - Literate Computing Dashboard
EDICIÓN: Perdón. No sé si ya has resuelto tu problema. Si lo entiendo bien, lo más fácil es volver a la plantilla predeterminada, sin versión, y volver a compilar.
2 Me gusta
¿Reconstruiste el contenedor de datos (probablemente app en tu caso) dos veces, como se requiere?
(De paso, el mensaje de actualización indica reconstruir app, pero supongo que se refería a “el contenedor de base de datos que podría llamarse app o data” o ¿se refiere a ambos?)
Y un poco de retroalimentación: hace un tiempo intenté pasar de la versión 13 a la 15, pero falló varias veces y me quedé con la plantilla .13. Ahora que se ofrecía la versión .18, lo intenté de nuevo y funcionó sin problemas (solo tuve que limpiar los directorios _new y _older antes). Así que ahora puedo volver a usar la plantilla de datos por defecto sin versión. Buen trabajo al hacer la actualización tan robusta.
1 me gusta
Acabo de notar en el registro de errores que, antes de la actualización de PG, parece que había algunos errores relacionados con SQL en los registros:
Job exception: PG::UndefinedFunction: ERROR: function array_remove(bigint[], integer) does not exist LINE 1: ...ATE "access_control_lists" SET allowed_user_ids = array_remo...
Lo cual es extraño, ya que parece que esta función es de PG9, y yo estaba ejecutando la versión 15 antes. ¿Podría ser un problema de permisos o de ruta de búsqueda (search path)? Parece que no ocurre después de la actualización de la BD, pero tal vez sea un asunto de sincronización por lotes… Veo que la función se usa en bastantes lugares e incluso en scripts de migración.
Quizás eso signifique que algunas funciones fallan en versiones más antiguas de PostgreSQL, a pesar de que sus plantillas sigan listadas. Tal vez lo pasé por alto, pero pensaba que las versiones más antiguas eran compatibles.
1 me gusta