We are using Entity Framework Code First for our application. Migrations has also been enabled, and we upgrade our database through the migration scripts generated by using migrate.exe.
On a production environment, we would like to upgrade the database in-place (without downtime). In order to do this, we want to first upgrade the database, while the front-end nodes are still running an older copy of the application. Once the DB is upgraded, we would then upgrade individual application nodes one at a time.
Is this possible with Code-first and Migrations? Currently, when we try to have the older version of the application connect to a newer "migrated" version of the database, it throws the context out of sync exception (which is expected).
You could set your database initialization strategy to null to prevent your context from checking to see if there are any discrepancies
Database.SetInitializer<YourContext>(null);
Related
So transitioning from the development/deployment approach of
Have DB under Source Control and have deployment pipeline for specific versions of the DB
Have Web App/API under Source Control and have deployment pipelines for these;
and then have dependencies of the Web APP/API on DB Versions - hence to add a new DB change for example we have to do a DB release; before we do an APP release - and the DB change has to not 'break' the old app - and then we can upgrade the App to use the new DB Change
Whilst painful - this works; it also works when you have N Servers for the web app (horizontal scale) with a suitably SINGLE DB Server.
Now working towards EF Core 3.1 Code First using Data Migrations. All working as expected one a single web app with single DB.
But - if this was deployed to N Web Servers, again with a single DB instance; Then.....
"IF" Web Servers upgraded one at a time then then Data Migration would occur on the start up of the first "new" app - and potentially the old web apps would continue to work (depends on the changes)
The above isn't really my concern; it's
If you have simultaneous deployment over multiple web app servers and these apps start at the same time; then I imagine the Data Migrations would be attempted all at the same time.... meaning one of them must fail.
So: $64,000 Question - how do people deal with the horiztonal scale out of Web app with Single DB Server with EF Code First Data Migrations?
Is it "just be careful with your changes"?
how do people deal with the horiztonal scale out of Web app with Single DB Server with EF Code First Data Migrations?
Applying migrations at runtime is suitable only for dev and simple production deployments.
The most common pattern here is to generate the database change scripts (perhaps using Migrations, perhaps using a database-oriented tool like SQL Server Data Tools), review the changes for backwards-compatibility and ability to be applied online, and deploy them first.
The documentation for Entity Framework says to use migration CLI commands to create a database that doesn't exist yet for our EF model, and sync a database when our EF model changes.
Why do we need to explicitly run CLI commands outside our application in order to handle migration?
Can our applications that use EF implicitly handle migration: create a database if it doesn't exist for our EF model and sync a database when our EF model changes?
I had a little experience with Hibernate before, and I didn't hear about migration then. I might be wrong but left with the impression that applications using Hibernate could handle migration implicitly.
You can do either one you want. If you have a formal DevOps deployment process you would normally deploy your database schema then, and the CLI commands are how you do that with Migrations. You can run the migration in the deployment pipeline, or use the CLI to generate the upgrade scripts and run the scripts in the deployment pipeline.
See
Some apps may want to apply migrations at runtime during startup or
first run. Do this using the Migrate() method. . . .
Warning
This approach isn't for everyone. While it's great for apps with a
local database, most applications will require more robust deployment
strategy like generating SQL scripts.
Apply migrations at runtime
So while you would normally apply migrations at runtime on your private developer database, for deployment to shared environments it't often not the best choice.
So I have an EF Core project. When I need to add/migrations I issue and update command:
dotnet ef database update -v
This all works fine, if I need to update the QA, Staging, Prod database I update the connection string in my appsettings.json file and run the command.
What happens if I don't have access to production from my local machine? How do you go about updating the database to the latest migration?
If I remember working with Entity Framework (not .net core). It would try and update the database automatically when I deploy a new version of the .net application. Does this functionality still exist in .NET core?
Yes you could run
dbContext.Database.Migrate();
On startup but it is generally not a good idea to conflate database migration with your application lifecycle - best practice is to keep your application start up as fast and simple as possible because an application start failure is hard to diagnose remotely, and a migration would introduce a lot of unwelcome complexity.
The alternative is to run a migration operation as part of your deployment. It depends on what method you use to deploy but say for example you use a CI server, you will be able to run
dotnet ef database update
after copying the new code but before starting the application back up.
I'm faced with this scenario: I want to release my software into production on Azure, but there's a code-first database migration that must be applied at the same time to an Azure SQL database. During the time that new software version is pushed without the new database schema (or vice-versa), there will be a period of time that software will throw the exception The model backing the 'BlogContext' context has changed since the database was created..
My software is deployed upon pushing git commits to a branch using continuous integration in Visual Studio Team Services, so I really need a way to run update-database at the same time.
It appears this can be done using a manual publish from Visual Studio by checking the Update Database box (below), but I need this to be automated.
If you do not care about the data just drop the dbo.__MigrationHistory table
Hope this helps.
Can you take direct control over the deployment process (Team Services can help, or Octopus, Jenkins, others)? If so, deploy the database ahead of the code. That's how I would do it if I wasn't using Entity Framework. I would assume the same even with Entity Framework.
An entity framework context is initialised, by default, using CreateDatabaseIfNotExists<TContext>. If the database schema is different than the EF model, then error The model backing the 'BlogContext' context has changed since the database was created. will be triggered.
By adding to your db context contructor Database.SetInitializer<context>(null); the model error will not be triggered. This means you can deploy schema changes to production, without causing model errors, ahead of the new version of the application being deployed that contains the new db context, which equals no down-time.
Make use of an appSetting so that production code will use the null initializer.
I have a team developing a web application using EF. They all have local copies of their DB, as well as there being a central DB for a published version of the app. Some of the devs, and the CI server, have built their initial DB from a later version of the model than others, and so when they run Update-Database or the migrate.exe tool, they get errors when running migrations they don't actually need.
Other than blowing away all DBs and starting over, what's the best way to get everyone on the same page migrations-wise? Can migrate or Update-Database be told to mark migrations as being applied even if they fail, and continue?