| Bug #30932 | slave_net_timeout for connect() to master is not optimal. | ||
|---|---|---|---|
| Submitted: | 10 Sep 2007 16:09 | Modified: | 24 Oct 2007 14:46 |
| Reporter: | Domas Mituzas | ||
| Status: | Closed | ||
| Category: | Server: Replication | Severity: | S2 (Serious) |
| Version: | 5.0, 5.1, .. | OS: | Any |
| Assigned to: | Andrei Elkin | Target Version: | |
| Tags: | replication | ||
[10 Sep 2007 16:09]
Domas Mituzas
[13 Oct 2007 13:19]
Andrei Elkin
With fixes for bug#20435 introducing a new heartbeat feature `slave_net_timeout' can be set to a small values e.g the same suggested 10 seconds. The heartbeat replication event - to be sent in master's idling time - resets `slave_net_timeout'. Provided that the heartbeat period would be set to a value less that `slave_net_timeout' there is a very slim chance for the latter to elapse and force reconnecting.
[16 Oct 2007 22:59]
Lars Thalmann
This is fixed by the fix for BUG#20435: > a) Default value is 3600, so connect() will be terminated by OS > rather than MySQL With heartbeats enabled, there will be no termination of connect(). > b) Reducing slave_net_timeout to reasonable amount for connect() > (like 10s) would cause disconnects in case of idle replication, as > well as log rotation (see Bug#20435) With heartbeats enabled, there will be no idle replication.
[24 Oct 2007 11:54]
Jon Stephens
Documented fix in mysql-5.1.22-ndb-6.3.4 changelog; closed.
[24 Oct 2007 12:15]
Domas Mituzas
This is generic bug, not related to NDB - is it going to be added to mainstream versions?
[8 Nov 2007 15:08]
Lars Thalmann
Domas, yes it will appear in 6.0.
[28 Nov 2007 21:21]
Jon Stephens
Also documented for 6.0.4 release - see also Bug #20435.
