Murmur 1.2.19 unable to recover from timeout on DB connection with DB on HA solution #1632

Closed
opened 2026-02-20 21:08:45 -05:00 by deekerman · 3 comments
Owner

Originally created by @Glowsome on GitHub (Sep 15, 2019).

Situation :

  • Murmur 1.2.19 running on server 1
  • MySQL backend running on Server 2 , situated on HA cluster VM (Proxmox V6.x) with shared storage.
  • Database correctly configured for murmur, and functional.

Behaviour :

  • Migrate MySQL backend server to another node (usually takes like a few seconds)
  • Murmur daemon receives a timeout on the database connection while migration is in progress
  • murmur daemon never recovers from the connection loss, daemon keeps running but throws error 'unable to connect on database' and will not allow clients to connect to server untill server daemon is manually reloaded/restarted.

Suggestions to solve :

  • Implement an option for 'cluster-awareness' regarding database, increasing timeout option for connection to database.
  • increase time before throwing a fatal to reconnect database ( in conjunction to cluster-awareness)
  • buffer database info in murmur to not loose functionality while a/the database is migrating in the background (or possibly in a non-clustered env a/the database-server is restarting)

Remark :
As this is experienced on version 1.2.9 and we are now at new release 1.3.0 but have not migrated to it due to another bug, so i have yet to investigate the behavior on 1.3.0

Originally created by @Glowsome on GitHub (Sep 15, 2019). Situation : - Murmur 1.2.19 running on server 1 - MySQL backend running on Server 2 , situated on HA cluster VM (Proxmox V6.x) with shared storage. - Database correctly configured for murmur, and functional. Behaviour : - Migrate MySQL backend server to another node (usually takes like a few seconds) - Murmur daemon receives a timeout on the database connection while migration is in progress - murmur daemon never recovers from the connection loss, daemon keeps running but throws error 'unable to connect on database' and will not allow clients to connect to server untill server daemon is manually reloaded/restarted. Suggestions to solve : - Implement an option for 'cluster-awareness' regarding database, increasing timeout option for connection to database. - increase time before throwing a fatal to reconnect database ( in conjunction to cluster-awareness) - buffer database info in murmur to not loose functionality while a/the database is migrating in the background (or possibly in a non-clustered env a/the database-server is restarting) Remark : As this is experienced on version 1.2.9 and we are now at new release 1.3.0 but have not migrated to it due to another bug, so i have yet to investigate the behavior on 1.3.0
deekerman 2026-02-20 21:08:45 -05:00
  • closed this issue
  • added the
    bug
    server
    labels
Author
Owner

@Krzmbrzl commented on GitHub (Jun 6, 2020):

As this is experienced on version 1.2.9 and we are now at new release 1.3.0 but have not migrated to it due to another bug, so i have yet to investigate the behavior on 1.3.0

Did you migrate yet? If so: does the problem persist?

@Krzmbrzl commented on GitHub (Jun 6, 2020): > As this is experienced on version 1.2.9 and we are now at new release 1.3.0 but have not migrated to it due to another bug, so i have yet to investigate the behavior on 1.3.0 Did you migrate yet? If so: does the problem persist?
Author
Owner

@Glowsome commented on GitHub (Jun 6, 2020):

@Krzmbrzl , the same issue exists/is seen on in 1.3.0

@Glowsome commented on GitHub (Jun 6, 2020): @Krzmbrzl , the same issue exists/is seen on in 1.3.0
Author
Owner

@Krzmbrzl commented on GitHub (Jun 6, 2020):

Okay thanks for the update 👍

@Krzmbrzl commented on GitHub (Jun 6, 2020): Okay thanks for the update :+1:
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/mumble-mumble-voip#1632
No description provided.