Hi.

There has been a heated discussion on this about 2 years back, so sorry for
reopening any wounds. Also sorry for long winded intro.

My understanding is that neither 1.4 nor 1.5 are planned to have any
support for resolving any server addresses during normal operations; i.e.
such are always resolved at start-up.

One of the ways I would like to use ha-proxy, is to to become a pure TCP
proxy to a database server that is provides fail-over through DNS.

The problem with connection the application directly to such database is
that when the database does go down, previous IP address effectively goes
"dark", and I don't even get TCP connections reset on previously
established connections. Naturally, any attempts to establish new
connections just block, as it takes a while for the application (JDBC
driver, really), to figure out that nobody's even listening. The "host
unreachable" don't come either, I actually never seen those on this
particular network.

My attempts to make JDBC driver time out faster during either connect, or
read (through TCP keep alive, I can't really tune down socket read timeout
without failing real queries that just take long to run) were not all that
successful. I have to use "reasonable" timeouts, which prove enough to have
the application overrun with requests, locking it up. The implementation of
the connection pool in that particular application framework doesn't help
either, as everything just converges on the JDBC connections that can not
be established. I have enough redundancy in the application to overcome
that no database connection is available, but I need to get an error from
the JDBC/Pool to move forward, and getting this error is what's taking too
long.

I tried using ha-proxy for this. The idea was - if ha-proxy determines that
the server is "down", it will quickly snip both previously established, or
newly established connections, so I won't have to incur blocks associated
with those. So, ha-proxy is a perfect tool to prevent unreachable server
problem from the perspective of the application. This actually worked great
in my test: once I simulated database failure, there was absolutely no
blocks on database operations (sure, there were failures to connect to it,
but that's fine).

What remains a problem - is that because the fail-over changes the IP
address behind the server name, ha-proxy is not able to pick up the new
address. It would really be perfect if it could, otherwise, that "backend"
just never recovers.

Now, I have no control over this fail-over implementation. I have no
control over network specifics and application framework either. I can
fiddle with the JDBC driver, but it will probably be more tedious and
throw-away than the following.

Would anybody be interested in an optional parameter address modifier, say
"@chk:<n:m>" as a suffix to a host name, to enable ha-proxy to re-check the
specified name each <n> seconds, past initial resolution? Say, also
agreeing to mark server as "down" if a name fails to resolve after <m>
checks. If <n> is 0, then no checks are performed past initial resolution,
which is default and is that now. Having <m> of 0 to mean to not fail on
resolution errors.

Thank you,
  Pawel.

Reply via email to