2016-04-30 04:39:32 +00:00
2016-04-28 23:31:06 +00:00
=== Replication and Failover
2018-06-12 20:10:27 +00:00
There are some caches like `sessions`, `authenticationSessions`, `offlineSessions`, `loginFailures` and few others, which are configured
as distributed caches in case of clustered setup. Entries are
2016-04-29 20:12:12 +00:00
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
2017-08-28 12:50:14 +00:00
is lost forever. By default, {project_name} only specifies one owner for data. So if that one node goes down
2016-04-28 23:31:06 +00:00
that data is lost. This usually means that users will be logged out and will have to login again.
2016-04-29 20:12:12 +00:00
You can change the number of nodes that replicate a piece of data by change the `owners` attribute in the `distributed-cache` declaration.
2016-04-28 23:31:06 +00:00
.owners
2018-06-12 20:10:27 +00:00
[source,xml,subs="attributes+"]
2016-04-28 23:31:06 +00:00
----
2018-06-12 20:10:27 +00:00
<subsystem xmlns="{subsystem_infinispan_xml_urn}">
<cache-container name="keycloak">
<distributed-cache name="sessions" owners="2"/>
2016-04-28 23:31:06 +00:00
...
----
2016-12-06 20:53:48 +00:00
Here we've changed it so at least two nodes will replicate one specific user login session.
2016-04-28 23:31:06 +00:00
2016-04-29 20:12:12 +00:00
TIP: 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.
2018-06-12 20:10:27 +00:00
TIP: It is very good if you 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 distributed cache and
hence it will be able to lookup the data locally. More details in <<sticky-sessions>>.
