Hi Cyril,
thanks for your tests. I'll leave it up to you and Hervé to improve
on existing code, since I really have no added value here (I don't
even have one mysql at hand).
Concerning possible choices, I agree that we must do our best not
to perturbate the service. Most of the time when people don't want
to enable health-checks, it's :
1) because that produces logs (wrong excuse)
2) because that significantly increases servers load (meaning the
tests are wrong)
3) because tests tend to cause site effects (worst case)
So I'd rather limit the range of versions we accept to support with
the check but support them very well, than try to support more versions
with undesired effects. If you think that we can already support
everything from 4.0 or 4.1 and up, that's already perfect. People
running older versions will just have to continue to use TCP checks.
Also it's very unlikely that someone will deploy a new haproxy version
with a very old MySQL version.
Your comment about the user/password reminded me about a similar issue
I had a long time ago for a scripted health check on a sensible app.
I had to use a tech login/password until I noticed that if someone
would mistakenly use that login 3 times in a row, it would be blocked,
meaning all servers would suddenly be marked down. I finally changed
the test to ask for an impossible user and inspected the return code,
looking for the expected precise status.
Maybe it's possible to do that with MySQL too. It's probable that
the return status when you ask for a wrong login is different from
any other one, meaning the DB did really check for that user, thus
showing it is alive. I don't know what impact that could have on
the logs though.
Regards,
Willy
