Changes from review

Small changes based on tech review

Author: peachdawnleach

src/current/v25.3/read-from-standby.md

@@ -5,17 +5,17 @@ toc: true
 docs_area: manage
 ---
 
-In addition to providing [failover]({% link {{ page.version.version }}/failover-replication.md %}) capabilities for disaster recovery, CockroachDB **physical cluster replication (PCR)** allows you to direct read-only queries to your standby cluster. This process offloads traffic such as application reads, analytics queries, and ad-hoc reporting from the primary cluster.
+In addition to providing [failover]({% link {{ page.version.version }}/failover-replication.md %}) capabilities for disaster recovery, [**physical cluster replication (PCR)**]({% link {{ page.version.version }}/physical-cluster-replication-overview.md %}) allows you to direct read-only queries to your standby cluster. This process offloads traffic such as application reads, analytics queries, and ad-hoc reporting from the primary cluster.
 
-Use this page to understand how the **read from standby** feature works and how to utilize it.
+Use this page to understand how the _read from standby_ feature works and how to utilize it.
 
 ## How the read from standby feature works
 
-PCR utilizes cluster virtualization to separate clusters' control planes from their data planes. A cluster always has one control plane, called a _system virtual cluster (SystemVC)_, and at least one data plane, called an _App Virtual Cluster (AppVC)_. A cluster's SystemVC manages PCR jobs and cluster metadata, and is not used for application queries. All data tables, system tables, and cluster settings in the standby cluster's AppVC are identical to the primary cluster's AppVC. The standby cluster's AppVC itself remains offline during replication.
+PCR utilizes [cluster virtualization]({% link {{ page.version.version }}/cluster-virtualization-overview.md %}) to separate a cluster's control plane from its data plane. A cluster always has one control plane, called a _system virtual cluster (SystemVC)_, and at least one data plane, called an _App Virtual Cluster (AppVC)_. The standby cluster's SystemVC manages the PCR job and other cluster metadata, and is not used for application queries. All data tables, system tables, and cluster settings in the standby cluster's AppVC are identical to the primary cluster's AppVC. The standby cluster's AppVC itself remains offline during replication.
 
-When using read from standby, applications can read from the standby cluster, but they do not connect directly to the standby cluster's AppVC. Instead, PCR introduces a _reader virtual cluster (ReaderVC)_. The ReaderVC ensures a clean, isolated environment specifically for serving read queries without interfering with replication or system metadata. It reads continuously from the standby cluster's AppVC using internal pointers, providing access to the replicated data while keeping the AppVC offline. The ReaderVC does not store any data itself, so it does not require extra disk space.
+When using read from standby, applications can read from the standby cluster, but they do not connect directly to the standby cluster's AppVC. Instead, PCR introduces a _reader virtual cluster (ReaderVC)_. The ReaderVC ensures a clean, isolated environment specifically for serving read queries without interfering with replication or system metadata. It reads continuously from the standby cluster's AppVC using internal pointers, providing access to the replicated data while keeping the AppVC offline. The ReaderVC itself only stores a few GB of metadata and no user data,  so it does not require much extra disk space.
 
-The standby cluster's ReaderVC has its own system tables and cluster settings. The ReaderVC replicates a subset of system tables, including **Users** and **Roles**, from the AppVC, so that existing primary users can authenticate. Other system tables and cluster settings are set to defaults in the ReaderVC.
+The standby cluster's ReaderVC has its own system tables and cluster settings. The ReaderVC replicates a subset of system tables, including **Users** and **Roles**, from the AppVC, so that existing primary users can authenticate using the same users and roles as on the primary cluster's AppVC. Other system tables and cluster settings are set to defaults in the ReaderVC.
 
 In the event of failover, the ReaderVC's response depends on the type of failover. After failover to the latest timestamp, the ReaderVC continues pointing to the AppVC but stops receiving updates. After failover to a point-in-time timestamp, the ReaderVC is destroyed.
 
@@ -54,7 +54,7 @@ To confirm that your reader virtual cluster is active:
 SHOW VIRTUAL CLUSTERS;
 ~~~
 
