Skip to content

Fix incorrect instructions in 'Upgrade a Cluster Running PCR' #23151

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
rmloveland wants to merge 2 commits into
base: main
Choose a base branch
from
+24 −24
Open

Fix incorrect instructions in 'Upgrade a Cluster Running PCR' #23151

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
3d3d2a1
Fix incorrect instructions in 'Upgrade a Cluster Running PCR'
rmloveland Apr 1, 2026
798da7e
Update with feedback from smcvey (1)
rmloveland Apr 1, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 8 additions & 8 deletions src/current/v25.4/upgrade-with-pcr.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 <readervc-name> STOP SERVICE;
ALTER VIRTUAL CLUSTER <application-vc-readonly> 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 <readervc-name>;
DROP VIRTUAL CLUSTER <application-vc-readonly>;
~~~

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 <readervc-name> SET REPLICATION READ VIRTUAL CLUSTER;
ALTER VIRTUAL CLUSTER <application-vc> 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.
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.
16 changes: 8 additions & 8 deletions src/current/v26.1/upgrade-with-pcr.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 <readervc-name> STOP SERVICE;
ALTER VIRTUAL CLUSTER <application-vc-readonly> 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 <readervc-name>;
DROP VIRTUAL CLUSTER <application-vc-readonly>;
~~~

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 <readervc-name> SET REPLICATION READ VIRTUAL CLUSTER;
ALTER VIRTUAL CLUSTER <application-vc> SET REPLICATION READ VIRTUAL CLUSTER;
Copy link
Copy Markdown
Contributor

@bsanchez-the-roach bsanchez-the-roach Apr 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this <application-vc> the same string as <application-vc-readonly>? If so maybe you should just use <application-vc-readonly>? The change in placeholder makes it seem like it should be a different string.

Copy link
Copy Markdown

@smcvey smcvey Apr 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change in placeholder makes it seem like it should be a different string.

Yes, it's supposed to be a different string, that is the purpose of this docs change. The first two commands run on the readonly version of the cluster being replicated which is called <cluster>-readonly. The last command rebuilds the readonly version from the non-readonly version so it's <cluster> without the -readonly.

Copy link
Copy Markdown
Contributor

@bsanchez-the-roach bsanchez-the-roach Apr 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, makes sense. @rmloveland Possible suggestion of using <application-vc-main> to differentiate? I wasn't sure which VC (of the two mentioned in step 4) that that placeholder referred to. But up to you, might be obvious to someone who knows more about the topic.

~~~

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.
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.
16 changes: 8 additions & 8 deletions src/current/v26.2/upgrade-with-pcr.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 <readervc-name> STOP SERVICE;
ALTER VIRTUAL CLUSTER <application-vc-readonly> 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 <readervc-name>;
DROP VIRTUAL CLUSTER <application-vc-readonly>;
~~~

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 <readervc-name> SET REPLICATION READ VIRTUAL CLUSTER;
ALTER VIRTUAL CLUSTER <application-vc> 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.
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.
Loading