Le 27/04/2020 à 18:15, Florent Rivoire a écrit :
Hello,

This is my first message here, so: hi everyone :)
And thanks to everyone involved in the Haproxy project !

I wanted to give an idea of a (minor) better default that should be improved:
=> enable by default the "post-41" parameter in *mysql-check*

Today, it's off by default, so Haproxy is using the "very very old"
authentication method (before MySQL 4.1) to do the health-checks.
But since MySQL 4.1 is now *16* years old (stable in 2004), we are
fairly sure that all new installations of Haproxy will certainly be
used with a "recent-enough" (>= 4.1) mysql version that supports the
new protocol.

NB: of course, I know it's a breaking-change, so it needs to be
properly packaged in the right version.

For the anecdote, I'm writing this email because of:

1) What happened to me today: I was debugging a slightly complex (but
temporary) setup of an Haproxy being in front of MaxScale proxies
(mysql-specialized L7 LB) which are themself forwarding to mysql
daemons.
And the haproxy had "Layer7 wrong status: #08S01Bad handshake" errors.
After some hours of tests, I understood that my Haproxy was doing its
health-checks using the default config, so "very-old auth protocol",
but MaxScale only accepts the "new" protocol. It worked properly after
enabling the "post-41" option :)
If Haproxy had the "post-41" option enabled by default, I wouldn't
have had the issue.

2) The HAProxyConf 2019 Keynote in which Willy T. talked about "Better
defaults" that I saw a few months ago. Because I kinda recognized my
issue as a (fairly minor) example of such "usability tests".

What do you think ?


Hi,

Reading the doc about MySQL client/server protocol, it seems possible to know if the server supports the 4.1 protocol or not. Thanks to the recent refactoring of the checks engine, it is probably possible to automatically use the 4.1 protocol when supported by the server. I add it on my todo list. But no promises about the eta.

--
Christopher Faulet

Reply via email to