Skip to content
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

Improve deletion via LTX zero commit #382

Closed
benbjohnson opened this issue Aug 10, 2023 · 6 comments · Fixed by #395
Closed

Improve deletion via LTX zero commit #382

benbjohnson opened this issue Aug 10, 2023 · 6 comments · Fixed by #395
Assignees
Labels
bug Something isn't working

Comments

@benbjohnson
Copy link
Collaborator

Currently, LiteFS communicates database deletion to replicas by sending a "dropdb" frame in the stream. However, this doesn't work well for LiteFS Cloud as it acts as the data authority and doesn't receive a stream. LFSC also needs to retain old copies of the database in case of recovery in the future.

This issue is to track the integration of "zero commit" LTX files (superfly/ltx#46) into LiteFS & LFSC.

@benbjohnson benbjohnson added the bug Something isn't working label Aug 10, 2023
@benbjohnson benbjohnson self-assigned this Aug 10, 2023
@gc-victor
Copy link

also needs to retain old copies of the database in case of recovery in the future

Sorry if this is too obvious, but I want to highlight this case.

In my use case, a new database can be recreated with the same name as a deleted database, but it has no relation to the old one except for using the same name.

Case:
DB X is created
DB X is deleted -> it is stored as a deleted DB
DB X is created (without any relation with the old DB other than the name)
DB X is deleted -> it is stored as a deleted DB

@benbjohnson
Copy link
Collaborator Author

The filename is the only identifier for the database in LiteFS so the two databases are related in that sense. On the LFSC side, you'd still see an entry for the database after deletion but it wouldn't show up on the LiteFS side if the database size was set to 0 in the most recent transaction.

@gc-victor
Copy link

If I delete and recreate a database with the same name, will it cause any problems? And if I delete it again, will it affect the previous deletion?

@benbjohnson
Copy link
Collaborator Author

No, it shouldn't cause any problems. With LiteFS, a transaction represents a specific set of bytes that make up the database at a given point in time. By making a zero-length database represent a deletion, it's just another transaction from LiteFS' perspective.

So internally, the TXID will keep incrementing even though you've created/deleted multiple times. e.g.

  • TXID 1: Create database.
  • TXID 2: Insert row.
  • TXID 3: Delete database. File no longer visible via LiteFS FUSE mount.
  • TXID 4: Create database again.

@benbjohnson
Copy link
Collaborator Author

@gc-victor I implemented soft delete so you can actually delete databases while connected to LiteFS Cloud (#395). You can test it using the Docker image for the PR:

COPY --from=flyio/litefs:pr-395 /usr/local/bin/litefs /usr/local/bin/litefs

@gc-victor
Copy link

@gc-victor I implemented soft delete so you can actually delete databases while connected to LiteFS Cloud (#395). You can test it using the Docker image for the PR:

COPY --from=flyio/litefs:pr-395 /usr/local/bin/litefs /usr/local/bin/litefs

Great! I will test it next week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants