In een multi-node-setup met een web_only-container achter een load-balancer is opgemerkt dat sommige instellingen, wanneer ze worden gewijzigd, alleen op een enkele node worden toegepast (waarschijnlijk degene waarmee ik via de load-balancer was verbonden toen de wijzigingen werden aangebracht). Dit is specifiek opgemerkt bij: Global notice, Globally pinned posts en nu het laatste, bij het wijzigen van het thema om een aangepast thema bij te werken.
Uiteindelijk worden wijzigingen dus alleen aan gebruikers gepresenteerd als de load-balancer hen verbindt met dezelfde node waar ze zijn aangebracht. Dit leidt in sommige gevallen tot gemengde paginaloads en een rommelige site-rendering.
Nu de vraag. Moet ik na dergelijke wijzigingen een config reload-commando uitvoeren in rake op alle nodes, of moet er misschien een specifieke omgevingsvariabele aan de container worden toegevoegd bij het uitvoeren ervan, voor automatische herlaadacties/cluster-modus zodat de configuratie automatisch naar sibling nodes wordt doorgegeven?
Als alternatief, als je de rails console wilt openen, zou SiteSetting.refresh! waarschijnlijk hetzelfde doen, maar is specifieker voor site-instellingen.
Bedankt! Ik had het gevoel dat ik daar iets miste. Zijn er misschien documentatieartikelen die vermelden na welke configuratiewijzigingen dergelijke acties vereist zijn? Ik heb de documentatieartikelen snel bekeken en merkte niets op voor die of HA-setup specifiek.
Bewerken: het lijkt erop dat cache:clear niet beschikbaar is
docker exec -it web_only bash
root@discourse-build-web-only:/# cd /var/www/discourse
root@discourse-build-web-only:/var/www/discourse# su discourse -c 'bundle exec rake cache:clear'
rake aborted!
Don't know how to build task 'cache:clear' (See the list of available tasks with `rake --tasks`)
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.3.0/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
(See full trace by running task with --trace)
Wanneer ik controleer met --tasks zie ik het ook niet.
Even ter controle: hebben jullie een gedeelde redis-database tussen alle nodes? Dat is essentieel voor Discourse om te werken.
(sommige andere applicaties werken met één-redis-per-node, maar proberen dat met Discourse te doen, zal de soort problemen veroorzaken die je beschrijft)
Ziet u foutmeldingen zoals Global messages on xx timed out, message bus is no longer functioning correctly in /logs?
Eerder ontdekte ik dat wanneer Redis en de message bus op aparte hosts draaien, er time-outs optreden, wat resulteert in een mislukte synchronisatie tussen verschillende Unicorn-workers.
Mijn tijdelijke oplossing was om de hele Unicorn-server periodiek opnieuw te laden.
Ah. Er waren toch die berichten Global messages on xx timed out, message bus is no longer functioning correctly. Maar ik keek per ongeluk in de daadwerkelijke logmap. Nu ik in de logsectie van de webinterface kijk, zie ik inderdaad de vermeldingen die je noemde. Ik moet nog wennen aan het feit dat verschillende fouten op verschillende plaatsen verschijnen voor Discourse. Toch fijn om functies te hebben aan de Discourse-webside.