It looks like when a run a migration which fails, that migration is not added to the schema.version table but is reflected locally as pending state in the info command.
Given this, repair is not required as there is no checksum stored in schema.version.
So I suppose my question is; is there a scenario where repair is required for PostgreSQL and also, what scenario puts a row into schema_version that has a non-TRUE value for success?
You are correct. For PostgreSQL and other databases with DDL transaction support, success is always true.
The only time repair is required, is when for some reason you had to change a migration and the checksums need to be realigned.
Related
How can make a change to the database with Prisma.js without having to reset the whole thing?
When I changed prisma.schema and run:
npx prisma migrate dev --name change-name
My database lost all data. Can I run another command which doesn't remove my data? What is best for me in this situation?
You would need to Baseline your database in order to not reset your database.
For the cases which contains data that must be maintained (like production), which means that the database cannot be reset, In those cases Baselining tells Prisma Migrate to assume that one or more migrations have already been applied. This prevents generated migrations from failing when they try to create tables and fields that already exist.
I have a PostgreSQL db that is used by a Nest.Js / Prisma app.
We changed the name of a field in the Prisma schema and added a new field.
Now, when we want to update the PostreSQL structure, I'm running, as suggested by Prisma, the following commands:
npx prisma generate
and then
npx prisma migrate dev --name textSettings-added --create-only
The idea is to use the --create-only flag to review the migration before it is actually made.
However, when I run it I get a list of the changes to be made to the DB and the following message:
We need to reset the PostgreSQL database "my_database" at "my_db_name#cluster.us-east-1.rds.amazonaws.com:5432".
Do you want to continue? All data will be lost.
Of course I choose not to continue, because I don't want to lose the data. Upon inspection I see that the migration file actually contains DROP TABLE for the tables that I simply wanted to modify. How to avoid that?
So how do I run the update without affecting the data?
UPDATE:
I saw that running with --create-only creates a migration which can then be implemented on the DB level using prisma migrate dev, however, in that migration file there are still some commands that drop my previous tables because of some new parameters inside. How can I run prisma migration without deleting my PostgreSQL data?
UPDATE 2:
I don't want Prisma to drop my tables when I just updated them. The migration file generated, however, drops them and then alters them. Do you know what's the best procedure to avoid this drop? I saw somewhere I could first manually update the DB with the new options and then run the migration, so Prisma can find a way to update it, but that seems too manual to me... Maybe some other ideas?
For some cases like renaming tables or columns, Prisma's generated migration files need to be updated if they already contain data.
If that applies to your use case, Prisma's docs suggest to:
Make updates to the prisma schema
Create migration file without applying it (--create-only flag)
Update the migration script to remove the drops and instead write your custom query (e.g. RENAME <table_name> TO <new_name>)
Save and apply the migration (npx prisma migrate dev)
Note that those changes can lead to downtime (renaming a field or model), for which they have outlined the expand and contract pattern.
It might be a Prisma bug: https://github.com/prisma/prisma/issues/8053
I also recently had this situation. It probably should not try to run migration if you only want to create migration file.
But overall it is expected with Prisma to recreate your db sometimes. If you migration is breaking then it will be required to reset the data anyway when you apply it.
I suggest you to create some seeding script so you could consistently re-create the database state, it's very useful for your development environment.
More info
I have a Spring Boot application that uses Flyway for database migrations in Postgres.
It's about four years old now, so we're talking Flyway 4.0.3, Spring Boot 1.3.x, and Postgres 9.x. Versions could probably be upgraded, but I'd like to fix any existing issues before doing that.
In the meantime, Postgres was upgraded to higher than 9.x. Unfortunately, with that, a few of the existing migrations became outdated as they contain deprecated syntax. So now starting the app with a fresh database (i.e. in a development environment) leads to those migrations failing. In production it is fine as those migrations already have already been applied and won't be again.
I am curious as to what the best practices are to go about this. I can't just go and fix the syntax in the existing migrations, as this will lead to the checksums in the production environment failing. I know repair is a thing, however I am unsure how it works and how to use it with Spring Boot.
Failing SQL:
UPDATE config
SET (description) = 'my description'
WHERE ...
Correct SQL:
UPDATE config
SET description = 'my description'
WHERE ...
Error:
Message : ERROR: source for a multiple-column UPDATE item must be a sub-SELECT or ROW() expression
EDIT 24/04/2020 Spring Boot solution:
After Grant Fitchey posted the correct answer about how to use repair for this below, I am just going to add how I did this with Spring Boot specifically. I just created a bean of FlywayMigrationStrategy that calls
repair before it calls migrate:
#Bean
public FlywayMigrationStrategy cleanMigrateStrategy() {
return flyway -> {
flyway.repair();
flyway.migrate();
};
}
When deploying this to the production environment, during startup the checksums in the schema_versions table in Postgres were fixed. In another version I will remove the flyway.repair(); line again, as otherwise obviously this would create the risk of applying invalid migrations.
You are looking for the repair option. I don't know directly how to call it through spring boot, but the documentation is here. This should take care of exactly what you're looking for.
So the first step in this case would be to fix the migrations so they execute correctly in the development environment. Development should now be fine, and flyway should migrate successfully.
On production you should now get a validation error because the checksums differ. Flyway repair will 'repair' the schema history table so that the checksums it has stored match the new ones on disk, and therefore flyway validation passes again.
Specifically what flyway repair is doing is making the schema history table match what you have on disk. It updates all the checksums for applied migrations to the checksums of the ones you have on disk (and therefore, only use this if you are confident the changes are identical). It also removes all failed migration entries from the table (again, only use this once you have cleaned up the database yourself).
I used prisma to generate the schema to a database, but due to changing an id column started getting errors. I deleted the tables and was going to redeploy the schema but I can't find a way to do that.
I've already tried doing things like prisma deploy, but it tells me I'm already sync'd up which isn't true. I need it to redeploy as if the schema was new and it seems to not want to do that.
TL;DR: Try prisma delete then prisma deploy.
Prisma create a database for management where it will hold all migration related data. Even if you deleted the tables manually, you didn't change the migration data about your service. Therefore, Prisma think everything is up-to-date.
Instead of manually deleting the tables, you should use prisma delete to let Prisma do a clean deleting of your tables. Then, you can re-run prisma deploy to rebuild the tables again.
Give this a try: "prisma deploy --force"
According to the documentation you have to accept data loss caused by schema changes with --force. But the tables are already deleted in your case, so I think it is ok to try it.
Prisma doc
If some script fails during migration , flyway won't add record to schema_version in DB2 db for failed statement.
Do you have any idea how to avoid this situation?
I did a migration, 4th script failed, i expect this script will have status ABORTED/FAILED
One explanation for flyway behavior difference that you observe is the way Oracle handles DDL (implicit commit before/after each DDL) as compared with how Db2 handles DDL (implements DDL under transaction control by default). So with Db2 it's possible to arrange for each migration to be atomic and to rollback upon failure - meaning that there is nothing to repair, and therefore no repair action required as the flyway Oracle implementation may need.