Having no-down-time when doing migrations is not an easy topic.
Depending on the nature of the migration and the type of data and the type of service and how coupled everything is, it's impossible. Especially when you are dealing with financial data and transactions that you can't afford to screw up even a single one.
I usually vote for having some planned non-working-hours downtime.
Yep. No other way around it. You tell your clients weeks/months ahead of the planned downtime. They'll understand and migrate in the middle of the night over a holiday weekend.
But this is in regards to major structural migrations, not simple schema updates or changes.
I'm talking about serious systematic migrations, not upgrades. In these instances, it is impossible to avoid downtime ( whether it be a few seconds, minutes or even hours ). It's one of the reasons why SLAs do not offer 100% uptimes.
Interested in a concrete example of where you see a migration being impossible without downtime; I'm not aware of Amazon or Google taking their APIs down for maintenance, which suggests that you can solve these problems with enough engineering spend.
depending on... how coupled everything is
If you're just saying here that some systems aren't currently able to migrate in a hitless way, rather than claiming that it would never be possible for some systems, then I fully agree. Hitless migrations require a lot of work, and probably aren't worth the cost for many applications/systems.
Relational databases are awesome, but it's much harder to achieve 100% uptime compared to schemaless, distributed, replicated data stores. You easily can take down your system with one innocuous-looking DDL migration that works great in test but grinds the machine to a halt on a production dataset.
Comments
Depending on the nature of the migration and the type of data and the type of service and how coupled everything is, it's impossible. Especially when you are dealing with financial data and transactions that you can't afford to screw up even a single one.
Yep. No other way around it. You tell your clients weeks/months ahead of the planned downtime. They'll understand and migrate in the middle of the night over a holiday weekend.
But this is in regards to major structural migrations, not simple schema updates or changes.
Are you saying no downtime is impossible or merely expensive?
Erlang/OTP with relups is an example of a system that provides zero downtime online upgrade and rollback with zero downtime.
I'm talking about serious systematic migrations, not upgrades. In these instances, it is impossible to avoid downtime ( whether it be a few seconds, minutes or even hours ). It's one of the reasons why SLAs do not offer 100% uptimes.
Interested in a concrete example of where you see a migration being impossible without downtime; I'm not aware of Amazon or Google taking their APIs down for maintenance, which suggests that you can solve these problems with enough engineering spend.
If you're just saying here that some systems aren't currently able to migrate in a hitless way, rather than claiming that it would never be possible for some systems, then I fully agree. Hitless migrations require a lot of work, and probably aren't worth the cost for many applications/systems.
Neither Amazon nor Google run off of an RDBMS.
Relational databases are awesome, but it's much harder to achieve 100% uptime compared to schemaless, distributed, replicated data stores. You easily can take down your system with one innocuous-looking DDL migration that works great in test but grinds the machine to a halt on a production dataset.
That's a good general point, but Youtube does use MySQL:
https://www.mysql.com/customers/view/?id=750 http://highscalability.com/youtube-architecture