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

Object Store Mediated Replication #434

Open
pg-wtatum opened this issue Jun 25, 2024 · 1 comment
Open

Object Store Mediated Replication #434

pg-wtatum opened this issue Jun 25, 2024 · 1 comment

Comments

@pg-wtatum
Copy link

Related to #18, it would be extremely powerful to be able to replicate data to read-replicas outside the datacenter infrastructure which could not securely or performantly access the HTTP endpoints of the litefs master directly. My proposed use-case if offline first web and mobile clients that can tolerate somewhat higher latency in their replication than the current method used for primary to read-replica, but still want an efficient and repeatable method for replicating database state from a primary.

If #18 is implemented then it feels like a very powerful added capability this would offer is for detached clients to use S3 as a method to get "in sync" with the primary (minus a time delay) without needing to manage any connectivity with the primary. The major additional effort to support this would be the ability to trigger a "restore" operation of the backup independent of the rest of the litefs plumbing (and most likely from an application sdk rather than via filesystem operations). Ideally this would only require the client to have S3 coordinates for the various objects holding the backup but not any other litefs config.

@pg-wtatum
Copy link
Author

I raised this before spotting #315 -- which makes it sound like the client for streaming writes via LTX to an external S3 (or the filesystem) is already in place. Would it be correct to assume that since #18 isn't closed that there's not a straightforward method to run a restore? For my use-case the absolute ideal would include two other capabilities:

  • Downloading the minimal set of LTX files needed given an initial database state that aligns to an historical transaction ID tracked by LiteFS (i.e. if the synchronization client has an "older" revision of the DB only fetch LTX files necessary to bring it up to date.
  • The ability to target "point in time" or a specific transaction ID within the limits possible based on the level of compaction in the LTX files.

As I'm asking I recognize that this is likely a lot but since it sounds like it aligns with existing project goals just clarifying if this is actually something that's on the roadmap?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant