Dans une configuration multi-nœuds avec un conteneur web_only derrière un équilibreur de charge, j’ai remarqué que certains paramètres, une fois modifiés, ne s’appliquaient qu’à un seul nœud (probablement celui auquel j’étais connecté via l’équilibreur de charge lors des modifications). J’ai spécifiquement remarqué ceci pour : Global notice, Globally pinned posts et, plus récemment, lors du changement de thème pour en mettre un personnalisé.
En fin de compte, les changements ne sont représentés aux utilisateurs que si l’équilibreur de charge les connecte au même nœud où ils ont été effectués. Cela conduit à des chargements de page mixtes et à un rendu de site désordonné dans certains cas.
Maintenant, la question. Dois-je exécuter une commande de rechargement de configuration dans rake sur tous les nœuds après de telles modifications, ou une variable d’environnement spécifique doit-elle être ajoutée au conteneur lors de son exécution, pour que les rechargements automatiques/le mode cluster propagent automatiquement la configuration aux nœuds frères ?
Merci ! J’avais l’impression qu’il me manquait quelque chose. Y a-t-il peut-être un article de documentation qui mentionne après quels changements de configuration de telles actions sont nécessaires ? J’ai rapidement consulté les articles de documentation et je n’ai rien remarqué à ce sujet ou spécifiquement pour la configuration HA.
Je vérifie juste : avez-vous une base de données Redis partagée entre tous les nœuds ? C’est essentiel pour que Discourse fonctionne.
(certaines autres applications fonctionnent avec un redis par nœud, mais essayer de faire cela avec Discourse causera le genre de problèmes que vous décrivez)
Oui. Redis est partagé par toutes les instances de nœuds Discourse. J’ai créé la configuration pour qu’elle soit HA, donc il y a des S3/Redis/PostgreSQL séparés.
Observez-vous des messages d’erreur similaires à Global messages on xx timed out, message bus is no longer functioning correctly dans /logs ?
Auparavant, j’ai découvert que lorsque Redis et le bus de messages s’exécutent sur des hôtes distincts, des délais d’attente se produisent, entraînant une défaillance de synchronisation entre différents workers Unicorn.
Ma solution de contournement consistait à recharger périodiquement l’ensemble du serveur Unicorn.
Ah. Après tout, il y avait ces messages Global messages on xx timed out, message bus is no longer functioning correctly. Mais j’avais regardé par erreur dans le répertoire des logs réel. Maintenant, en regardant dans la section des erreurs des logs de l’interface web, j’ai effectivement remarqué les entrées que vous avez mentionnées. Il faut s’habituer au fait que différentes erreurs apparaissent à différents endroits pour Discourse. C’est quand même bien d’avoir des fonctionnalités du côté web de Discourse.