-The output shows a `standby-readonly` virtual cluster in addition to the primary and standby clusters:
+The output shows a `standby-readonly` virtual cluster in addition to the systemVC and AppVC:
 
 ~~~
   id |       name       | data_state  | service_mode

src/current/v25.4/read-from-standby.md

@@ -5,17 +5,17 @@ toc: true
 docs_area: manage
 ---
 
-In addition to providing [failover]({% link {{ page.version.version }}/failover-replication.md %}) capabilities for disaster recovery, CockroachDB **physical cluster replication (PCR)** allows you to direct read-only queries to your standby cluster. This process offloads traffic such as application reads, analytics queries, and ad-hoc reporting from the primary cluster.
+In addition to providing [failover]({% link {{ page.version.version }}/failover-replication.md %}) capabilities for disaster recovery, [**physical cluster replication (PCR)**]({% link {{ page.version.version }}/physical-cluster-replication-overview.md %}) allows you to direct read-only queries to your standby cluster. This process offloads traffic such as application reads, analytics queries, and ad-hoc reporting from the primary cluster.
 
-Use this page to understand how the **read from standby** feature works and how to utilize it.
+Use this page to understand how the _read from standby_ feature works and how to utilize it.
 
 ## How the read from standby feature works
 
-PCR utilizes cluster virtualization to separate clusters' control planes from their data planes. A cluster always has one control plane, called a _system virtual cluster (SystemVC)_, and at least one data plane, called an _App Virtual Cluster (AppVC)_. A cluster's SystemVC manages PCR jobs and cluster metadata, and is not used for application queries. All data tables, system tables, and cluster settings in the standby cluster's AppVC are identical to the primary cluster's AppVC. The standby cluster's AppVC itself remains offline during replication.
+PCR utilizes [cluster virtualization]({% link {{ page.version.version }}/cluster-virtualization-overview.md %}) to separate a cluster's control plane from its data plane. A cluster always has one control plane, called a _system virtual cluster (SystemVC)_, and at least one data plane, called an _App Virtual Cluster (AppVC)_. The standby cluster's SystemVC manages the PCR job and other cluster metadata, and is not used for application queries. All data tables, system tables, and cluster settings in the standby cluster's AppVC are identical to the primary cluster's AppVC. The standby cluster's AppVC itself remains offline during replication.
 
-When using read from standby, applications can read from the standby cluster, but they do not connect directly to the standby cluster's AppVC. Instead, PCR introduces a _reader virtual cluster (ReaderVC)_. The ReaderVC ensures a clean, isolated environment specifically for serving read queries without interfering with replication or system metadata. It reads continuously from the standby cluster's AppVC using internal pointers, providing access to the replicated data while keeping the AppVC offline. The ReaderVC does not store any data itself, so it does not require extra disk space.
+When using read from standby, applications can read from the standby cluster, but they do not connect directly to the standby cluster's AppVC. Instead, PCR introduces a _reader virtual cluster (ReaderVC)_. The ReaderVC ensures a clean, isolated environment specifically for serving read queries without interfering with replication or system metadata. It reads continuously from the standby cluster's AppVC using internal pointers, providing access to the replicated data while keeping the AppVC offline. The ReaderVC itself only stores a few GB of metadata and no user data,  so it does not require much extra disk space.
 
-The standby cluster's ReaderVC has its own system tables and cluster settings. The ReaderVC replicates a subset of system tables, including **Users** and **Roles**, from the AppVC, so that existing primary users can authenticate. Other system tables and cluster settings are set to defaults in the ReaderVC.
+The standby cluster's ReaderVC has its own system tables and cluster settings. The ReaderVC replicates a subset of system tables, including **Users** and **Roles**, from the AppVC, so that existing primary users can authenticate using the same users and roles as on the primary cluster's AppVC. Other system tables and cluster settings are set to defaults in the ReaderVC.
 
 In the event of failover, the ReaderVC is destroyed.
 
@@ -54,7 +54,7 @@ To confirm that your reader virtual cluster is active:
 SHOW VIRTUAL CLUSTERS;
 ~~~
 
-The output shows a `standby-readonly` virtual cluster in addition to the primary and standby clusters:
+The output shows a `standby-readonly` virtual cluster in addition to the systemVC and AppVC:
 
 ~~~
   id |       name       | data_state  | service_mode