
[[_replication]]
=== 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.

.owners
[source,xml,subs="attributes+"]
----
<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.

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.

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.

