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 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for cockroachdb-interactivetutorials-docs canceled.
|
✅ Netlify Preview
To edit notification comments on pull requests, go to your Netlify project configuration. |
❌ Deploy Preview for cockroachdb-docs failed. Why did it fail? →
|
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
removed one sentence based on tech review
|
|
||
| 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. | ||
|
|
||
| If the localities on the primary cluster do not match the localities on the standby cluster, the standby cluster may be unable to satisfy replicating locality constraints. For example, if a replicated regional by row table has partitions in `us-east`, `us-central`, and `us-west`, and the standby cluster only has nodes with the locality tags `us-east` and `us-central`, the standby cluster cannot satisfy the regional by row `us-west` partition constraint. Data with unsatisfiable partition constraints is placed in an arbitrary location on the standby cluster, which can cause performance issues in the case of a failover event due to latency between regions. |
There was a problem hiding this comment.
The grammar of "regional by row" here is off. Per https://www.cockroachlabs.com/docs/v25.4/table-localities.html it seems like we use both "regional by row" and "REGIONAL BY ROW" interchangeably, but here I would prefer the latter since it reads more neatly as a proper noun. Is there a reason to keep it as-is?
There was a problem hiding this comment.
I can't think of a reason- changed this
src/current/v26.1/physical-cluster-replication-technical-overview.md
Outdated
Show resolved
Hide resolved
Small changes based on docs review- also backported since this should be the final version
|
@jhlodin Made the changes requested, and also went ahead and backported because I'm thinking this should now be the final version |
4 participants
Fixes: DOC-15033
Added section on multi region behavior based on this Google doc