A migration plan can name every component and still leave the useful question unanswered: if the move fails, can the application work again? A dump file is not that answer. A restore into a new database, followed by the checks the application actually needs, is.
The missing-role example is a good reminder that a successful dump isn’t the same as a usable recovery. I’m also curious how you’d handle schema changes during the migration. A database might restore perfectly, but if the application has already moved to a newer schema version, the restore could still leave it unable to run. Would you include an application-version compatibility check in the recovery test?
Hi @Screen_White,
I am of the opinion that there should be a code freeze during migration procedures, so even if you would allow application-side writes, they shouldn’t write DDLs. Schema changes should not happen during the migration. Try to reduce complexity as much as possible.
I am not the blog author, so my opinions may not reflect that of the author 
Unanswered | Unsolved | Solved
MySQL, InnoDB, MariaDB and MongoDB are trademarks of their respective owners.
Copyright © 2006 - 2024 Percona LLC. All rights reserved.