2015-06-22 13:45 GMT+02:00 Ben RUBSON <ben.rub...@gmail.com>: > 2015-06-19 12:08 GMT+02:00 Ben RUBSON <ben.rub...@gmail.com>: >> >> 2015-06-18 22:52 GMT+02:00 shawn l.green <shawn.l.gr...@oracle.com>: >>> >>> On 6/18/2015 2:10 PM, Ben RUBSON wrote: >>>> >>>> Hello, >>>> >>>> In order for the slave to quickly show a communication issue between >>>> the master and the slave, I set slave_net_timeout to 10. >>>> "show slave status" then quickly updates, perfect. >>>> >>>> I would also like the master to quickly show when the slave is no more >>>> reachable. >>>> >>>> However, "show processlist" and "show slave hosts" take a very long >>>> time to update their status when the slave has gone. >>>> Is there any way to have a refresh rate of about 10 seconds, as I did >>>> on slave side ? >>> >>> There are two situations to consider >>> >>> 1) The slave is busy re-trying. It will do this a number of times then >>> eventually disconnect itself. If it does disconnect itself, the processlist >>> report will show it as soon as that happens. >> >> Yes, I confirm. >> >>> 2) The connection between the master and slave died (or the slave itself is >>> lost). In this case, the server did not receive any "I am going to >>> disconnect" message from its client (the slave). So as far as the server is >>> concerned, it is simply sitting in a wait expecting the client to eventually >>> send in a new command packet. >>> >>> That wait is controlled by --wait-timeout. Once an idle client connection >>> hits that limit, the server is programmed to think "the idiot on the other >>> end of this call has hung up on me" so it simply closes its end of the >>> socket. There are actually two different timers that could be used, >>> --wait-timeout or --interactive-timeout and which one is used to monitor the >>> idle socket depends entirely on if the client did or did not set the >>> 'interactive flag' when it formed the connection. MySQL slaves do not use >>> that flag. >>> >>> Now, if the line between the two systems died in the middle of a >>> conversation (an actual data transfer) then a shorter -net-write-timeout or >>> --net-read-timeout would expire and the session would die then. >> >> This is the interesting part yes, when the connection dies (whatever >> the link status is at this moment, idle or not). >> So I set wait_timeout=10. >> >> When the link is up, we clearly see that the idle connection is reset >> every 10 seconds : the "show processlist" clearly shows that the slave >> TCP source port changes, and time is reset from 10 to 0. >> Perfect. > > Well this behavior is due to slave_net_timeout, not to wait_timeout. > So neither wait_timeout nor interactive_timeout (expected), > net_read_timeout, net_write_timeout helped. > >> However, when the link dies, the "Binlog Dump" process stays in the >> "show processlist", I have to wait more than 1000 seconds for it to >> disappear. >> I made tests adding interactive_timeout=10, net_read_timeout=10 and >> net_write_timeout=10, however the behavior is the same. >> >> Did I miss something ? >> >> Of course goal is to monitor replication, from the slave (done and >> working thanks to slave_net_timeout), but from the master too (some >> more tuning needed), as we never know which one will be able to >> transmit the alert properly. >> >> Thank you very much Shawn.
Hello, Would you have any further advice on this topic please ? Thank you again, Best regards, Ben -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql
