On 2014-06-02 13:47, Cor Bosman wrote:
Thanks for the pointer, but it's kind of a hassle as there's no debian packages for phpredis. We could package it ourselves, but thats just more stuff to maintain.
Has anyone ever gotten memcached to be truly redundant? I cant seem to get it so if I bring 1 (of many) memcached down, then bring it back up, it still works right. Roundcube sees an empty server and assumes there's no session key.
I believe that this is the way that memcached expects to work.
You provide a list of memcached servers for horizontal scaling rather than high availability.
Memcache has a replication/fallback system but i cant get it to work.
I am running Roundcube against memcached with the repcached patch.
Node #1:
/opt/repcached/bin/memcached -m 4096 -c 4096 -d -l 192.168.128.31 -x 192.168.128.81
Node #2:
/opt/repcached/bin/memcached -m 4096 -c 4096 -d -l 192.168.128.81 -x 192.168.128.31
Both nodes claim to be the master node through the stats interface (and indeed a update on either node is mirrored to the other side). If I restart memcached on one node it fetches the state from the other side after a short pause.
This does work: only this morning I was able to walk the memcached session store from one pair of machines to another pair of machines in the same cluster without any user visible downtime by:
resynchronised there 3) Moving the other node in the same fashion
The only problem that I have had is that memcached slowly leaks memory when replication is enabled: some memory isn't released until one of the two nodes is restarted. Consequently I do that once a day, in the middle of the night.
Session timeouts also behave a little differently when memcached is used rather than the normal database session management. I found that the compose page hangs rather than giving a error page if someone clicks "Send" on a page where the session has timed out. We use a four hour session timeout, which helps.