-
Notifications
You must be signed in to change notification settings - Fork 470
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
Update docs for LDR v25.1 #19353
Update docs for LDR v25.1 #19353
Conversation
Files changed:
|
✅ Deploy Preview for cockroachdb-interactivetutorials-docs canceled.
|
✅ Deploy Preview for cockroachdb-api-docs canceled.
|
✅ Netlify Preview
To edit notification comments on pull requests, go to your Netlify site configuration. |
f2364da
to
366c902
Compare
@@ -36,12 +42,6 @@ You'll need: | |||
- All nodes in each cluster will need access to the Certificate Authority for the other cluster. Refer to [Step 2. Connect from the destination to the source](#step-2-connect-from-the-destination-to-the-source). | |||
- LDR replicates at the table level, which means clusters can contain other tables that are not part of the LDR job. If both clusters are empty, create the tables that you need to replicate with **identical** schema definitions (excluding indexes) on both clusters. If one cluster already has an existing table that you'll replicate, ensure the other cluster's table definition matches. For more details on the supported schemas, refer to [Schema Validation](#schema-validation). |
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 @alicia-l2 Am I right in thinking that the main point of this prerequisite bullet applies only to CREATE LOGICAL REPLICATION STREAM
?
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.
create the tables that you need to replicate with identical schema definitions (excluding indexes) on both clusters.
correct, this only applies to the original syntax.
{{site.data.alerts.end}}{% endcomment %} | ||
|
||
To create bidirectional LDR, you can complete the [optional step](#step-4-optional-set-up-bidirectional-ldr) to start the second LDR job that sends writes from the table on cluster B to the table on cluster A. | ||
|
||
### Schema validation |
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.
What about Schema validation? Is this just the old syntax since the new syntax will create the table?
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.
both flavors undergo schema validation. In fact, the CREATE LOGICALLY REPLICATED
is slightly more restricive. Unlike with the og syntax, a replicating table with the new syntax cannot have:
- UDTs
- foreign keys
366c902
to
2e3493f
Compare
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.
LGTM, have some comments
@@ -0,0 +1 @@ | |||
If your table does not contain any user-defined types or [foregin key]({% link {{ page.version.version }}/foreign-key.md %}) dependencies, use the [`CREATE LOGICALLY REPLICATED`]({% link {{ page.version.version }}/create-logically-replicated.md %}) syntax to start the stream for a fast, offline initial scan and automatic destination table setup. |
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 Can you fact check that those are the only two limitations for the ofline initial scan?
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.
Yes, i believe these are the only ones.
{{site.data.alerts.callout_info}} | ||
{% include feature-phases/preview.md %} | ||
|
||
Logical data replication is only supported in CockroachDB {{ site.data.products.core }} clusters. |
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.
*currently only supported
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.
We should avoid potential "forward-looking" language, and remain with what is factually available right now.
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.
Looks good! Left mostly nits
@@ -0,0 +1 @@ | |||
If your table does not contain any user-defined types or [foregin key]({% link {{ page.version.version }}/foreign-key.md %}) dependencies, use the [`CREATE LOGICALLY REPLICATED`]({% link {{ page.version.version }}/create-logically-replicated.md %}) syntax to start the stream for a fast, offline initial scan and automatic destination table setup. |
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.
Yes, i believe these are the only ones.
|
||
- [Column families]({% link {{ page.version.version }}/column-families.md %}) | ||
- [Partial indexes]({% link {{ page.version.version }}/partial-indexes.md %}) and [hash-sharded indexes]({% link {{ page.version.version }}/hash-sharded-indexes.md %}) | ||
- Indexes with a [virtual computed column]({% link {{ page.version.version }}/computed-columns.md %}) | ||
- Composite types in the [primary key]({% link {{ page.version.version }}/primary-key.md %}) | ||
|
||
Additionally, for the `CREATE LOGICALLY REPLCATED` syntax, you cannot use LDR on a table with a schema that contains: |
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.
i find it a bit confusing that we have this list of limitations as well as a separate list of known limitations. LDR, with both syntaxes, currently do not support UDFs, Sequences etc. IMHO, it would be clearer to have just one list.
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.
For this, I've created myself an issue that I'll tackle as a follow-up. I want to take a look at the KL sections across LDR and this Schema validation section to evaluate the best approach: https://cockroachlabs.atlassian.net/browse/DOC-12331
|
||
You can use the `cockroach encode-uri` command to generate a connection string containing a cluster's certificate. | ||
|
||
1. On the **source** cluster in a new terminal window, generate a connection string, by passing the replication user, node IP, and port, along with the directory to the source cluster's CA certificate: | ||
1. On the **source** cluster in a new terminal window, generate a connection string, by passing the user, node IP, and port, along with the directory to the source cluster's CA certificate: |
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.
it would be good to clarify that the user in the external conn requires the REPLICATION priv.
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.
I've added this back in, not sure why I took that out while testing 🤔
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.
if you your user was root
, then you had these privs automatically
|
||
## Step 4. (Optional) Set up bidirectional LDR | ||
{% include_cached copy-clipboard.html %} |
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.
I just realized I did something bad: I should have added a release note to this SHOW LOGICAL REPLICATION JOBS change I made for 25.1, which means we'll need to update the examples in the docs. Should I open a separate docs issue?
This is another SHOW LDR JOBS change that should have had a release note as well.
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.
No worries! I've updated both of these column name changes and added the release notes to the 25.1 testing releases they released with.
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.
thank you!
I think I've addressed the comments / opened an issue to take care of the KLs in a follow-up. PTAL when you have a chance, @msbutler @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.
LGTM, had non-blocking questions/comments to take or leave as you desire
src/current/_includes/v25.1/ldr/use-create-logically-replicated.md
Outdated
Show resolved
Hide resolved
5d3eee9
to
bb79370
Compare
Fixes DOC-11948, DOC-12060
This PR adds the new LDR syntax
CREATE LOGICALLY REPLICATED
. We're keeping the original syntax from 24.2 in place as well, which has resulted in restructuring the Set Up Logical Data Replication tutorial. Both the new syntaxes, plus unidirectional/bidirectional intersect, so the updates are intended to pave a logical way through the tutorial no matter if the user setting up unidirectional or bidirectional.Rendered Previews
Setup Guide
New SQL Page