Flushall de Redis

Comparto esto por si ayuda a alguien más que vea “Actualizando” en el panel de administración, aunque no haya ninguna actualización en curso y el foro parezca estar sano.

Aunque nunca afectó las actualizaciones del gestor de Docker, en las últimas versiones he tenido que hacer actualizaciones por CLI, ya que el panel de administración siempre parecía indicar que Discourse estaba actualizándose.

Mi foro es pequeño y no tiene plugins personalizados.

La solución para resolver el problema fue limpiar la caché de Redis.

Aunque no puedo compartir la causa subyacente, fue muy frustrante llegar al límite de mi conocimiento y comprensión del proceso de actualización de Discourse (esto no es una queja, es una admisión).

Hasta ahora, reconstruir la aplicación siempre había sido la solución fiable para prácticamente cualquier problema.

Redis también contiene sesiones de usuario y mucho más. Limpiar Redis por completo desconectará a todos y eliminará todos los trabajos pendientes de Sidekiq. Los trabajos programados solo se recuperarán después del siguiente reinicio.

Esto solo debería ser un último recurso e incluso entonces te animo a identificar qué claves específicas son las culpables en lugar de ejecutar un flushall. Esto es como prender fuego a todo un edificio porque quieres deshacerte de un ratón.

¿Podría reiniciarse Redis en su lugar? Creo que es una base de datos en memoria, por lo que nada se mantendría, por ejemplo, tras un reinicio del servidor. Y un reinicio del servidor no es destructivo (y podría ocurrir en cualquier momento).

Eso es incorrecto. Redis sí persiste en disco.

Agradezco tu perspectiva y experiencia.

Cosas que intenté:

Actualizar desde el panel de administración (falló/nunca comenzó)

Seguí los pasos manuales para actualizar Discourse (en las últimas 3 versiones)

Realicé varias reconstrucciones de la aplicación del lanzador.

Busqué en el foro un problema y solución similares.

Finalmente, recurrí a una consulta en ChatGPT que reveló opciones de Redis, aunque ChatGPT mismo dijo que era una solución poco probable (y sugirió las cosas que ya había intentado).

Esta fue la única acción que tomé y que resolvió el problema.

Entiendo la analogía.

¿Qué más podría haber hecho para comprender y resolver mejor el problema como alternativa?

Para aclarar, ¿encontraste que

cd /var/discourse
git pull
./launcher rebuild app

no funcionó para ti? (¿De qué manera no funcionó? ¿Es una instalación estándar?)

No se realizó el git pull, pero sí se reconstruyó la aplicación del lanzador.

Ese proceso funcionó correctamente, simplemente nunca se despejó la creencia del panel de administración de que había una actualización en curso.

Gracias, así que la observación es que la actualización del panel de administración no te está funcionando. Además, a mí tampoco me ha estado funcionando desde hace un tiempo. Sería mejor si funcionara.

Prefiero las actualizaciones por línea de comandos, pero esta vez actualicé Docker y Discourse desde la interfaz en mi iPhone 15 y funcionó bastante bien (instalación estándar en DO).

Por lo general, lo hago todo desde la CLI en una de mis computadoras, ya que la última vez que lo intenté por la interfaz falló (hace unos meses, así que igual tuve que conectarme por SSH de todos modos).

¿Qué devuelve free -h?

¿A qué está establecido UNICORN_WORKERS en app.yml?

¿A qué está establecido db_shared_buffers en app.yml?

¿Está db_work_mem comentado en app.yml?

¿Cuántas (v)CPU tiene tu servidor?

Free -h muestra 3.8Gi de memoria, 1.7Gi en uso, 134Mi libres, 1.0Gi compartidos, buff/cache 2.0Gi, disponible 788Mi

Swap 2.0Gi, 290Mi en uso, 1.7Gi libres

UNICORN_WORKERS: 4

db_shared_buffers 1GB

db_work_mem está comentado, configurado a 40MB

Estoy ejecutando una instancia de 2 vCPU y 4GB de RAM.

¡Gracias por las preguntas! :smiley: