-
Notifications
You must be signed in to change notification settings - Fork 340
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
libsql: add durable_frame_num
caching and metadata file
#1830
Conversation
@penberg in the logs above I see it is re-sending frame 7 because the server on the previous call returned max_frame_no 6 when we sent frame_no 7. Is there an off by one on the server side or is that to be expected with the protocol? |
libsql/src/sync.rs
Outdated
// Update our last known max_frame_no from the server. | ||
self.durable_frame_num = durable_frame_num; | ||
|
||
self.write_metadata().await?; |
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.
Do we have to write metadata on every frame? Maybe we could do that after each batch?
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.
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 does this mean?
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 don't see this being fixed in commit de24d82
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.
sorry I made a mistake it wasn't done in that commit but its done here 26ac07e
@LucioFranco What happens if the metadata file is corrupted? The code should recover from that by trying to push the whole log. |
This adds a new `<database>-info` file that is a json file containing metadata for syncing databases. At this point it just contains the `max_frame_no` from the server to optimize sending wal frames that already exist on the server. Closes #1818
4a8460f
to
203fc49
Compare
@LucioFranco I corrupted the info file as follows:
and now I see this error:
As I said before, the info file is for caching purposes. If we fail to read it, we should just discard it and regenerate it after chatting with the server. |
@penberg that has been fixed/implemented and there are a bunch of tests including a corrupted metadata file. |
7baa9a0
to
11cce47
Compare
@@ -402,7 +402,7 @@ impl Database { | |||
|
|||
let max_frame_no = conn.wal_frame_count(); | |||
|
|||
let generation = 1; // TODO: Probe from WAL. | |||
let generation = sync_ctx.generation(); // TODO: Probe from WAL. | |||
let start_frame_no = sync_ctx.durable_frame_num() + 1; |
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.
Now that we cache durable frame number, we need to be prepared for the scenario where remote database got deleted. IOW. the durable frame number we have here might be higher than what is actually on server side.
This PR adds both a metadata file that is used to cache the
durable_frame_num
to allow us to only send the frames the server needs. This also adds some basic logging to allow us to track what frames and generations are being pushed to the server.Closes #1818