Hot vs cold mysql schema migrations and improving speed
I have recently been doing cold migrations...which means that I make it impossible from an application level to read/write to the database while doing the migration (Maintenance page).
This way errors won't happen for changes to the structure and also if there is a lot of load I wouldn't want mysql to crash in the middle of the migration.
My structure is that every clients get their own database. The only downside to this approach is their can be downtime of 15-45 minutes depending on how many changes are made.
My solution to this would be the following:
Have 2 copies of the code running at the same time. I have code that detects what version of the program they are on and if they are still on old show them the old code...if they are on new show them the new code
The only part that scares me is if someone does a denial of service attack in the middle of the migration I could have serious problems.
I have about 360 databases right now.
Is the hot method recommended? I just get worried about a denial of service in the middle of it or some sort of mysql query error because their could be data changes going on. I did have this happen once before but luckily it was just before I started the migration.
Your idea would work only if the "new Code Base" is 100% compatible with the "old DB version", or else it might crash while the DB migration is in progress. Also, it requires that at no stage during the DB migration, the database is never in an inconsistent state (perhaps by wrapping migration steps in appropriate transactions).
If ressources allow, I would:
(you can even skip the tinkering with virtual hosts and use symbolic links instead)
链接地址: http://www.djcxy.com/p/23468.html上一篇: 获取Logstash的IP地址
下一篇: 热与冷mysql模式迁移并提高速度