Skip to content
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
32 lines (23 sloc) 1.76 KB

Replication and Failover

There are caches like sessions, authenticationSessions, offlineSessions, loginFailures and a few others (See [_eviction] for more details), which are configured as distributed caches when using a clustered setup. Entries are not replicated to every single node, but instead one or more nodes is chosen as an owner of that data. If a node is not the owner of a specific cache entry it queries the cluster to obtain it. What this means for failover is that if all the nodes that own a piece of data go down, that data is lost forever. By default, {project_name} only specifies one owner for data. So if that one node goes down that data is lost. This usually means that users will be logged out and will have to login again.

You can change the number of nodes that replicate a piece of data by change the owners attribute in the distributed-cache declaration.

<subsystem xmlns="{subsystem_infinispan_xml_urn}">
   <cache-container name="keycloak">
       <distributed-cache name="sessions" owners="2"/>

Here we’ve changed it so at least two nodes will replicate one specific user login session.

The number of owners recommended is really dependent on your deployment. If you do not care if users are logged out when a node goes down, then one owner is good enough and you will avoid replication.
It is generally wise to configure your environment to use loadbalancer with sticky sessions. It is beneficial for performance as {project_name} server, where the particular request is served, will be usually the owner of the data from the distributed cache and will therefore be able to look up the data locally. See [sticky-sessions] for more details.
You can’t perform that action at this time.