Hi David, > That's not to say using multiple A records isn't a helpful practice > for many sorts of outages (especially to permit controlled > maintenance). Just don't expect it to necessarily be sufficient in > all failure modes depending on the behavior you want clients to > experience.
Indeed, in our application it's considered an optimisation over DNS failover. This is why we also use a low TTL (30 seconds) to purge the bad A records out of the pool as soon as possible. > If this is strictly limited to a client you control, it's much less of > an issue, since you can drop the TCP connect timeout much lower than > what it defaults to, though you still probably can't match how fast it > can happen for rejected connections, since you'll want to leave enough > room for occasional latency or response time issues without > immediately failing over. But you can do a lot better than the system > defaults. Unfortunately we have no control over the clients' configuration (this is a LAMP web hosting environment). But 30 seconds is considered much more acceptable than the days it can often take a manual repair job if a server goes down. -- Best Regards, Luke Marsden Hybrid Logic Ltd. Web: http://www.hybrid-cluster.com/ Hybrid Web Cluster - cloud web hosting based on FreeBSD and ZFS Mobile: +447791750420 _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
