31 lines
1.8 KiB
Text
31 lines
1.8 KiB
Text
|
|
[[_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.
|
|
|