-
Notifications
You must be signed in to change notification settings - Fork 3.4k
POC for size and timeout based flush at SourceShipper #7591
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
base: HBASE-28957_rebased
Are you sure you want to change the base?
Conversation
|
🎊 +1 overall
This message was automatically generated. |
|
💔 -1 overall
This message was automatically generated. |
| } | ||
|
|
||
| private void flushStagedWal() { | ||
| source.getReplicationEndpoint().beforePersistingReplicationOffset(); |
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 if persisting the WAL entries fails at the endpoint? In that case, we should throw an exception and fail here as well, since we cannot move forward until the entries are successfully persisted at the endpoint.
Apache9
left a comment
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 suggest we implement the POC based on the current master code base, and then applied the continous backup code on top of it. Otherwise it is a bit difficult to figure out what is the real modification for implementing this mechanism and what is because we have already supported continuius backup...
| // Loop until we close down | ||
| while (isActive()) { | ||
| // check if flush needed for WAL backup, this is need for timeout based flush | ||
| if (shouldFlushStagedWal()) { |
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.
The name is a bit confusing, which still assumes that the WAL entries we send to ReplicationEndpoint are 'staged'...
Just name it 'shouldPersistLogPosition'. And we already have a logPositionAndCleanOldLogs method?
This is followup POC of #7528
This is needed for continuous backup and PITR feature: https://github.com/apache/hbase/pull/7445/files
Here instead of ReplicationEndpoint handling flush and offset update, ReplicationSourceShipper is using time based and size based logic to flush and update replication offset
Please ignore the failing tests