-
Notifications
You must be signed in to change notification settings - Fork 474
Add new section on read from standby feature #20502
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.
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
base: main
Are you sure you want to change the base?
Conversation
Added new pages and added them to the TOC
✅ Deploy Preview for cockroachdb-interactivetutorials-docs canceled.
|
✅ Deploy Preview for cockroachdb-api-docs canceled.
|
Files changed:
|
❌ Deploy Preview for cockroachdb-docs failed. Why did it fail? →
|
✅ Netlify Preview
To edit notification comments on pull requests, go to your Netlify project configuration. |
Fixed broken links
…om:cockroachdb/docs into 2025-10-01-doc-13854-add-read-from-standby
Build was failing because summary was too short
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice start!
|
||
### Check the status of your reader virtual cluster | ||
|
||
To confirm that your reader virtual cluster is active: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: we should add some language around the fact that the reader VC will only can serve reads after PCR initial scan completes. After the initial scan completes, use show virtual clusters to wait until the service mode is "shared" for the readerVC.
Then, the user should wait a minute to open a sql connection to the reader vc (i know, horrible ux).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unresolving. i don't see updated language on this.
SELECT region, SUM(amount) FROM orders GROUP BY region; | ||
~~~ | ||
|
||
The results of queries on the standby cluster reflect the state of the primary cluster as of the replicated time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: i think a more accurate way to say this is: "reads are always served at a historical time approaches the replicated time." (its not quite the replicated time currently)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be accurate to word this as "The results of queries on the standby cluster reflect the state of the primary cluster as of a historical time that approaches the replicated time"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@msbutler is this due to the lag between primary and standby AND readervc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@peachdawnleach yeah i like that language.
@alicia-l2 the lag between the AOST the user provides and the AOST actually used is due to a very annoying technical bug i really want to address. It has to do with the fact that the reader tenant descriptors are updated after the replicated data comes in on the replicating tenant.
The output provides the following information: | ||
- the replication status of the standby cluster | ||
- the timestamp of the most recently applied event on the standby cluster | ||
- any lag relative to the primary cluster |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to see the replicated time used by reader queries specifically, we could point users to the resolved time posted by the standby poller job on the reader vc. maybe that's a follow up item for this page cc @alicia-l2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resolved time posted by the standby poller job on the reader vc.
how does one get to this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
run SHOW JOBS on the reader tenant. Or view the job on the db console of the reader tenant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great start! one thing to note is that we probably also have to edit the sql syntax pages as well for ALTER VIRTUAL CLUSTERhttps://deploy-preview-20502--cockroachdb-docs.netlify.app/docs/v25.3/alter-virtual-cluster
|
||
## 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The standby cluster's AppVC itself remains offline during replication.
we should say the reason, @msbutler can you help here?
|
||
{% include_cached copy-clipboard.html %} | ||
~~~ sql | ||
ALTER VIRTUAL CLUSTER main SET REPLICATION READ VIRTUAL CLUSTER; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a blurb which says "you can only run this command after the standby appvc is replicating." aka like if you run SHOW VIRTUAL CLUSTERS you will see that the status for the appvc is "replicating." basically we can't add a readervc from an alter command if the standby appvc is not ready/replicating.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure why this comment was resolved. looks like we still need this.
Small changes based on tech review
|
||
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 itself only stores a few GB of metadata and no user data, so it does not require much extra disk space. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: s/a few GB/ a bit/r
after thinking about this a bit more, i don't we should say exactly how much storage space is required for the reader tenant
|
||
{% include_cached copy-clipboard.html %} | ||
~~~ sql | ||
ALTER VIRTUAL CLUSTER main SET REPLICATION READ VIRTUAL CLUSTER; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure why this comment was resolved. looks like we still need this.
|
||
### Check the status of your reader virtual cluster | ||
|
||
To confirm that your reader virtual cluster is active: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unresolving. i don't see updated language on this.
SELECT region, SUM(amount) FROM orders GROUP BY region; | ||
~~~ | ||
|
||
The results of queries on the standby cluster reflect the state of the primary cluster as of the replicated time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@peachdawnleach yeah i like that language.
@alicia-l2 the lag between the AOST the user provides and the AOST actually used is due to a very annoying technical bug i really want to address. It has to do with the fact that the reader tenant descriptors are updated after the replicated data comes in on the replicating tenant.
The output provides the following information: | ||
- the replication status of the standby cluster | ||
- the timestamp of the most recently applied event on the standby cluster | ||
- any lag relative to the primary cluster |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
run SHOW JOBS on the reader tenant. Or view the job on the db console of the reader tenant.
Addresses: DOC-13854
Adding information about the new read from standby feature in pcr