Here in this post i will explain how we can do zero downtime migration in deployment.
First we can take backup of running system and create setup locally. Then we can perform migration and identify if there are any issues. Usually dump restore and setup take sometime based on deployment.
Then after that we can test APIs, resources etc. Also we can test extension points, integrations etc.
Then after we completed above we can come up with exact steps on migrating. So we can run same in deployment backup(or staging deployment). Ideally it should work without issues. Then we can repeat this to verify exact steps.
Following steps need to follow(if need they can automate that)
- Create dump of current running setup
- Restore it to lower environment.
- Perform migration.
- Do sanity check
Then we need to analyze traffic pattern of the deployment for about one week or more to identify time slot for migration. After some analysis we can identify time window with minimum user interaction.
Then we need to perform all above mentioned steps in production server. But at this time we should test all use cases end to end.
Also we need to create one way synchup script to synchronize tokens to new deployment(tokens created within maintain window).
Then comes real migration,
- Make API Manager store and publisher read only for maintain window(say 3 hours).
- Perform creating dump and restore to new environment.
- Do migration in new envirionment.
- Run synchup script to update new tokens created in original deployment.
- Then test functionalities using automated tests and manual tests.
- Once we are 100% confident we can do DNS switch.
- If everything works fine open traffic for store/publisher as well.
If you wish to do gradual traffic movement to new deployment it may bit different from above above mention approach. In that case we may need 2 way synch up scripts as tokens can created in both deployments.