J’exécute la commande ./launcher rebuild app
redis est maintenant prêt à quitter, au revoir... bloque Discourse pendant 40 minutes, puis j’arrête avec Ctrl + C.
Cela charge indéfiniment. En conséquence, nous n’avons pas créé de nouveau conteneur. Pourriez-vous expliquer quels types de journaux dans Discourse pourraient nous aider à identifier la cause ?
Cela pourrait-il être un problème d’allocation de ressources ?
Y a-t-il d’autres sites web ou services hébergés sur ce serveur ? Quelle quantité de RAM/CPU est disponible sur votre serveur ?
C’est normal.
Ce ne l’est pas. En général, le nouveau conteneur démarre moins d’une minute après ce message.
Et vous avez essayé cela plus d’une fois avec le même résultat ?
Oui, plusieurs fois, avec le même résultat
Était sur une branche 3d050bdaa31633a954758894629c0eb9fea537d0
Je souhaite passer à fe71c43c57c0248a8264245cb6ff0dc114da335a
et cela bloque Discourse !!
production.log
Erreur de connexion à Redis sur localhost:6379 (Errno::ENETUNREACH) échec de l'abonnement, nouvelle tentative dans 1 seconde. Stack d'appels ["/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:363:in `rescue in establish_connection'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:344:in `establish_connection'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:106:in `block in connect'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:307:in `with_reconnect'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:105:in `connect'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:382:in `ensure_connected'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:231:in `block in process'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:320:in `logging'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:230:in `process'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:139:in `block in call_loop'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:293:in `with_socket_timeout'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:138:in `call_loop'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/subscribe.rb:44:in `subscription'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/subscribe.rb:13:in `subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:3468:in `_subscription'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:2301:in `block in subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:51:in `block in synchronize'", "/usr/local/lib/ruby/2.6.0/monitor.rb:235:in `mon_synchronize'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:51:in `synchronize'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:2300:in `subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus/backends/redis.rb:287:in `global_subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus.rb:741:in `global_subscribe_thread'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus.rb:689:in `block in new_subscriber_thread'"]
Exception de tâche : Erreur de connexion à Redis sur localhost:6379 (Errno::ENETUNREACH)
Exception de tâche : Erreur de connexion à Redis sur localhost:6379 (Errno::ENETUNREACH)
Exception de tâche : Erreur de connexion à Redis sur localhost:6379 (Errno::ENETUNREACH)
Exception de tâche : Erreur de connexion à Redis sur localhost:6379 (Errno::ENETUNREACH)
Exception de tâche : Erreur de connexion à Redis sur localhost:6379 (Errno::ENETUNREACH)
Exception de tâche : Erreur de connexion à Redis sur localhost:6379 (Errno::ENETUNREACH)
Exception de tâche : Erreur de connexion à Redis sur localhost:6379 (Errno::ENETUNREACH)
Erreur de connexion à Redis sur localhost:6379 (Errno::ENETUNREACH) échec de l'abonnement, nouvelle tentative dans 1 seconde. Stack d'appels ["/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:363:in `rescue in establish_connection'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:344:in `establish_connection'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:106:in `block in connect'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:307:in `with_reconnect'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:105:in `connect'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:382:in `ensure_connected'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:231:in `block in process'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:320:in `logging'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:230:in `process'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:125:in `call'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:915:in `block in get'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:51:in `block in synchronize'", "/usr/local/lib/ruby/2.6.0/monitor.rb:235:in `mon_synchronize'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:51:in `synchronize'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:914:in `get'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus/backends/redis.rb:360:in `process_global_backlog'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus/backends/redis.rb:271:in `block in global_subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus/backends/redis.rb:284:in `global_subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus.rb:741:in `global_subscribe_thread'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus.rb:689:in `block in new_subscriber_thread'"]
Exception de tâche : Erreur de connexion à Redis sur localhost:6379 (Errno::ENETUNREACH)
Création de la portée :visible_groups. Écrasement de la méthode existante Group.visible_groups.
Création de la portée :visible. Écrasement de la méthode existante Notification.visible.
Création de la portée :public_posts. Écrasement de la méthode existante Post.public_posts.
Création de la portée :private_posts. Écrasement de la méthode existante Post.private_posts.
Création de la portée :open. Écrasement de la méthode existante Poll.open.
Migration vers CreateDiscourseVotingCategorySettings (20200727220143)
Migration vers CreateDiscourseVotingVotes (20200728222920)
Migration vers CreateDiscourseVotingTopicVoteCount (20200729042607)
Création de la portée :visible_groups. Écrasement de la méthode existante Group.visible_groups.
Création de la portée :visible. Écrasement de la méthode existante Notification.visible.
Création de la portée :public_posts. Écrasement de la méthode existante Post.public_posts.
Création de la portée :private_posts. Écrasement de la méthode existante Post.private_posts.
Création de la portée :open. Écrasement de la méthode existante Poll.open.
Création de la portée :visible_groups. Écrasement de la méthode existante Group.visible_groups.
Création de la portée :visible. Écrasement de la méthode existante Notification.visible.
Création de la portée :public_posts. Écrasement de la méthode existante Post.public_posts.
Création de la portée :private_posts. Écrasement de la méthode existante Post.private_posts.
Création de la portée :open. Écrasement de la méthode existante Poll.open.
Ubuntu 14.04 semble assez ancien. J’ai vu ces dernières semaines plusieurs publications signalant des problèmes à ce sujet :
https://meta.discourse.org/search?q=14.04%20order%3Alatest
Peut-être qu’une mise à jour d’une dépendance entre mai et maintenant a causé un dysfonctionnement 
Merci pour les réponses.
J’ai un nouveau serveur avec Ubuntu 20.04.1 LTS et Docker installé dessus.
Comment puis-je déplacer mon ancien forum de production sur ce serveur ?
Pourriez-vous me suggérer des guides étape par étape ?
Construisez à partir de zéro en suivant le guide standard. Copiez le fichier app.yml. Reconstruisez. Importez le fichier de sauvegarde Discourse depuis le premier serveur. C’est tout.
(Et n’oubliez pas la petite question de la réaffectation de l’adresse IP pour le domaine !)
C’est cool, mais la création de sauvegardes via le panneau d’administration ne fonctionne pas pour nous 
Transfert du conteneur Docker
docker ps -a
docker commit c559bec6f29a local_discourse/app
docker save local_discourse/app > /tmp/local_discourse_app.tar.gz
scp /tmp/local_discourse_app.tar.gz root@mon-nouveau-serveur:/tmp/
---
docker load < /tmp/local_discourse_app.tar.gz
docker run local_discourse/app
Des problèmes surviennent à cette étape - NoMethodError on docker run - #8 by Dev_Work
Vous n’avez aucune sauvegarde existante hors site ?
J’ai besoin d’une copie avec des données à jour (pas de sauvegardes récentes)
Salut @Dev_Work
Désolé d’apprendre que vous rencontrez des problèmes avec cela.
Donc, pour résumer :
discourse-2020-08-24-103334-v20200811004537.tar.gz
https://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md
Vous avez fait cela sur un tout nouveau serveur Ubuntu 20.04.1 LTS avec Docker installé et testé.
Puis vous avez restauré manuellement la sauvegarde ci-dessus sur le nouveau serveur, c’est bien ça ?
Est-ce exact, et êtes-vous à ce stade de l’opération ?
Merci pour la réponse. Oui, c’est exact, un problème survient sur la nouvelle version Ubuntu 20.04.1 LTS.
Avez-vous créé un administrateur avec le nom d’utilisateur “pavel_BLANKEDOUT” avant de tenter le processus de restauration manuelle de Discourse ?
Je suppose que ce n’est pas le problème, je pose simplement la question pour couvrir tous les aspects, puisque l’utilisateur “pavel_BLANKEDOUT” est mentionné dans votre erreur de clé dupliquée.
Non, n’a pas été créé.
Utilisateur admin qui n’est pas dans la base de données de sauvegarde.
Salut @Dev_Work
Et votre site d’origine, celui dont la sauvegarde utilisée est complètement hors ligne ?
Ou pouvez-vous accéder au conteneur de votre ancien site et vérifier la base de données Discourse pour un index corrompu ?
De plus, quelle version de PostgreSQL exécutait votre ancienne instance défectueuse ? 10 ou 12 ?
Cela ressemble à mon problème, Search results for 'could not create unique index category:6' - Discourse Meta
pleure 
ERREUR : impossible de créer l'index unique "index_user_emails_on_email"
DÉTAIL : La clé (lower(email::text))=(andrii_test@local.com) est en double.
EXCEPTION : psql a échoué : DÉTAIL : La clé (lower(email::text))=(andrii_test@local.com) est en double.
/var/www/discourse/lib/backup_restore/database_restorer.rb:95:in `restore_dump'
/var/www/discourse/lib/backup_restore/database_restorer.rb:26:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:49:in `run'
script/discourse:143:in `restore'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor.rb:392:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/base.rb:485:in `start'
script/discourse:284:in `<top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `kernel_load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:28:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:476:in `exec'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor.rb:399:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:30:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/base.rb:476:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:24:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:46:in `block in <top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/friendly_errors.rb:123:in `with_friendly_errors'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:34:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Ancien serveur utilisant PostgreSQL 12
Ancien site et serveur fonctionnels
Je peux accéder au conteneur de l’ancien site (comment vérifier un index corrompu ?)