Impossible de restaurer car sidekiq ne lâche pas

J’ai un site qui tourne dans ECS avec RDS. J’essaie de restaurer la base de données (comme décrit ici : Restore failed `entity2char already exists' RDS Postgres 13.7 - #7 by RGJ).

Le problème à ce stade est que la sauvegarde ne démarre pas car elle attend sidekiq. Elle prétend attendre 60 secondes, mais j’ai attendu 60 minutes et elle n’a jamais arrêté d’attendre.

Ensuite, j’ai décidé de supprimer, créer, migrer la base de données avant la restauration (je suis à peu près sûr que c’est ce qui a fonctionné la dernière fois), mais je ne peux toujours pas supprimer la base de données car 6 tâches l’ont ouverte.

SELECT application_name,client_addr FROM pg_stat_activity;

Montre ceci (et il y a 6 sidekiqs avec des connexions actives)

 psql                                  | 10.3.2.155
 PostgreSQL JDBC Driver                | 127.0.0.1
                                       | 127.0.0.1
 sidekiq 6.5.8 discourse [0 of 5 busy] | 10.3.2.155
 sidekiq 6.5.8 discourse [0 of 5 busy] | 10.x.2.155
 sidekiq 6.5.8 discourse [0 of 5 busy] | 10.x.2.34
 sidekiq 6.5.8 discourse [0 of 5 busy] | 10.x.2.155
 sidekiq 6.5.8 discourse [0 of 5 busy] | 10.x.2.155
 sidekiq 6.5.8 discourse [0 of 5 busy] | 10.x.2.34

Une de ces adresses est l’ECS, l’autre un conteneur que j’ai démarré dans un EC2. Dans les deux conteneurs, j’ai fait un sv stop unicorn, ce qui dans d’autres contextes a suffi pour pouvoir supprimer la base de données.

Oh. Et maintenant, j’ai arrêté le conteneur sur l’EC2, donc ces connexions doivent juste être bloquées puisqu’il s’est arrêté sans les fermer ? Peut-être que je dois redémarrer la base de données à nouveau. (Redémarrer la base de données a arrêté ces connexions, et maintenant elle n’affiche que des connexions inactives du unicorn arrêté).

Que dois-je faire pour tuer sidekiq ? Dois-je aller dans redis et tout effacer ? (Je l’ai déjà fait et je peux chercher sur Google pour le comprendre à nouveau).

Vous devez simplement arrêter toutes les instances (conteneurs, licornes) qui exécutent un sidekiq.

C’est ce que j’aurais pensé, mais même après avoir arrêté le conteneur exécutant sidekiq, postgres affichait toujours des connexions actives. De même, j’avais fait un sv stop unicorn sur l’instance ECS, mais postgres affichait toujours des connexions actives.

J’ai redémarré le serveur RDS, lancé le conteneur sur l’EC2 (les instances dans ECS n’ont pas assez d’espace disque pour une restauration), sv stop unicorn, puis j’ai supprimé, créé et restauré la base de données, et maintenant, je tente une restauration.

Merci beaucoup pour votre aide. J’apprécie vraiment !

1 « J'aime »