# Failover issues with sticky **URL:** \ **Category:** NGINX\ **Created:** [July 21, 2011, 11:13am UTC](https://www.ruby-forum.com/t/failover-issues-with-sticky/209727 "2011-07-21T11:13:26Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![luislavena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/0ea827/32.png) [@luislavena](https://www.ruby-forum.com/u/luislavena)\ **Post date:** [July 21, 2011, 11:13am UTC](https://www.ruby-forum.com/t/failover-issues-with-sticky/209727/1 "2011-07-21T11:13:26Z")
Hello, I’m using nginx solely as a load balancer, with nginx-sticky ( [Google Code Archive - Long-term storage for Google Code Project Hosting.](https://code.google.com/p/nginx-sticky-module/)) as a way to maintain sticky sessions. There are 2 upstream servers configured - and I have to occasionally mark one of them as down. When I do this, failover from clients that have a sticky session cookie does not seem to happen to the other upstream server (which is up). Here are the steps in detail - 1. nginx with 2 upstream servers in the backend s1, s2 2. Client connects, nginx routes to s1 3. s1 marked as down in config, nginx config is reloaded 4. Requests from the same client continue going to s1, instead of s2 My understanding is that nginx should automatically route traffic to the second server. Anything I am missing here? - Hrish ---
**Author:** ![Hrishikesh\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/5fc32e/32.png) [@Hrishikesh\_B](https://www.ruby-forum.com/u/Hrishikesh_B)\ **Post date:** [July 21, 2011, 11:22am UTC](https://www.ruby-forum.com/t/failover-issues-with-sticky/209727/2 "2011-07-21T11:22:43Z")
2011/7/21 Hrishikesh B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): > Here are the steps in detail - > > 1. nginx with 2 upstream servers in the backend s1, s2 > 2. Client connects, nginx routes to s1 > 3. s1 marked as down in config, nginx config is reloaded > 4. Requests from the same client continue going to s1, instead of s2 > > My understanding is that nginx should automatically route traffic to the > second server. Anything I am missing here? Hello it’s a bug on the sticky module. Can you open a bug report there ([Google Code Archive - Long-term storage for Google Code Project Hosting.](https://code.google.com/p/nginx-sticky-module/issues/list)) please ? I’ll look at it. ++ jerome ---
**Author:** ![Hrishikesh\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/5fc32e/32.png) [@Hrishikesh\_B](https://www.ruby-forum.com/u/Hrishikesh_B)\ **Post date:** [July 21, 2011, 11:43am UTC](https://www.ruby-forum.com/t/failover-issues-with-sticky/209727/3 "2011-07-21T11:43:12Z")
Hi Jerome, Done - [Google Code Archive - Long-term storage for Google Code Project Hosting.](https://code.google.com/p/nginx-sticky-module/issues/detail?id=12) - Hrish 2011/7/21 Jrme L. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![Hrishikesh\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/5fc32e/32.png) [@Hrishikesh\_B](https://www.ruby-forum.com/u/Hrishikesh_B)\ **Post date:** [July 21, 2011, 2:41pm UTC](https://www.ruby-forum.com/t/failover-issues-with-sticky/209727/4 "2011-07-21T14:41:37Z")
Thanks a lot for the quick turnaround, Jerome. I’ll test it as soon as I get a chance. Hrish 2011/7/21 Jrme L. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![Hrishikesh\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/5fc32e/32.png) [@Hrishikesh\_B](https://www.ruby-forum.com/u/Hrishikesh_B)\ **Post date:** [July 21, 2011, 2:21pm UTC](https://www.ruby-forum.com/t/failover-issues-with-sticky/209727/5 "2011-07-21T14:21:12Z")
the bug has been fixed. I’ve released the 1.0-rc3 for the opportunity: [http://code.google.com/p/nginx-sticky-module/downloads/list](http://code.google.com/p/nginx-sticky-module/downloads/list) Can you please test it ? ++ jerome 2011/7/21 Hrishikesh B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):