Entity Framework migrations are great. I particularily like the mechanism that prevents any query on the database until all pending migrations are applied. This solves a lot of issues and in most scenarios, you can even rely on the MigrateDatabaseToLatestVersion initializer in production. The initializer is smart enough to guard any instance of the dbcontext within the current process, this works correctly even from ASP.NET.
Well, mostly. Problems start when you have a farm of many ASP.NET servers that connect to the very same database. Each single server runs its own migration. Under heavy load this possibly means that your database is concurrently migrated from multiple servers.
Some time ago we almost had a disaster involving this scenario. A really busy app deployed on multiple servers was updated and, sadly, applying pending migrations was constantly failing. Yep, it was something specific in one of migrations but the result was as follows: one of servers tried to start the migration. Migration involved a heavy query that lasted a couple of seconds. All other servers were migrating too, trying to execute the very same heavy query. After the heavy query there was another lightweight query that was failing on the first server because the heavy query was pending on other servers. And as soon as any other server finished the heavy query, it immediately failed on the lightweight query because yet another server was just executing the heavy query.
There's a solution, though, involving two custom initializers. One just checks if there are pending migrations and throws. This one is configured as the default initializer. Another one actually migrates the database and is only invoked from a controlled environment, like a separate application or a specific controller/action.
Some code:
public class DefaultDbContextInitializer :
IDatabaseInitializer<ExampleMigrationDbContext>
{
public void InitializeDatabase( ExampleMigrationDbContext context )
{
Configuration cfg = new Configuration(); // migration configuration class
cfg.TargetDatabase =
new DbConnectionInfo(
context.Database.Connection.ConnectionString,
"System.Data.SqlClient" );
DbMigrator dbMigrator = new DbMigrator( cfg );
if ( dbMigrator.GetPendingMigrations().Count() > 0 )
{
throw new MigrationsException( "pending migrations!" );
}
}
}
public class MigratingDbContextInitializer :
IDatabaseInitializer<ExampleMigrationDbContext>
{
public void InitializeDatabase( ExampleMigrationDbContext context )
{
Configuration cfg = new Configuration(); // migration configuration class
cfg.TargetDatabase =
new DbConnectionInfo(
context.Database.Connection.ConnectionString,
"System.Data.SqlClient" );
DbMigrator dbMigrator = new DbMigrator( cfg );
foreach ( string MigrationName in dbMigrator.GetPendingMigrations() )
{
Stopwatch watch = new Stopwatch();
watch.Start();
dbMigrator.Update( MigrationName );
watch.Stop();
}
}
}
The first default initializer is configured globally:
Database.SetInitializer<ExampleMigrationDbContext>( new DefaultMigrationDbContextInitializer() );
Because of that, any attempt to touch the database that has pending migrations will fail with an exception you can catch and show a message.
But then, somewhere in a controlled environment you call this:
var context = new ExampleMigrationDbContext();
var migrator = new MigratingDbContextInitializer();
migrator.InitializeDatabase( context );
This works. After the database is migrated in the controlled way, the default initializer stops throwing and the app is back to running.
