Hola chicos.
¿Cómo se implementa un Discourse secundario/de reserva?
Pensé que sería un tema bastante común, pero no pude encontrar nada al respecto.
Dicho Discourse de reserva sería, obviamente, en mi opinión, por lo tanto, intentando configurarlo de esa manera, ejecutándose en nodo(s) esclavo/solo lectura, solo lectura tanto para Redis como para pgSQL. Pero Discourse falla al iniciarse con:
\u003e 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.
incluso con DISCOURSE_SKIP_BOOTSTRAP=yes
¿Cómo lo hacen ustedes? ¿Todo esto está en/sobre contenedores? ¿Es posible tener un Discourse de reserva de este tipo, de la manera en que lo estoy intentando o con cualquier otro enfoque, tener una configuración de alta disponibilidad (HA)?
Si quieres alta disponibilidad, configurarías postgres para que se replique, y quizás redis también, aunque no es un gran problema empezar con un redis nuevo.
Hay guías sobre cómo configurar la replicación de postgres en otros lugares. O podrías conseguir que rds lo haga por ti.
Por lo que entiendo, no existe tecnología oficial que no sea de terceros para hacer pgSQL multi-maestro y aún más que se aplique a Redis.
¿Realmente no es posible informarle a Discourse sobre dicho entorno y decirle que no se preocupe por ello y/o que lo ignore?
Si no lo es y @devel lee esto, entonces sugiero - creo que muchos lo agradecerán - “mejorar” Discourse de esa manera - para que haga todas las comprobaciones necesarias pero no falle, sino que se inicie y funcione con dichos “datos” de solo lectura.