Add documentation for replication client#579
Conversation
There was a problem hiding this comment.
Pull request overview
Adds a new README documenting how the pkg/repl replication client works and how its subscription implementations handle binlog deltas during migrations.
Changes:
- Introduces
pkg/repl/README.mdexplaining the replication client’s purpose and architecture. - Documents the three subscription implementations (delta map, delta queue, buffered map) with tradeoffs and examples.
- Describes key operational behaviors: watermark optimization, checkpointing, and cutover coordination.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 3 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Safe to cutover now | ||
| ``` | ||
|
|
||
| The `client.Flush()` will retry in a loop until the number of pending changes is considered trivial (currently <10K). It is important to handle errors correctly here, because `FlushUnderTableLock` may fail if it can't flush the pending changes fast enough. This is your cue to abandon the cutover operation for now, and try again when the server is under less load. |
There was a problem hiding this comment.
Is there force-cutover behavior that can help here?
There was a problem hiding this comment.
Force cutover applies to the lock acquisition. This threshold is about once we have the lock, what we can reasonably do before we decide that we're taking too long.
The repl.FlushUnderTableLock() call requires that you have to have pre-created the lock, which is done here:
spirit/pkg/migration/cutover.go
Lines 122 to 129 in 35bd921
(This is where force / non-force matters).
A Pull Request should be associated with an Issue.
Provides documentation for the replication client package.