Added section on multi region behavior #21686
Conversation
Added section on multi region behavior
✅ Deploy Preview for cockroachdb-api-docs canceled.
|
✅ Deploy Preview for cockroachdb-interactivetutorials-docs canceled.
|
✅ Deploy Preview for cockroachdb-api-docs canceled.
|
✅ Deploy Preview for cockroachdb-interactivetutorials-docs canceled.
|
✅ Netlify Preview
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Netlify Preview
To edit notification comments on pull requests, go to your Netlify project configuration. |
Added links
|
|
||
| For details on failing back to the primary cluster following a failover, refer to [Fail back to the primary cluster]({% link {{ page.version.version }}/failover-replication.md %}#failback). | ||
|
|
||
| ## Multi-region behavior |
There was a problem hiding this comment.
Is this supposed to be an <h3> instead? Noticed in the preview that Multi-region behavior isn't nested with everything else:
There was a problem hiding this comment.
Oh good catch, thanks!
|
|
||
| ## Multi-region behavior | ||
|
|
||
| You can use PCR to replicate between clusters with different [cluster regions]({% link {{ page.version.version }}/multiregion-overview.md %}#cluster-regions), [database regions]({% link {{ page.version.version }}/multiregion-overview.md %}#database-regions), and [table localities]({% link {{ page.version.version }}/table-localities.md %}). Mismatched regions and localities do not impact the [failover process]({% link {{ page.version.version }}/failover-replication.md %}) or ability to access clusters after failover, but they do impact [leaseholders]({% link {{ page.version.version }}/architecture/glossary.md %}#leaseholder) and locality-dependent settings. Clusters replicating across different regions may also experience a slight decrease in performance due to longer replication times. |
There was a problem hiding this comment.
"they do impact leaseholders and locality-dependent settings"
I think we should be clearer here. If the standby cluster doesn't match the primary's localities, the standby cluster may not be able to satisfy replicating locality constraints. For example, if we're replicating an Regional by Row (rbr) table with partitions in us-east, us-central, and us-west; and the standby cluster does not have any nodes with a locality tag with us-west, the rbr us-west partition constraint cannot be satisfied, and the data will be placed in an arbitrary location on the destination cluster. This arbitrary data placement then has performance implications: if the user was relying on partitioning for intra region latency, we can no longer meet that on the destination.
There was a problem hiding this comment.
Just added a new paragraph getting a bit more detailed on this
There was a problem hiding this comment.
nice! one more nit:
Clusters replicating across different regions may also experience a slight decrease in performance due to longer replication times.
IMHO, i think this sentence can be removed, as you explain it more detail in the paragraph below, but perhaps the docs reviewer will have better opinions on how to organize this.
Added another paragraph explaining what settings are affected, also fixed header type
3 participants
Fixes: DOC-15033
Added section on multi region behavior based on this Google doc