Hey Meteor community. My names Abhi Aiyer and I have a quick question for all of ya. Recently I deployed our Meteor app to Modulus, using compose for our DB related stuff, and using Percolate’s Migrations package. In our last deployment, since we’re iterating pretty hard, we had to run several migrations. These migrations took alot since we have tons of users and were doing all sorts of jazz within in them.
My question is twofold:
- How can I run my migrations with zero downtime?
- What is the typical deployment procedure when you have to run migrations like this
I’m hoping all you engineering studs/ devops nerds can help me out! Currently we bite the bullet, deploy late at night and pray to god no ones doing anything on our site. We’re scaling fast and this isnt always gonna be the case!
Thanks!
-Abhi
I usually try to keep the app compatible with v-1 by way of checking its data, state etc to determine what to do, either with the updated functionality of current version, or v-1. This is not always easy but as long as you keep small deltas between updates, it stays manageable.
I use https://atmospherejs.com/percolate/migrations for this, works pretty well for me. just bundle the new code together with the needed migration as a file and you’re good to go.
I think he is already using precolate:migrations but his problem seems the time it takes the migrations to complete and how the application behaves within that timeframe.
DNS pointers are your friend, along with naming schemes that avoid dev/prod. If you don’t lock your servers into one operating environment or the other, you can run them in parallel in an A/B fashion and have rolling or cascading upgrades. Sometimes requires setting up a shadow database to tail the primary. But that’s what the OpsLog is for.
1 Like