Cluster-Vorlagenunterstützung [Hohe Verfügbarkeit] [Redundanz]

Beitragen Merkmal
1

Ich schlage folgende Ergänzungen für den Ordner templates vor:

  • postgres.master.yml
  • postgres.slave.yml
  • redis.master.yml
  • redis.slave.yml

Auf diese Weise verschwindet das Discourse-Clustering und die damit verbundene Qual rund um dieses Thema.

Meines Wissens kann der Redis-Container aufgrund einzigartiger Transaktionen im Message-Bus nicht dupliziert werden, scheint aber replizierbar zu sein.

Architektonische Vorteile?

  1. Möglichkeit, das Bootstrap (web.template.yml + web.template.yml + redis.master.yml) innerhalb des Master-Knotens und nur (web.template.yml + postgres.slave.yml + redis.slave.yml) innerhalb des Slave-Knotens durchzuführen, OHNE auf den Master-Knoten zurückzugreifen. Dies entlastet die Last erheblich und nutzt die Leistung des Nginx-Load-Balancers, der vor allen Knoten steht.

  2. Die ehrgeizige Unterstützung für einen Abschnitt zum Clustering in der Benutzeroberfläche innerhalb des Admin-Dashboards wird damit realisierbar!

Discourse ist wohl die fortschrittlichste Open-Source-Anwendung, die je erstellt wurde. Vielen Dank an das Team hinter diesem High-Tech-System.

3

Das wäre auch dann nützlich, wenn kein HA-Failover konfiguriert ist. Haben Sie einen PR mit vorgeschlagenen Inhalten für solche Dateien erstellt?

Wie würden Sie Datenbank-Updates auf neue Major-Versionen von Postgres verwalten, wenn Sie in dieser Weise über mehrere Knoten hinweg bereitstellen?