# After config change some settings not in sync on sibling nodes in multi-node discourse setup

**URL:** https://meta.discourse.org/t/after-config-change-some-settings-not-in-sync-on-sibling-nodes-in-multi-node-discourse-setup/372573
**Category:** Support
**Created:** [July 2, 2025, 4:32am UTC](https://meta.discourse.org/t/after-config-change-some-settings-not-in-sync-on-sibling-nodes-in-multi-node-discourse-setup/372573 "2025-07-02T04:32:38Z")
**Posts on this page:** 9
**Page:** 1

<div class="post-metadata">

### Author: ![kpums](https://avatars.discourse-cdn.com/v4/letter/k/9fc348/32.png) [@kpums](https://meta.discourse.org/u/kpums)
#### Post date: [July 2, 2025, 4:32am UTC](https://meta.discourse.org/t/after-config-change-some-settings-not-in-sync-on-sibling-nodes-in-multi-node-discourse-setup/372573/1 "2025-07-02T04:32:38Z")

</div>

Hello,

In multi node setup with web\_only container behind load-balancer noticed that some settings when changed are applied only on single node (probably the one to which I was connected through load-balancer when making changes). So noticed these specifically: `Global notice`, `Globally pinned posts` and now the latest, when changing theme to update custom one.

So in the end changes are represented to users only if load-balancer connect them to same node where they were made. Which leads to mixed page loads and messy site render in some cases.

Now the question. Do I need to run some config reload command in rake on all nodes after such changes or maybe some specific env variable needs to be added to container when running it, for auto-reloads/cluster-mode for config to be propagated to sibling nodes automatically?

---

<div class="post-metadata">

### Author: ![nat](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/nat/32/235063_2.png) [@nat](https://meta.discourse.org/u/nat)
#### Post date: [July 2, 2025, 5:02am UTC](https://meta.discourse.org/t/after-config-change-some-settings-not-in-sync-on-sibling-nodes-in-multi-node-discourse-setup/372573/2 "2025-07-02T05:02:50Z")

</div>

Yeah, you could try the following:

```plaintext
su discourse -c 'bundle exec rake cache:clear'

```

Alternatively if you want to go into the rails console, `SiteSetting.refresh!` would likely do the same thing but is more specific to site settings.

---

<div class="post-metadata">

### Author: ![kpums](https://avatars.discourse-cdn.com/v4/letter/k/9fc348/32.png) [@kpums](https://meta.discourse.org/u/kpums)
#### Post date: [July 2, 2025, 5:41am UTC](https://meta.discourse.org/t/after-config-change-some-settings-not-in-sync-on-sibling-nodes-in-multi-node-discourse-setup/372573/3 "2025-07-02T05:41:10Z")

</div>

Thanks! I had a feeling I was missing something there. Are there maybe some documentation article that mentions after which config changes such actions are required? Did a quick look at documentation articles and didn’t notice anything for that or HA setup specifically.

Edit: seems that the `cache:clear` is not available

```plaintext
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)

```

When checking with that `--tasks` I also do not see it.

---

<div class="post-metadata">

### Author: ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)
#### Post date: [July 2, 2025, 9:41am UTC](https://meta.discourse.org/t/after-config-change-some-settings-not-in-sync-on-sibling-nodes-in-multi-node-discourse-setup/372573/4 "2025-07-02T09:41:52Z")

</div>

Just checking: do you have a shared redis database between all nodes? That is essential for Discourse to work.

(some other applications work with one-redis-per-node, but trying to do that with Discourse will cause the kinds of issues you describe)

---

<div class="post-metadata">

### Author: ![kpums](https://avatars.discourse-cdn.com/v4/letter/k/9fc348/32.png) [@kpums](https://meta.discourse.org/u/kpums)
#### Post date: [July 2, 2025, 10:04am UTC](https://meta.discourse.org/t/after-config-change-some-settings-not-in-sync-on-sibling-nodes-in-multi-node-discourse-setup/372573/5 "2025-07-02T10:04:44Z")

</div>

Yes. Redis is shared by all discourse node instances. I created the setup to be HA, so there is separate S3/Redis/PostgreSQL.

---

<div class="post-metadata">

### Author: ![pangbo](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pangbo/32/538562_2.png) [@pangbo](https://meta.discourse.org/u/pangbo)
#### Post date: [July 3, 2025, 9:33am UTC](https://meta.discourse.org/t/after-config-change-some-settings-not-in-sync-on-sibling-nodes-in-multi-node-discourse-setup/372573/6 "2025-07-03T09:33:21Z")

</div>

Do you observe any error messages akin to `Global messages on xx timed out, message bus is no longer functioning correctly` within `/logs`?

Previously, I discovered that when Redis and the message bus run on separate hosts, timeouts occur, resulting in a failure to synchronize among different Unicorn workers.

My workaround was to periodically reload the entire Unicorn server.

---

<div class="post-metadata">

### Author: ![kpums](https://avatars.discourse-cdn.com/v4/letter/k/9fc348/32.png) [@kpums](https://meta.discourse.org/u/kpums)
#### Post date: [July 3, 2025, 11:49am UTC](https://meta.discourse.org/t/after-config-change-some-settings-not-in-sync-on-sibling-nodes-in-multi-node-discourse-setup/372573/7 "2025-07-03T11:49:01Z")

</div>

Grep’ed through logs on all nodes, not seeing such log entries.

---

<div class="post-metadata">

### Author: ![kpums](https://avatars.discourse-cdn.com/v4/letter/k/9fc348/32.png) [@kpums](https://meta.discourse.org/u/kpums)
#### Post date: [July 9, 2025, 6:01am UTC](https://meta.discourse.org/t/after-config-change-some-settings-not-in-sync-on-sibling-nodes-in-multi-node-discourse-setup/372573/8 "2025-07-09T06:01:14Z")

</div>

Ah. After all there were those `Global messages on xx timed out, message bus is no longer functioning correctly` messages. But I mistakenly looked in actual logs dir. Now when looking in web interface logs error section I actually did notice entries which you mentioned. Need to get used to fact that different errors show up in different places for discourse. Still nice to have features in discourse web side.

---

<div class="post-metadata">

### Author: ![AhmedLoud](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ahmedloud/32/576547_2.png) [@AhmedLoud](https://meta.discourse.org/u/AhmedLoud)
#### Post date: [April 10, 2026, 6:11pm UTC](https://meta.discourse.org/t/after-config-change-some-settings-not-in-sync-on-sibling-nodes-in-multi-node-discourse-setup/372573/9 "2026-04-10T18:11:12Z")

</div>

Hi @david I opened a PR [fix: subscriber thread never self heals after half open tcp connection by Mubramaj · Pull Request #388 · discourse/message\_bus · GitHub](https://github.com/discourse/message_bus/pull/388)

This PR addresses the `Global messages on xx timed out` and avoids the @pangbo workaround to periodically reload the entire Unicorn server