La actualización tarda aproximadamente 20 minutos y la actualización del progreso se detiene (temporalmente) en el paso multisite:migrate

Acabo de hacer la actualización semanal de nuestro sitio de Discourse y descubrí que, en lugar de tomar los 1-2 minutos habituales, esta vez se necesitaron unos 20 minutos. Además, la actualización de progreso se interrumpió temporalmente con errores de tiempo de espera agotado en la consola de Chrome en el paso $ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate (captura de pantalla a continuación).

Pude ver en el servidor que algo estaba sucediendo (carga en postmaster y ocasionalmente en ruby), y finalmente las actualizaciones de progreso se recuperaron, pero en general parece que podría haber un problema con las migraciones actuales.

Según los registros de actualización, parece que la migración responsable del largo tiempo de ejecución fue DropTrgmIndexesOnUsers. He incluido la parte respectiva del registro directamente en esta publicación a continuación (el registro completo se adjunta como un archivo de texto en caso de que se necesite para un análisis adicional).

********************************************************
*** Por favor, tenga paciencia, los próximos pasos pueden tardar un tiempo ***
********************************************************
...
$ LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all
discourse-bbcode ya está en la última versión compatible
discourse-data-explorer ya está en la última versión compatible
docker_manager ya está en la última versión compatible
$ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate
El migrador multisite se está ejecutando usando 1 hilos

Migrando predeterminado
== 20240912061702 DropUserSearchSimilarResultsSiteSetting: migrando ==========
-- execute("DELETE FROM site_settings WHERE name = 'user_search_similar_results';\n")
   -> 0.0006s
== 20240912061702 DropUserSearchSimilarResultsSiteSetting: migrado (0.0015s) ==

== 20240912061806 DropTrgmIndexesOnUsers: migrando ===========================
-- execute("DROP INDEX IF EXISTS index_users_on_username_lower_trgm;\nDROP INDEX IF EXISTS index_users_on_name_trgm;\n")
   -> 1290.7163s
== 20240912061806 DropTrgmIndexesOnUsers: migrado (1290.7169s) ===============

== 20240912212253 IncreaseExternalAvatarUrlLimitTo2000: migrando =============
-- change_column(:single_sign_on_records, :external_avatar_url, :string, {:limit=>2000})
   -> 0.0011s
== 20240912212253 IncreaseExternalAvatarUrlLimitTo2000: migrado (0.0017s) ====

Sembrando predeterminado
*** Empaquetando activos. Esto llevará un tiempo *** 
$ bundle exec rake themes:update assets:precompile
Construyendo
Entorno: producción
construyendo...
...

Registro completo: upgrade-log-2024-09-15.txt (124.7 KB)

No estoy seguro de que podamos hacer algo ahora.

Necesitamos eliminar el índice y si tu foro estaba muy ocupado en ese momento, puede llevar un tiempo.

¿Asumimos que todo está bien ahora?

Sí, las cosas han vuelto a la normalidad, así que no hay ningún problema inmediato.

La razón principal por la que lo informé aquí fue que el indicador de progreso se rompió temporalmente, y eso es quizás algo que podría hacer que la gente creyera que la actualización se ha bloqueado (no estoy seguro de cuánto se puede hacer realmente aquí).

Sin embargo, este no fue el caso. El servidor es un servidor de prueba (necesitamos hacer bastante preparación) y normalmente ejecuto las actualizaciones después de la medianoche, así que creo que probablemente era el único usuario.

Así que la otra pregunta que se me ocurrió después es: ¿Discourse requiere efectivamente un SSD para comunidades como la nuestra (~6k usuarios, ~2.5M publicaciones)? Porque el servidor actual es decente (AMD Ryzen 5 3600, 64GB RAM), pero tiene discos giratorios clásicos y si eso es un problema, necesitaríamos cambiar a uno con SSD antes de salir en vivo.

Eliminar ese índice en un servidor con solo 6k usuarios debería tomar milisegundos, incluso en un disco duro giratorio; es un fuerte indicador de que su base de datos está escasa de recursos.

Ok, ¡gracias! No sabía que se requeriría ajuste de la base de datos (estamos usando la configuración de contenedor único) y no hay mucho más ejecutándose en la máquina (Discourse, Mailcow, Traefik, Crowdsec). Pero le echaré un vistazo más de cerca.

¿Alguna indicación sobre la documentación relevante a este respecto? Lo único que sé ahora mismo es Configure Discourse Docker on servers with more RAM and CPU, y nuestro db_shared_buffers ya está en 4096MB.

Sospecho que esto se debe a que no eliminamos el índice de forma concurrente.

Un DROP INDEX normal adquiere un bloqueo ACCESS EXCLUSIVE en la tabla, bloqueando otros accesos hasta que se pueda completar la eliminación del índice.

Esto debería corregirse en PERF: Update migration to drop index concurrently. by tgxworld · Pull Request #28955 · discourse/discourse · GitHub.

@schneeland Gracias por tomarte el tiempo de informar del problema :+1:

2 Me gusta