Hi Willy, >> is it possible for haproxy to failover to a backup, >> but not failback even if the server is alive again?
I have the same problem. I would like for my primary to be detected as UP, but not do the failback immediately. Is it possible to failback to the primary only when the backup becomes unhealthy? I use HAProxy with two mysql servers in Active/Backup configuration. Sometimes, the primary mysql-server's CPU utilization increases a lot and it is unable to service queries quickly enough. The queries and connections pile up and exceed max_connections limit. My HAProxy detects this as an unhealthy condition and fails over to the mysql-server backup. At this point, the primary mysql-server slowly processes a couple of queries and the number of connections reduces to a value that is just below max_connections. HAPRoxy's health check goes through and determines the primary to be healthy and failback happens to an already overloaded primary. When this happens, inevitably the primary chokes again in a couple of seconds and a failover happens once again to the backup .. and the process repeats. I think that in this case, it would be great if HAProxy stayed with the mysql-server backup and switched back only when the backup becomes unhealthy. Is it possible to configure HAProxy to stick with the backup and not failback ? Thanks Siva Willy Tarreau <w <at> 1wt.eu> writes: > > On Thu, Feb 25, 2010 at 10:05:02PM -0500, Greg Gard wrote: > > sorry willy i sent this to wrong address. here is my other question: > > > > one more thing. is it possible for haproxy to failover to a backup, > > but not failback even if the server is alive again? for example, if i > > could set rise to be infinite so that once it was down, it was down > > for good? currently, i am handling this with a text file that gets > > written and once there forces my ruby db checker to return 5xx to > > haproxy. can you all think of any better way to deal with this withing > > haproxy? > > Well, there's no easy way to do this, but more importantly you don't > describe how you want to proceed to put the service back online after > the issue. Obviously you won't leave your server dead forever in a > rack and through it to the bin every time it fails. So "infinite" > here is still the wrong solution. I have a feeling that in fact > you're trying to use haproxy more as a fuse or an on/off switch > than for what it's designed. > > I really believe that you have to rethink the whole lifecycle of > your components and write down rules indicating after what event > you consider them dead, and after what event you consider them > usable again. You also have to identify if certain maintenance > operations are needed during the up->dead or dead->up transition. > Think of it just as if someone else was managing your haproxy and > you couldn't call him every day to stop/start/change configs. > > That's the only way you'll manage to get a reliable and easily > manageable application. > > Regards, > Willy > >
