Bereitstellung schlägt fehl - exec_command.rb:117:in `spawn

Installation
1

Hallo Leute.
Bevor ich hier mit langen Logs überlade, habe ich das unten eingefügt.
Die Bereitstellung schlägt jedes Mal auf diese Weise fehl. Kann mir jemand einen Vorschlag machen, was das Problem ist und wie ich es beheben kann? Ich wäre sehr dankbar.
…

I, [2023-06-20T14:08:40.997134 #1]  INFO -- : > cd /var/www/discourse & su discourse -c 'LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all'
I, [2023-06-20T14:08:43.104608 #1]  INFO -- : docker_manager ist bereits in der neuesten kompatiblen Version

I, [2023-06-20T14:08:43.104825 #1]  INFO -- : > cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate'
rake aborted!
Redis::CommandError: READONLY You can't write against a read only replica. script: bcec1d9b3bbcfb089dc0b7316771be9f011872b6, on @user_script:8.
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis/client.rb:162:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rack-mini-profiler-3.1.0/lib/mini_profiler/profiling_methods.rb:85:in `block in profile_method'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis.rb:270:in `block in send_command'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis.rb:269:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis.rb:269:in `send_command'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis/commands/scripting.rb:110:in `_eval'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis/commands/scripting.rb:97:in `evalsha'
/var/www/discourse/lib/discourse_redis.rb:273:in `eval'
/var/www/discourse/lib/distributed_mutex.rb:82:in `get_lock'
/var/www/discourse/lib/distributed_mutex.rb:50:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:34:in `synchronize'
/var/www/discourse/lib/tasks/db.rake:221:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => db:migrate
(See full trace by running task with --trace)
I, [2023-06-20T14:08:45.555646 #1]  INFO -- :

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 687 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
1 „Gefällt mir“
2

Auhh.. das ist Redis – als Anfänger hat es eine Weile gedauert – richtig?
Aber wenn ja, wie kann man es so bereitstellen, dass man daran denkt und es als „Standby-Replika“ bezeichnet? – ja, eine solche Discourse-Instanz meine ich.

3

Ist dies eine Standardinstallation, eine Entwicklungsinstallation oder etwas anderes? Haben Sie Ihr eigenes Redis erstellt? Bei einer Standardinstallation sollte Redis im Container sein und einfach funktionieren.

1 „Gefällt mir“
4

Hallo.
Ich habe nicht erwähnt – ich ging davon aus und tue dies immer noch –, dass das, was ich versuche, nicht ungewöhnlich ist – dass sowohl Redis als auch pgSQL extern zum Discourse-Container sind.
Ist es möglich, Discourse auf eine mehr oder weniger Standardweise als „Standby“ bereitzustellen – auf die gleiche oder eine ähnliche Weise wie Redis –, damit eine solche Container-Instanziierung/-Bereitstellung nicht fehlschlägt?

1 „Gefällt mir“
5

Ja, aber Sie müssen Ihren Redis-Server selbst debuggen.

Der Fehler lautet

Sie können nicht gegen eine schreibgeschützte Replik schreiben

Es sieht so aus, als hätten Sie eine Replik erstellt und Sie müssen in die Hauptinstanz schreiben. Wenn Sie ein Failover versuchen, müssen Sie herausfinden, wie Sie die Replik zur aktiven Instanz machen und sie aufhören lassen, eine Replik zu sein.

Dafür müssen Sie woanders Hilfe suchen.

6

Ja. Aber Fail-over ist hier nicht das Problem, noch nicht.
Hier versuche ich, einen solchen “Standby/Sekundär”-Discourse-Container auf einem anderen, separaten Knoten/System zu instanziieren, bei dem sowohl Redis als auch pgSQL solche Read-Only-Replikate sind – wie mache ich das?

Der Fehler ist selbsterklärend und die offensichtliche Frage ist – für mich, da dies mein allererster Ausflug in Discourse ist – wie man einen solchen “Hot-Standby”-Container bereitstellt und ausführt, wenn das überhaupt möglich ist.

7

Sie müssen Discourse so einrichten, dass es das primäre System verwendet. Wenn dies fehlschlägt, sollten Sie DNS oder HAProxy verwenden, um auf das sekundäre System umzuschalten.

Dies ist kein Discourse-Problem. Wenn Sie lernen möchten, wie Sie Redis und PostgreSQL in einer Hochverfügbarkeitskonfiguration verwalten, müssen Sie woanders suchen.