A few weeks ago, we release Litestream v0.5.0 and it was a big release! We revamped the underlying storage architecture to improve storage efficiency and restore times dramatically.
However, with every big change there are always some bugs that crop up. So we’ve been fixing up those minor issues and we’ve now released Litestream v0.5.1!
Here’s a few of the fixes we’re shipping with the new release.
Fixed timestamp-based restores
With the new LTX storage layer, we began storing timestamps in the header files so that we could track it across compactions. Unfortunately, some of the code was still using file-based timestamps for restores and those timestamps can skew depending on usage.
Re-added -if-replica-exists flag
The -if-replica-exists flag existed in Litestream v0.3.x and allows the litestream restore command to continue successfully even if there were no backups to restore from. This was useful in automated setups where a restore should be attempted in case there are backups but then it should fall back to creating a new database otherwise.
This missing flag in v0.5.0 was an oversight and we’ve re-added it with the same semantics.
Restored databases not restarting from correct TXID
When a database was restored and there was no local replication information, Litestream wasn’t properly catching up to the state on the replica. We added a fix here so that the restored database would check for the current transaction ID from the replica before starting replication.
Fixing endpoints to require valid URLs
As part of the v0.5.0 release, we upgraded the AWS client to its v2 implementation. However, one of the changes that occurred with that was that the new client required full, valid URLs for custom endpoints. We have fixed this issue by prepending the scheme onto URLs that were missing them.