2010/1/13 Cyril Bonté <[email protected]>: > Le Mercredi 13 Janvier 2010 12:56:30, Hervé COMMOWICK a écrit : >> I know the check is not perfect, because it doesn't handle a correct >> disconnection. >> Mysql expect the client to talk, and i think it's weird... in the >> future, i think it will be better to do a *real* mysql ping, but at the >> moment, the checks API doesn't let me handle this in a cleaner way. >> >> as a workaround, you can disable the mysql connection_errors checking by >> adding max_connect_errors=999999999 in you my.cnf > > Yes I guessed you knew that, but I thought it was better to signal it for > users interested by this check. > Maybe this workaround should appear in the documentation, like the note about > the client IP, until the handshake is complete. > This would minimize the risk to discover too late that the haproxy server has > been blacklisted by the mysql server (the guy who administrate haproxy is not > always the one for mysql, for example).
Yah, I got hit by that the first time I tried this too. I ended making a custom check run off localhost xinetd port. The script in turn makes a "normal" mysql connection to the database, does a query, checks the return value against a known good result, and then outputs good or bad. I don't know what the mysql-check does (sorry, haven't dug through the actual changed commit.) I don't see any reference to it in the 1.4 docs yet, so I figure it'll be there once 1.4 is actually done. One thing I've had trouble with when doing mysql though was the connection timeouts. I tried using tcpka but that didn't do it. So I do have trouble with connections of a long duration but where there is little actual data. Usually some client application that makes a connection once at the start and then goes idle waiting for some input from a client of its own. If anyone might know how to keep such an idle (but still valid) connection alive (other than a gigantic timeout), I'd love suggestions. Thank you, PH
