MySQL Bugs: #191: Many connections from the slave to the master cause "alarm queue is full"

Bug #191	Many connections from the slave to the master cause "alarm queue is full"
Submitted:	25 Mar 2003 14:24	Modified:	18 Apr 2003 13:56
Reporter:	Guilhem Bichot	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S3 (Non-critical)
Version:	3.23	OS:	Linux (Linux at least)
Assigned to:	Guilhem Bichot	CPU Architecture:	Any

Description:
When a 3.23 slave fails to connect to the master, it retries after master-connect-retry (usually 60) seconds.
Every retry puts an alarm in the alarm queue, which grows until it is full.
Then the slave prints "alarm queue is full", and sometimes it send all
the alarms it has in the queue. See :

T@1026 : | >init_thr_alarm
T@1026 : | <init_thr_alarm
T@2051 : | | >thr_alarm
T@1026 : | >process_alarm
T@1026 : | | info: sig: 14 active alarms: 1
T@1026 : | <process_alarm
T@2051 : | | <thr_alarm
T@2051 : | >thr_alarm
T@1026 : | >process_alarm
T@1026 : | | info: sig: 14 active alarms: 2
<cut>
T@1026 : | >process_alarm
T@1026 : | | info: sig: 14 active alarms: 120
T@1026 : | <process_alarm
T@2051 : | >thr_end_alarm
T@2051 : | <thr_end_alarm
T@2051 : | | >thr_alarm
T@2051 : | | <thr_alarm
T@2051 : | >thr_alarm
T@2051 : | <thr_alarm
T@1026 : | >process_alarm
T@1026 : | | info: sig: 14 active alarms: 121
T@1026 : | <process_alarm
T@2051 : | >thr_end_alarm
T@2051 : | <thr_end_alarm
T@2051 : | | >thr_alarm
T@2051 : | | <thr_alarm
T@2051 : | >thr_alarm
T@2051 : | | info: alarm queue full
T@2051 : | <thr_alarm
T@1026 : | >process_alarm
T@1026 : | | info: sig: 14 active alarms: 121
T@1026 : | <process_alarm
T@2051 : | | >thr_alarm
T@2051 : | | <thr_alarm
T@2051 : | >thr_alarm
T@2051 : | <thr_alarm
T@1026 : | >process_alarm
T@1026 : | | info: sig: 14 active alarms: 2

etc etc. Such alarm consumption seems to generally slow down the slave server.

How to repeat:
Start a slave with master-connect-retry=1. 
Start no master.
Do SLAVE START.
Watch the messages printed by the slave server for 2 minutes or so.

Suggested fix:
I don't want to fix it yet as :
- this does not happen in 4.0 (where the alarm queue remains one-element-long,
which is fine ; no stupid growth like in 3.23 ; looks like the bug has already
been fixed in 4.0 which is production now).
- with the default value of master-connect-retry (60 sec) messages will show up
only after 2 hours of unsucessful attempts.
- this is the first time this is reported.
- it just maybe slows things down.
- fixing it in 3.23 may be risky.

Already fixed in 4.0.

Thank you for your bug report. This issue has already been fixed
in the latest released version of that product, which you can download at 
http://www.mysql.com/downloads/

Let's close it as it does not occur in 4.0.

Thank you for your bug report. This issue has been fixed in the latest
development tree for that product. You can find more information about
accessing our development trees at 
    http://www.mysql.com/doc/en/Installing_source_tree.html

Got email from Monty saying he fixed it in 3.23.57,
considering it critical.