8000 Feedback: MOLT Fetch - document replication rationale and cutover strategy · Issue #19530 · cockroachdb/docs · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Feedback: MOLT Fetch - document replication rationale and cutover strategy #19530

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.

Sign up for GitHub

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

Jump to bottom
Open
hand-crdb opened this issue Apr 17, 2025 · 0 comments
Open

Feedback: MOLT Fetch - document replication rationale and cutover strategy #19530

hand-crdb opened this issue Apr 17, 2025 · 0 comments
Assignees
@taroface
Labels
C-doc-improvement

Comments

@hand-crdb
Copy link
hand-crdb commented Apr 17, 2025 •
edited by cockroach-jira-scripts
Loading

Page: https://cockroachlabs.com/docs/molt/molt-fetch.html

What is the reason for your feedback?

[X] Missing the information I need

[ ] Too complicated

[ ] Out of date

[ ] Something is broken

[ ] Other

Additional details

The MOLT Fetch docs need to describe the rationale for using a replication approach, and describe the strategy for cutting over from the source database to CockroachDB.

Regarding the rationale for using the MOLT Fetch replication functionality, the doc should say something along the lines of:

MOLT Fetch supports low-downtime migrations by providing a replication mode of operation. With replication mode, the downtime required is shorter because you do not need to wait for all the source data to be transferred to CockroachDB. Instead, you only have to wait for the replication pipeline to drain, which takes much less time.

Regarding the strategy for cutting over from the source database to CockroachDB, the doc should say something along the lines of:

When using replication, the approach for the cutover to CockroachDB is: (1) stop performing writes on the old database, (2) wait for the replication pipeline to drain, then (3) start performing writes to CockroachDB.

It should also document how the customer can know when the replication pipeline has finished draining so they can move from step 2 to 3. It should say something along the lines of:

You can infer that replication pipeline has drained from seeing no more replication activity. You can see this activity in two places:

  1. Looking at the Replicator logs, once there is no more activity, you would no longer see upserted rows. The Replicator logs should show something like info upserted rows: 0

  2. There is also a Replicator metric that shows throughput. Once you see that as 0 rows/sec then the replication pipeline should be drained.

Jira issue: DOC-13256
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@taroface taroface

Labels
C-doc-improvement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@taroface @hand-crdb
0