4 ms·

> When TFA points out that zero vendor lock-in and hassle-free, local end-to-end tests are non-negotiable, I think it is for this reason. if zero vendor lock-i

> When TFA points out that zero vendor lock-in and hassle-free, local end-to-end tests are non-negotiable, I think it is for this reason. if zero vendor lock-in and hassle-free, local end-to-end tests are non-negotiable, why are they using s3? migrating to another s3 compatible backend would be similar in effort to migrating from aurora mysql or postgres to another managed mysql or postgres service or to self-hosted mysql or postgres

ignoramous 5y ago
> migrating to another s3 compatible backend would be similar in effort to migrating from aurora mysql or postgres to another managed mysql or postgres service or to self-hosted mysql or postgres You may be right. I have no experience migrating litestream but from the docs (https://litestream.io/guides/ https://litestream.io/guides/) it is literally cp'ing files from S3 to wherever and exec'ing one of these one-liners (of course, the devil is in the details): litestream restore -o my.db s3://BUCKETNAME/PATHNAME litestream restore -o my.db abs://STORAGEACCOUNT@CONTAINERNAME/PATH litestream restore -o my.db gcs://BUCKET/PATH litestream restore -o my.db s3://SPACENAME.nyc3.digitaloceanspaces.com/db litestream restore -o my.db s3://BUCKETNAME.us-east-1.linodeobjects.com/db litestream restore -o my.db sftp://USER:PASSWORD@HOST:PORT/PATH
- benbjohnson 5y ago
  Litestream author here. Yeah, you're basically right but it's simpler than a DB migration. No need to copy the old data over. You can remove the `-litestream` metadata directory and point it at a new replication destination and it'll automatically re-snapshot the database begin replication.
tptacek 5y ago
First, S3 and a SQL database aren't comparable. But I think you're bringing up S3 because they're using Litestream to ship WAL frames to S3. Go read the Litestream documentation; Litestream syncs to basically anything. They don't need to "migrate to another S3 compatible backend"; they can migrate to almost anything that can save a file. It's a super confusing argument regardless, because the industry is lousy with "S3-compatible backends".

ignoramous 5y ago

> migrating to another s3 compatible backend would be similar in effort to migrating from aurora mysql or postgres to another managed mysql or postgres service or to self-hosted mysql or postgres You may be right. I have no experience migrating litestream but from the docs (https://litestream.io/guides/ https://litestream.io/guides/) it is literally cp'ing files from S3 to wherever and exec'ing one of these one-liners (of course, the devil is in the details): litestream restore -o my.db s3://BUCKETNAME/PATHNAME litestream restore -o my.db abs://STORAGEACCOUNT@CONTAINERNAME/PATH litestream restore -o my.db gcs://BUCKET/PATH litestream restore -o my.db s3://SPACENAME.nyc3.digitaloceanspaces.com/db litestream restore -o my.db s3://BUCKETNAME.us-east-1.linodeobjects.com/db litestream restore -o my.db sftp://USER:PASSWORD@HOST:PORT/PATH

benbjohnson 5y ago
Litestream author here. Yeah, you're basically right but it's simpler than a DB migration. No need to copy the old data over. You can remove the `-litestream` metadata directory and point it at a new replication destination and it'll automatically re-snapshot the database begin replication.

tptacek 5y ago

First, S3 and a SQL database aren't comparable. But I think you're bringing up S3 because they're using Litestream to ship WAL frames to S3. Go read the Litestream documentation; Litestream syncs to basically anything. They don't need to "migrate to another S3 compatible backend"; they can migrate to almost anything that can save a file. It's a super confusing argument regardless, because the industry is lousy with "S3-compatible backends".