Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
[Question] strategy for multiple table alters #812
Labels
Comments
|
Can you give more details? In our situation we tend to run migrations that are backwards compatible. If two tables need to be altered to make something work, we might migrate table 1, then table 2. After that developers would make changes to the code and If necessary, we'd migrate table 1 or 2 a second time to complete the process. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Imagine the migration alters two tables, but if I read the doc correctly gh-ost supports single table alteration. I understand that there's no "good way" of handling this kind of situation because even if you run migrations simultaneously (two instances of gh-ost), at some point you'll end up having one table migrated while the other one still in migration.
Do I assume correctly that the only right way here is just not allowing such migrations in the first place if you care about zero downtime?