diff --git a/src/current/v25.4/upgrade-with-pcr.md b/src/current/v25.4/upgrade-with-pcr.md index d6f82dfa17d..4844b3c85dc 100644 --- a/src/current/v25.4/upgrade-with-pcr.md +++ b/src/current/v25.4/upgrade-with-pcr.md @@ -111,31 +111,31 @@ To upgrade your primary and standby clusters: If you have a [_reader virtual cluster (reader VC)_]({% link {{ page.version.version }}/read-from-standby.md %}), you must drop and recreate it to upgrade after completing the main upgrade process on the primary and standby clusters. Follow these steps to upgrade your reader VC: 1. After upgrading the app VC on your primary cluster, wait for the replicated time to pass the time at which the upgrade completed. -1. On the standby cluster, stop the reader VC service: +1. On the standby cluster, stop the reader VC service on the readonly tenant: {% include_cached copy-clipboard.html %} ~~~ sql - ALTER VIRTUAL CLUSTER STOP SERVICE; + ALTER VIRTUAL CLUSTER STOP SERVICE; ~~~ -1. Drop the reader VC: +1. Drop the reader VC on the readonly tenant: {% include_cached copy-clipboard.html %} ~~~ sql - DROP VIRTUAL CLUSTER ; + DROP VIRTUAL CLUSTER ; ~~~ -1. On the standby cluster, re-create the reader VC: +1. On the standby cluster, re-create the reader VC from the standby cluster's replicating main VC. {% include_cached copy-clipboard.html %} ~~~ sql - ALTER VIRTUAL CLUSTER SET REPLICATION READ VIRTUAL CLUSTER; + ALTER VIRTUAL CLUSTER SET REPLICATION READ VIRTUAL CLUSTER; ~~~ -At this point, the reader VC is on the same version as the standby cluster. +At this point, the reader VC is on the same version as the replicating main VC on the standby cluster. ## Failover and fast failback during upgrade If needed, you can perform a [failover]({% link {{ page.version.version }}/failover-replication.md %}) while upgrading your clusters. -However, after performing a failover you cannot perform a [fast failback]({% link {{ page.version.version }}/failover-replication.md %}#failback) to the original primary cluster while the standby cluster version is newer than the primary cluster version. This is because you cannot replicate data from a cluster on a newer version to a cluster on an older version. \ No newline at end of file +However, after performing a failover you cannot perform a [fast failback]({% link {{ page.version.version }}/failover-replication.md %}#failback) to the original primary cluster while the standby cluster version is newer than the primary cluster version. This is because you cannot replicate data from a cluster on a newer version to a cluster on an older version. diff --git a/src/current/v26.1/upgrade-with-pcr.md b/src/current/v26.1/upgrade-with-pcr.md index d6f82dfa17d..e8c3dc74dae 100644 --- a/src/current/v26.1/upgrade-with-pcr.md +++ b/src/current/v26.1/upgrade-with-pcr.md @@ -111,31 +111,31 @@ To upgrade your primary and standby clusters: If you have a [_reader virtual cluster (reader VC)_]({% link {{ page.version.version }}/read-from-standby.md %}), you must drop and recreate it to upgrade after completing the main upgrade process on the primary and standby clusters. Follow these steps to upgrade your reader VC: 1. After upgrading the app VC on your primary cluster, wait for the replicated time to pass the time at which the upgrade completed. -1. On the standby cluster, stop the reader VC service: +1. On the standby cluster, stop the reader VC service on the readonly tenant: {% include_cached copy-clipboard.html %} ~~~ sql - ALTER VIRTUAL CLUSTER STOP SERVICE; + ALTER VIRTUAL CLUSTER STOP SERVICE; ~~~ -1. Drop the reader VC: +1. Drop the reader VC on the readonly tenant: {% include_cached copy-clipboard.html %} ~~~ sql - DROP VIRTUAL CLUSTER ; + DROP VIRTUAL CLUSTER ; ~~~ -1. On the standby cluster, re-create the reader VC: +1. On the standby cluster, re-create the reader VC from the standby cluster's replicating main VC. {% include_cached copy-clipboard.html %} ~~~ sql - ALTER VIRTUAL CLUSTER SET REPLICATION READ VIRTUAL CLUSTER; + ALTER VIRTUAL CLUSTER SET REPLICATION READ VIRTUAL CLUSTER; ~~~ -At this point, the reader VC is on the same version as the standby cluster. +At this point, the reader VC is on the same version as the replicating main VC on the standby cluster. ## Failover and fast failback during upgrade If needed, you can perform a [failover]({% link {{ page.version.version }}/failover-replication.md %}) while upgrading your clusters. -However, after performing a failover you cannot perform a [fast failback]({% link {{ page.version.version }}/failover-replication.md %}#failback) to the original primary cluster while the standby cluster version is newer than the primary cluster version. This is because you cannot replicate data from a cluster on a newer version to a cluster on an older version. \ No newline at end of file +However, after performing a failover you cannot perform a [fast failback]({% link {{ page.version.version }}/failover-replication.md %}#failback) to the original primary cluster while the standby cluster version is newer than the primary cluster version. This is because you cannot replicate data from a cluster on a newer version to a cluster on an older version. diff --git a/src/current/v26.2/upgrade-with-pcr.md b/src/current/v26.2/upgrade-with-pcr.md index d6f82dfa17d..e8c3dc74dae 100644 --- a/src/current/v26.2/upgrade-with-pcr.md +++ b/src/current/v26.2/upgrade-with-pcr.md @@ -111,31 +111,31 @@ To upgrade your primary and standby clusters: If you have a [_reader virtual cluster (reader VC)_]({% link {{ page.version.version }}/read-from-standby.md %}), you must drop and recreate it to upgrade after completing the main upgrade process on the primary and standby clusters. Follow these steps to upgrade your reader VC: 1. After upgrading the app VC on your primary cluster, wait for the replicated time to pass the time at which the upgrade completed. -1. On the standby cluster, stop the reader VC service: +1. On the standby cluster, stop the reader VC service on the readonly tenant: {% include_cached copy-clipboard.html %} ~~~ sql - ALTER VIRTUAL CLUSTER STOP SERVICE; + ALTER VIRTUAL CLUSTER STOP SERVICE; ~~~ -1. Drop the reader VC: +1. Drop the reader VC on the readonly tenant: {% include_cached copy-clipboard.html %} ~~~ sql - DROP VIRTUAL CLUSTER ; + DROP VIRTUAL CLUSTER ; ~~~ -1. On the standby cluster, re-create the reader VC: +1. On the standby cluster, re-create the reader VC from the standby cluster's replicating main VC. {% include_cached copy-clipboard.html %} ~~~ sql - ALTER VIRTUAL CLUSTER SET REPLICATION READ VIRTUAL CLUSTER; + ALTER VIRTUAL CLUSTER SET REPLICATION READ VIRTUAL CLUSTER; ~~~ -At this point, the reader VC is on the same version as the standby cluster. +At this point, the reader VC is on the same version as the replicating main VC on the standby cluster. ## Failover and fast failback during upgrade If needed, you can perform a [failover]({% link {{ page.version.version }}/failover-replication.md %}) while upgrading your clusters. -However, after performing a failover you cannot perform a [fast failback]({% link {{ page.version.version }}/failover-replication.md %}#failback) to the original primary cluster while the standby cluster version is newer than the primary cluster version. This is because you cannot replicate data from a cluster on a newer version to a cluster on an older version. \ No newline at end of file +However, after performing a failover you cannot perform a [fast failback]({% link {{ page.version.version }}/failover-replication.md %}#failback) to the original primary cluster while the standby cluster version is newer than the primary cluster version. This is because you cannot replicate data from a cluster on a newer version to a cluster on an older version.