Bootstrap Container se bloque sur su discourse -c 'bundle exec rake db:migrate'

Contribuer Bug
1

Nous exécutons actuellement cette version récente :

Elle tourne toujours dans notre conteneur de production (aucun problème).

J’essaie de démarrer une nouvelle instance à partir de cette version :

J’ai essayé plusieurs fois aujourd’hui, et à chaque fois, le processus se bloque ici :

Screen Shot 2021-02-11 at 5.32.24 PM

J’ai vérifié les journaux dans le conteneur de données et dans le conteneur de l’application de secours (nous sommes en cours de démarrage), mais il n’y a aucune erreur ni aucun problème.

À chaque fois que je lance le démarrage, il se bloque sur cette ligne :

I, [2021-02-11T10:37:25.133098 #1]  INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'

Avez-vous des pistes pour savoir où chercher afin de déboguer cela ?

J’ai examiné tous les journaux auxquels j’ai pu penser (dans tous les conteneurs), mais je n’ai trouvé aucun problème.

Merci.

Informations supplémentaires :

À chaque fois que le processus se bloque et que je fais Ctrl+C pour l’arrêter, il semble laisser un processus postmaster, que je peux ensuite tuer.

Voici un exemple :

Screen Shot 2021-02-11 at 5.49.42 PM
Screen Shot 2021-02-11 at 5.49.42 PM847×188 65.8 KB

Mise à jour :

Le démarrage se déroule correctement si je commente la ligne « db:migrate » dans le modèle web.

Il y a un problème étrange avec « rails db:migrate » qui se bloque sans aucune erreur, ce que je n’ai jamais rencontré auparavant.

Je me demande s’il y a une erreur (ou un problème sous-jacent) dans cette migration récente ?

Voir également :

2

Bonjour @neounix, nous sommes au courant du problème lié à la migration que vous avez partagée et nous travaillons actuellement sur une correction.

2 « J'aime »
3

Bonjour @david,

Merci pour ta réponse !

Je venais d’examiner la migration, et ma première pensée, en tant que « non-expert des migrations de base de données Discourse », était que cela pourrait être le problème ?

 add_index :dismissed_topic_users, %i(user_id topic_id), unique: true

Quoi qu’il en soit, je ne suis pas qualifié pour approfondir davantage les problèmes de migration Discourse, donc je me retire et reste à disposition.

Merci encore !

4

Pouvons-nous annuler en toute sécurité la migration sans perte de données et revenir à quelques commits en arrière ?

Cela a fonctionné.

1 « J'aime »
5

Salut @neounix,

désolé d’avoir inclus cette migration lourde et défectueuse dans la base de code. Ces modifications ont été annulées, donc un nouveau déploiement devrait fonctionner :

4 « J'aime »
6

Bonjour @kris.kotlarek,

Merci pour la mise à jour :

Je suis enclin à convenir que cette « migration lourde » nécessite très probablement un examen supplémentaire et des tests de développement rigoureux sur une configuration de test avec une base de données volumineuse avant d’être fusionnée dans le noyau. Heureusement pour notre site, j’ai toujours procédé à un démarrage en parallèle avec la production, nous n’avons donc subi aucune interruption de service lors des échecs de migration. Pas de souci de notre côté. Merci d’avoir annulé si rapidement.

Pour information uniquement (je fais juste preuve de précision technique, désolé pour cela…), j’ai vérifié la base de données juste après la reconstruction et le processus d’« annulation » n’a pas supprimé la table de la base de données. Ce n’est pas grave, juste pour info :

discourse=\d dismissed_topic_users

                                        Table "public.dismissed_topic_users"
   Column   |            Type             | Collation | Nullable |                      Default                      
------------+-----------------------------+-----------+----------+---------------------------------------------------
 id         | bigint                      |           | not null | nextval('dismissed_topic_users_id_seq'::regclass)
 user_id    | integer                     |           |          | 
 topic_id   | integer                     |           |          | 
 created_at | timestamp without time zone |           |          | 
Indexes:
    "dismissed_topic_users_pkey" PRIMARY KEY, btree (id)
    "index_dismissed_topic_users_on_user_id_and_topic_id" UNIQUE, btree (user_id, topic_id)

Merci encore pour votre travail acharné à ce sujet et pour avoir annulé la migration si rapidement.

2 « J'aime »
7

Cette migration se déroule désormais sans heurts, selon le dernier commit :

4 « J'aime »
8

Ce sujet a été automatiquement fermé après 6 jours. De nouvelles réponses ne sont plus autorisées.