Pavel, we have the same resolving issues, it would be really nice to have such kind of feature. -- */Best regards,/* /Eugene Istomin/
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.
