Discourse-Slave-Instanz mit Offline-Zugriff

Hintergrund
Wir haben eine in der Cloud gehostete Discourse-Instanz für die australische Ruby-Community (ich nenne sie Master). Zweimal im Jahr veranstalten wir RailsCamp-Events. Dabei verbringen wir ein ganzes Wochenende an einem abgelegenen Ort (50–150 Personen pro Event). Oft gibt es dort kaum oder gar keinen Mobilfunkempfang, was die Koordination erschwert.

Ich dachte mir, eine Discourse-Instanz, die während des Events im lokalen Netzwerk gehostet wird (ich nenne sie Slave), wäre ideal. Wir könnten sie nutzen, um Ankündigungen zu veröffentlichen, den Zeitplan zu teilen, Fotos hochzuladen usw.

Da wir auf Master bereits eine wachsende Community haben, wäre es großartig, diese zu nutzen. Zum Beispiel ist Ihr Profil bereits eingerichtet, wenn Sie beim Event ankommen, und Sie haben eine Kopie aller Inhalte.

Herausforderung
Wie kann die Slave-Discourse-Instanz parallel zur Master-Instanz laufen, wenn die Slave-Instanz drei Tage lang offline ist?

Vorgeschlagene Lösung
Ich verstehe, dass Discourse nicht dafür ausgelegt ist. Aber ich denke, es gibt einen Weg, um unsere Bedürfnisse zu erfüllen. Ich bin an Ihren Ideen dazu interessiert.

Der Plan:

  • Wir richten eine Slave-Discourse-Instanz im lokalen Netzwerk des Events ein.
  • Kurz vor dem Event sichern wir Master und stellen sie auf Slave wieder her.
  • Auf Slave:
    • Alle Kategorien werden als schreibgeschützt markiert.
    • Wir erstellen eine neue schreib-/lesefähige Kategorie für das Event.
  • Nach dem Event verwenden wir ein Ruby-Skript, um Informationen von Slave zu Master zu übertragen:
    • Neu erstellte Benutzer
    • Alle Themen und Beiträge aus der für das Event erstellten Kategorie
  • Ergebnis

Fragen

  • Sehen Sie Probleme mit der vorgeschlagenen Lösung?
  • Können Sie einen besseren Ansatz erkennen?

Es wäre großartig, auf Slave Schreibzugriff für alle Kategorien zu ermöglichen, aber ich habe das Gefühl, dass der Synchronisationsprozess sehr kompliziert werden könnte. Außerdem könnte das verwirrend sein, da einige Personen weiterhin auf Master zugreifen könnten, wenn sie Empfang haben.

Hello from a fellow Australian Rubyist… :wave:

This all sounds fine to me. To sync stuff up after the event I would recommend writing a small script that zooms through your read write categories and then makes API requests using our JSON API to create the topics / posts on the master.

I definitely recommend strongly against having any kind of merge topic scenario, it will be full of dragons and not worth the effort.

@antulik

Hast du bereits etwas Ähnliches ausprobiert?
Ich befinde mich in einer ähnlichen Situation, bei der ich Discourse offline mit Synchronisierung einsetzen muss.
Ich habe einen Master-Server und werde später mehr als 100–200 Slave-Instanzen haben. Die Slave-Instanzen können online oder offline sein, werden aber von Nutzern verwendet. Wenn eine offline Instanz wieder online geht, soll sie sich ohne Konflikte mit dem Master-Server synchronisieren und alle neuesten Daten aktualisieren können. Ich möchte keine Code-Änderungen vornehmen, da Discourse sich recht häufig aktualisiert und ich nicht möchte, dass Instanzen durch Code-Änderungen beschädigt werden.

Ich überlege, PostgreSQL in gewissem Umfang anzupassen. Andere datenbezogene Dateien können mit Syncthing synchronisiert werden. Das Synchronisieren von PostgreSQL-Daten macht mir jedoch Sorgen, denn wenn ich die Master-Daten direkt synchronisiere, gehen die von Offline-Nutzern durchgeführten Änderungen nach der Synchronisierung verloren. Wie war deine Erfahrung beim Schreiben von Skripten für diesen Zweck?

Wir haben es noch nicht gemacht, da wir an allen Veranstaltungsorten Internetzugang hatten.