# Primary node forwarding/failing over due to "Too many connections"

**URL:** <https://forums.percona.com/t/primary-node-forwarding-failing-over-due-to-too-many-connections/40258>\
**Category:** Other MySQL® Questions\
**Created:** [February 19, 2026, 3:11pm UTC](https://forums.percona.com/t/primary-node-forwarding-failing-over-due-to-too-many-connections/40258 "2026-02-19T15:11:42Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![SQLCaesar](https://avatars.discourse-cdn.com/v4/letter/s/9fc348/32.png) [@SQLCaesar](https://forums.percona.com/u/SQLCaesar)\
**Post date:** [February 19, 2026, 3:11pm UTC](https://forums.percona.com/t/primary-node-forwarding-failing-over-due-to-too-many-connections/40258/1 "2026-02-19T15:11:42Z")

</div>

Hi all,

I would like to discuss a common situation in a Galera Cluster setup where the intended primary writer (Node 1) stops accepting new requests, causing the loadbalancer to forward write traffic to Node 2. This results in an accidental multi-writer situation, which is undesirable for a specific application logic.

The error log on Node 1 shows a “Too many connections” alert. When this happens, the load balancer identifies Node 1 as saturated and fails over to the Node 2.

What is the best practice to ensure that Node 1 remains the sole writer even during connection spikes?

---

<div class="post-metadata">

**Author:** ![Wayne\_Leutwyler](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/wayne_leutwyler/32/20829_2.png) [@Wayne\_Leutwyler](https://forums.percona.com/u/Wayne_Leutwyler)\
**Post date:** [February 19, 2026, 7:54pm UTC](https://forums.percona.com/t/primary-node-forwarding-failing-over-due-to-too-many-connections/40258/2 "2026-02-19T19:54:32Z")

</div>

Just off the top of my head you could:

On **Node 2 (and Node 3…)** enable:

- `read_only=ON`
- `super_read_only=ON` (stronger; blocks even users with SUPER-like powers except internal threads)

**Reason this will help:** even if the Load Balancer sends writes to Node 2, they’ll fail immediately instead of silently becoming a second writer. Galera replication applier threads can still apply replicated transactions even when the node is `read_only/super_read_only`.

---

<div class="post-metadata">

**Author:** ![SQLCaesar](https://avatars.discourse-cdn.com/v4/letter/s/9fc348/32.png) [@SQLCaesar](https://forums.percona.com/u/SQLCaesar)\
**Post date:** [February 23, 2026, 9:11am UTC](https://forums.percona.com/t/primary-node-forwarding-failing-over-due-to-too-many-connections/40258/3 "2026-02-23T09:11:14Z")

</div>

Hi @Wayne_Leutwyler - thank you so much for your input.

Indeed, in our case, we were advised to increase the `max_connections` variable. This should provide the first node with enough resources to handle client spikes without triggering a (writing) failover to Node 2.

If there are no other suggestions, I will close this post with this conclusion. Thanks for the help!