|
| 1 | +--- |
| 2 | +title: Upgrade with Physical Cluster Replication Enabled |
| 3 | +summary: Upgrade your clusters when using PCR. |
| 4 | +toc: true |
| 5 | +docs_area: manage |
| 6 | +--- |
| 7 | + |
| 8 | +When [**physical cluster replication (PCR)**]({% link {{ page.version.version }}/physical-cluster-replication-overview.md %}) is enabled, you must use the process on this page to upgrade your clusters. This process ensures that the standby cluster upgrades before the primary cluster. |
| 9 | + |
| 10 | +{{site.data.alerts.callout_info}} |
| 11 | +The entire standby cluster must be at the same version as, or one version ahead of, the primary's virtual cluster. Within the primary and standby CockroachDB clusters, the _system virtual cluster (SystemVC)_ must be at a cluster version greater than or equal to the _app virtual cluster (AppVC)_. |
| 12 | +{{site.data.alerts.end}} |
| 13 | + |
| 14 | +## Upgrade primary and standby clusters |
| 15 | + |
| 16 | +To upgrade your primary and standby clusters: |
| 17 | + |
| 18 | +1. [Upgrade the binaries]({% link {{ page.version.version }}/upgrade-cockroach-version.md %}#perform-a-major-version-upgrade) on the standby cluster. Replace the binary on each node of the cluster and restart the node. |
| 19 | + |
| 20 | + After upgrading the binaries on the standby cluster, the primary cluster is not upgradable until the standby cluster's upgrade has finalized. |
| 21 | + |
| 22 | + If auto-finalization is enabled, the upgrade auto-finalizes after 72 hours. |
| 23 | + |
| 24 | +1. If auto-finalization is disabled, [finalize]({% link {{ page.version.version }}/upgrade-cockroach-version.md %}#finalize-a-major-version-upgrade-manually) the upgrade on the standby cluster's SystemVC. |
| 25 | + |
| 26 | + {{site.data.alerts.callout_info}} |
| 27 | + If you need to [roll back]({% link {{ page.version.version }}/upgrade-cockroach-version.md %}#roll-back-a-major-version-upgrade) an upgrade, you must do so before the upgrade has been finalized. |
| 28 | + {{site.data.alerts.end}} |
| 29 | + |
| 30 | +1. If auto-finalization is disabled, [finalize]({% link {{ page.version.version }}/upgrade-cockroach-version.md %}#finalize-a-major-version-upgrade-manually) the upgrade on the standby cluster's AppVC. |
| 31 | + |
| 32 | + After you have finalized the upgrade on the standby cluster's AppVC, the clusters can remain in this state for an indefinite amount of time. You can wait to upgrade the primary cluster as long as is needed. |
| 33 | + |
| 34 | +1. [Upgrade the binaries]({% link {{ page.version.version }}/upgrade-cockroach-version.md %}#perform-a-major-version-upgrade) on the primary cluster. Replace the binary on each node of the cluster and restart the node. |
| 35 | + |
| 36 | + After upgrading the binaries on the primary cluster, the standby cluster is not upgradable until the primary cluster's upgrade has finalized. |
| 37 | + |
| 38 | +1. If auto-finalization is disabled, [finalize]({% link {{ page.version.version }}/upgrade-cockroach-version.md %}#finalize-a-major-version-upgrade-manually) the upgrade on the primary cluster's SystemVC. |
| 39 | + |
| 40 | + {{site.data.alerts.callout_info}} |
| 41 | + If you need to [roll back]({% link {{ page.version.version }}/upgrade-cockroach-version.md %}#roll-back-a-major-version-upgrade) an upgrade, you must do so before the upgrade has been finalized. |
| 42 | + {{site.data.alerts.end}} |
| 43 | + |
| 44 | +1. If auto-finalization is disabled, [finalize]({% link {{ page.version.version }}/upgrade-cockroach-version.md %}#finalize-a-major-version-upgrade-manually) the upgrade on the primary cluster's AppVC. |
| 45 | + |
| 46 | +## Upgrade ReaderVC |
| 47 | + |
| 48 | +If you have a [_reader virtual cluster (ReaderVC)_]({% link {{ page.version.version }}/read-from-standby.md %}), use the following steps to upgrade it by dropping and re-creating it: |
| 49 | + |
| 50 | +1. After upgrading the AppVCs on your primary and standby clusters, wait for the replicated time to pass the time at which the upgrade completed. |
| 51 | +1. On the standby cluster, stop the ReaderVC service: |
| 52 | + |
| 53 | + {% include_cached copy-clipboard.html %} |
| 54 | + ~~~ sql |
| 55 | + ALTER VIRTUAL CLUSTER <readervc-name> STOP SERVICE |
| 56 | + ~~~ |
| 57 | + |
| 58 | +1. Drop the ReaderVC: |
| 59 | + |
| 60 | + {% include_cached copy-clipboard.html %} |
| 61 | + ~~~ sql |
| 62 | + DROP VIRTUAL CLUSTER <readervc-name> |
| 63 | + ~~~ |
| 64 | + |
| 65 | +1. On the AppVC, double-check that the standby cluster's AppVC has upgraded: |
| 66 | + |
| 67 | + {% include_cached copy-clipboard.html %} |
| 68 | + ~~~ sql |
| 69 | + SHOW CLUSTER SETTING version |
| 70 | + ~~~ |
| 71 | +
|
| 72 | +1. Back on the standby cluster, if the version is as expected, re-create the ReaderVC: |
| 73 | +
|
| 74 | + {% include_cached copy-clipboard.html %} |
| 75 | + ~~~ sql |
| 76 | + ALTER VIRTUAL CLUSTER dest-system SET REPLICATION READ VIRTUAL CLUSTER |
| 77 | + ~~~ |
| 78 | +
|
| 79 | +## Failover and fast failback during upgrade |
| 80 | +
|
| 81 | +If you need to perform a [failover]({% link {{ page.version.version }}/failover-replication.md %}) while upgrading your clusters, you can do that using the normal process. |
| 82 | +
|
| 83 | +However, after performing a failover you cannot perform a [fast failback]({% link {{ page.version.version }}/failover-replication.md %}#failback) to the original primary cluster during the upgrade process. This is because at times during the upgrade the standby cluster is ahead of the primary cluster. |
| 84 | +
|
| 85 | +## Patch deferrals |
| 86 | +
|
| 87 | +Patch versions are not relevant when determining PCR compatibility. There is no need to consider PCR compatibility when upgrading to a specific patch version within a major version. |
0 commit comments