2016-04-30 04:39:32 +00:00
2018-06-29 14:57:08 +00:00
[[_replication]]
2021-11-10 11:39:43 +00:00
=== Replication and failover
2016-04-28 23:31:06 +00:00
2018-06-29 14:57:08 +00:00
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
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-29 14:57:08 +00:00
TIP: 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.
2018-06-12 20:10:27 +00:00