Come implementare Discourse secondario/di standby?

Installazione
1

Ciao ragazzi.
Come si distribuisce Discourse secondario/di riserva?
Pensavo fosse un argomento piuttosto comune ma non sono riuscito a trovare nulla al riguardo.

Un tale Discourse di riserva sarebbe - ovviamente, nella mia mente, quindi cercando di configurarlo in quel modo - in esecuzione su nodi slave/sola lettura, in sola lettura sia per Redis che per pgSQL. Ma Discourse non si avvia con:

Redis::CommandError: ERR Error running script (call to f_bcec1d9b3bbcfb089dc0b7316771be9f011872b6): @user_script:8: @user_script: 8: -READONLY You can’t write against a read only replica.

anche con DISCOURSE_SKIP_BOOTSTRAP=yes

Come fate voi ragazzi - questo è tutto in/su container - è possibile avere un Discourse di riserva in questo modo - nel modo in cui sto provando o con qualsiasi altro approccio - avere una configurazione aka HA?

2

Se vuoi alta disponibilità, dovrai configurare postgres per la replica, e forse anche redis, anche se non è un grosso problema iniziare con un nuovo redis.

Ci sono guide su come impostare la replica di postgres altrove. Oppure potresti far fare a rds per te.

Quindi dovresti configurare due container web_only (Spostare da container standalone a container web e dati separati.

Avresti quindi bisogno di haproxy o qualcosa di simile per gestire il passaggio.

È davvero al di là dell’aiuto che puoi ottenere qui, a meno che tu non sia bloccato sulla parte di discourse.

3

Per quanto ne so, non esiste una tecnologia ufficiale non di terze parti per fare multi-master pgSQL e ancor meno per Redis.

È davvero impossibile informare Discourse su un tale ambiente e dirgli di non preoccuparsene e/o di ignorarlo?
Se non lo è e @devel legge questo, allora suggerisco - molti, penso, apprezzeranno - di “migliorare” Discourse in quel modo - in modo che faccia tutti i controlli necessari ma non fallisca, ma si avvii e funzioni su tali “dati” di sola lettura.