periodic refresh vs adaptive refresh

32 views
Skip to first unread message

jba...@gmail.com

unread,
Jul 24, 2019, 12:03:30 PM7/24/19
to lettuce-redis-client-users
found this old post about best practice of cluster topology refresh


I am thinking about just to enable adaptive refresh and disabled period refresh, will that be a safe config consider we are connecting to AWS Elastic Cache HA setup.
I assuming this will still work for AWS elastic cache master/slave fail over because of reconnection timeout  ?


Also, just how expensive is the periodic refresh? does it affect regular redis command execution during the refresh process? (are they competing with the shared ClientResources like EventExecutorGroup etc?)
If we have to use periodic refresh against elastic cache, i read somewhere else it is better to disable dynamicRefreshSources and rely on initils seed node, because the seed nodes from AWS is a DNS round-robin. (?)


mpa...@pivotal.io

unread,
Jul 25, 2019, 10:49:23 AM7/25/19
to lettuce-redis-client-users
The most honest answer is: Give it a try.

A refresh connects to either the seed nodes or all nodes (dynamic refresh sources) to issue a CLUSTER NODES and CLIENT LIST command. Refresh happens partially in a non-blocking way. Connections created for the topology retrieval use ClientResources and the actual refresh task runs on the computation thread pool (ClientResources.eventExecutorGroup).

I'd be happy if you share your findings and experience with us.

Cheers, 
Mark

y2k...@gmail.com

unread,
Jul 26, 2019, 12:16:34 AM7/26/19
to lettuce-redis-client-users
so i tried, and end up submitting a github issue :)

seems like if you are connecting to redis cluster that has replicas (slave), 5.1.7's new change will incorrectly think topology has changed every time periodic refresh kicks in.

i wonder what is the consequence of this, such continuous partition reload, will it affect actual command execution?
can this explain frequent command time out some people posted in 5.1.7 ?

mpa...@pivotal.io

unread,
Jul 26, 2019, 6:40:29 AM7/26/19
to lettuce-redis-client-users
Thanks for report.

The effects of topology reloads (topology is considered changed) are:

* Sending ClusterTopologyChangedEvent
* Discard of slot caches in partitions (cache invalidation happens too often)
* Unnecessary checks for stale connections (connections to nodes that no longer belong to the cluster)

While it's not a major flaw, we should fix it as it might cause performance regressions.

Cheers, 
Mark
Reply all
Reply to author
Forward
0 new messages