logoalt Hacker News

imjosh-devyesterday at 9:44 PM1 replyview on HN

(Also PlanetScale employee here) Each shard finishes a backup at it's own time T, so two different shards could finish minutes apart (or even more, depending on the difference in size). for pretty much any use of a backup, you'll effectively be doing a PITR, not a raw restore from the cluster. The PITR timestamp is what unifies all the clusters together, regardless on when each backup finishes. think of backups as jumpstarts for actual restores (like for cluster resizes), where WAL replay and replication get the node to real time (or some specific point)

with that said you can restore without PITR if you don't care about synchronization, but generally you'll just use PITR


Replies

adastralyesterday at 10:21 PM

How do you cope with distributed transactions? (I'm not sure if you support them?)

I know that Citus has a `citus_create_restore_point()` (or so) function that, when called, guarantees that no 2PC commits are in flight and creates a WAL restore point in every shard. Therefore, restoring shards to that point will leave the DB in a consistent state. Do you do something similar?

show 1 reply