3 ms·
We haven't done a cloud migration, but I know from zero-downtime DATABASE migrations that if you do this: - don't use any cloud service that isn't a packaged v
by AtlasBarfed 5y ago
We haven't done a cloud migration, but I know from zero-downtime DATABASE migrations that if you do this:
- don't use any cloud service that isn't a packaged version of an installable/usable OSS project
- architect your services to be able to double-write and switchover the read source with A/B deployments
If you can migrate your database without downtime this way, then you are much more flexible than if not.
- logifail 5y ago> architect your services to be able to double-write Can you share any details on how to achieve this? For instance, if the first database accepts the write but the second is temporarily inaccessible or throws an error, do you roll back the transaction on the first and throw an error, or <insert_clever_thing_here> ... ?
- vidarh 5y agoYou're right double-writes are flexible, and it's great when it works. With schema migrations I'm fine with it, because you can usually enforce consistency. But with migrations from one database to another at different locations, I'm lukewarm to it because it means having to handle split-brain scenarios, and often that ends up resulting in a level of complexity that costs far more than it's worth. Of course your mileage may vary - there are situations where it's easy enough and/or where the value in doing it is high enough.