On 9/21/09 1:28 PM, Stefan wrote:
Hello
Am Montag 21 September 2009 20:59:01 schrieb Hank A. Paulson:
I think you are getting a new cookie because of how your openais/etc is
failing over, not haproxy. haproxy doesn't create the cookie it just passes
it along.
drbd/openais doesn't have a way to maintain the same tcp connection id
across failovers (AFAIK), so when you fail over you get a new tcp
connection. You have to ask the openais/pacemaker/etc experts if the php
sessions/cookies are being replicated across all the servers and if so, how
would phpmyadmin get the list of cookies from the failed server.
I understood haproxy that it can handle session failover. Im wrong with this?
tia
stefan
Let's say the app (phpmyadmin) on server A issues a cookie with a value of
"phpcookie42132334595" haproxy forwards that cookie back and forth each
request. All is good.
later that same day...
Server A fails, haproxy forwards the cookie "phpcookie42132334595" to server B
which has taken over the IP address of server A. Server B says to the browser,
I have never heard of cookie "phpcookie42132334595" or a session with that
cookie.
haproxy can't fix that. You say the php or app level session data is there on
the drbd device and that it is still there after failover.
So you need to make sure haproxy is still delivering the cookie after failover
- you can log the cookie using the examples from the manual:
capture request header Cookie len 512
Once you confirm that it is delivering the cookie to the _first_ request
delivered to the new server (because after the first request, the new server
will probably issue a new cookie if it can't find the old session).
It probably is working, so the next step is you have to check why the php/app
on server B is not seeing the failed over cookies/sessions that are living on
the drbd device.
Do you have two servers running haproxy with the other stuff running locally
on those same servers?
