HN user

Snelius

-12 karma
Posts0
Comments54
View on HN
No posts found.

Thank you for the link but it's not the same case ;) Google used storage switching which has migration in mixed mode, i.e. migration on demand when data migrated due user access to. API had compatibility layer to read/write from/to both storage systems (i built kind of this migration mechanism about decade ago). And google spend about 8 years for the migration which ok. And the article about Database migration which can be periodical process (critical scheme changes for example) and they describe it to us. Take snapshot and racing with snapshot overhead changes and etc. I think we can let's over here. It's not a zero downtime solution cuz it's not exists.

The code is open source though, you can read it

Thank you! :D

Is pretty well trodden ground.

YES!! But the article point us to it's a 400TB+ w/o downtime migration. This is impossible. That why is looks like clickbait and advertising of a product.

Load in latest db dump, may take as long as it wants.

400TB its about a week+ ?

Then start replication and catch up on the delay.

Then u have a changes in the delay about +- 1TB. It means a changes syncing about few days more while changes still coming.

They said "current requests are buffered" which is impossible, especial for long distributed (optional) transactions which in a progress (it can spend a hours, days (for analitycs)).

Overwall this article is a BS or some super custom case which irrelevant for common systems. You can't migrate w/o downtime, it's a physical impossible.

Clock 3 years ago

I still don't know what time it is. "Nice" UI.

Why Not Rust? 6 years ago

Yea. The Rust is a language pleasant to read about but not to wish to write on.