keycloak-scim/docs/guides/high-availability/operate-switch-over.adoc
Ryan Emerson fc2120c881
Add docs for automating Infinispan CLI commands
Add docs for automating Infinispan CLI commands, Move Batch CR to its own concept

Signed-off-by: Ryan Emerson <remerson@redhat.com>
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Co-authored-by: Alexander Schwartz <aschwart@redhat.com>
2023-12-11 17:48:28 +01:00

96 lines
2.9 KiB
Text

<#import "/templates/guide.adoc" as tmpl>
<#import "/templates/links.adoc" as links>
<@tmpl.guide
title="Switch over to the secondary site"
summary="This topic describes the operational procedures necessary"
preview="true"
previewDiscussionLink="https://github.com/keycloak/keycloak/discussions/25269" >
This procedure switches from the primary site to the secondary site when using a setup as outlined in <@links.ha id="concepts-active-passive-sync" /> together with the blueprints outlined in <@links.ha id="bblocks-active-passive-sync" />.
include::partials/infinispan/infinispan-attributes.adoc[]
== When to use this procedure
Use this procedure to gracefully take the primary offline.
Once the primary site is back online, use the {sections} <@links.ha id="operate-network-partition-recovery" /> and <@links.ha id="operate-switch-back" /> to return to the original state with the primary site being active.
See the <@links.ha id="introduction" /> {section} for different operational procedures.
== Procedures
=== {jdgserver_name} Cluster
For the context of this {section}, `{site-a}` is the primary site and `{site-b}` is the secondary site.
When you are ready to take a site offline, a good practice is to disable the replication towards it.
This action prevents errors or delays when the channels are disconnected between the primary and the secondary site.
==== Procedures to transfer state from secondary to primary site
. Log in into your secondary site
<#include "partials/infinispan/infinispan-cli-connect.adoc" />
. Disable the replication to the primary site by running the following command:
+
.Command:
[source,bash,subs="+attributes"]
----
site take-offline --all-caches --site={site-a-cr}
----
+
.Output:
[source,bash,subs="+attributes"]
----
{
"offlineClientSessions" : "ok",
"authenticationSessions" : "ok",
"sessions" : "ok",
"clientSessions" : "ok",
"work" : "ok",
"offlineSessions" : "ok",
"loginFailures" : "ok",
"actionTokens" : "ok"
}
----
. Check the replication status is `offline`.
+
.Command:
[source,bash,subs="+attributes"]
----
site status --all-caches --site={site-a-cr}
----
+
.Output:
[source,bash,subs="+attributes"]
----
{
"status" : "offline"
}
----
+
If the status is not `offline`, repeat the previous step.
The {jdgserver_name} cluster in the secondary site is ready to handle requests without trying to replicate to the primary site.
=== AWS Aurora Database
include::partials/aurora/aurora-failover.adoc[]
=== {project_name} Cluster
No action required.
=== Route53
To force Route53 to mark the primary site as not available, edit the health check in AWS to point to a non-existent route (`health/down`). After some minutes, the clients will notice the change and traffic will gradually move over to the secondary site.
== Further reading
See <@links.ha id="concepts-infinispan-cli-batch" /> on how to automate Infinispan CLI commands.
</@tmpl.guide>