Docs review for blueprint regarding database and Infinispan

keycloak · Nov 20, 2023 · d196593 · d196593
1 parent e57ca07
commit d196593
Show file tree

Hide file tree

Showing 3 changed files with 13 additions and 2 deletions.
diff --git a/doc/kubernetes/modules/ROOT/pages/running/network-partition.adoc b/doc/kubernetes/modules/ROOT/pages/running/network-partition.adoc
@@ -75,7 +75,9 @@ First procedure is to delete the stale data from the secondary site.
 
 . Login into your secondary site.
 
-. Shutdown Keycloak.
+. Shutdown Keycloak. This will clear all Keycloak caches, and it prevents the state of Keycloak from being out-of-sync with Infinispan.
++
+When deploying Keycloak using the Keycloak Operator, change the number of Keycloak instances in the Keycloak Custom Resource to 0.
 
 . Run the `crossdc-clear-caches` Batch CR (see xref:#running-infinispan-batch[]).
 
@@ -102,6 +104,8 @@ As now the state is available in the secondary datacenter, Keycloak can be start
 . Login into your secondary site.
 
 . Startup Keycloak.
++
+When deploying Keycloak using the Keycloak Operator, change the number of Keycloak instances in the Keycloak Custom Resource to the original value.
 
 === AWS Aurora Database
 

diff --git a/doc/kubernetes/modules/ROOT/pages/running/switch-back.adoc b/doc/kubernetes/modules/ROOT/pages/running/switch-back.adoc
@@ -83,12 +83,14 @@ The first procedure is to delete any stale data from the primary site.
 . Login to the primary site.
 
 . Shutdown Keycloak. This will clear all Keycloak caches, and it prevents the state of Keycloak from being out-of-sync with Infinispan.
++
+When deploying Keycloak using the Keycloak Operator, change the number of Keycloak instances in the Keycloak Custom Resource to 0.
 
 . Run the `crossdc-clear-caches` Batch CR (see xref:#running-infinispan-batch[]).
 
 . Delete all Batch CRs created.
 
-Now we are ready to transfer the state from the secondary site to the secondary site.
+Now we are ready to transfer the state from the secondary site to the primary site.
 
 . Login into your secondary site.
 
@@ -107,6 +109,8 @@ Now we are ready to transfer the state from the secondary site to the secondary
 . Login to the primary site.
 
 . Start Keycloak.
++
+When deploying Keycloak using the Keycloak Operator, change the number of Keycloak instances in the Keycloak Custom Resource to the original value.
 
 Both {ispn} clusters are in sync and the switchover from secondary back to the primary site can be performed.
 

diff --git a/doc/kubernetes/modules/ROOT/partials/aurora/aurora-failover.adoc b/doc/kubernetes/modules/ROOT/partials/aurora/aurora-failover.adoc
@@ -1,5 +1,8 @@
 Assuming a Regional multi-AZ Aurora deployment, the current writer instance should be in the same region as the active Keycloak cluster to avoid latencies and communication across availability zones.
 
+Switching the writer instance of Aurora will lead to a small downtime, and having the writer instance in the other datacenter with a slightly longer latency might be acceptable for some deployments.
+So this might be deferred to a maintenance window or skipped depending on the circumstances of the deployment.
+
 To change the writer instance, run a failover.
 Note that this will make the database unavailable for a short time, and database connections need to be reestablished.