원인: org.flywaydb.core.api.Flyway Exception:검증에 실패했습니다.마이그레이션 2에 대한 마이그레이션 체크섬 불일치
아래의 문제에 대한 해결책을 찾으려고 했지만, 어느 쪽도 효과가 없었습니다.MySQL+플라이웨이를 사용하여 Angular+Spring Boot 어플리케이션을 개발하고 있습니다.여기서 무슨 일이 일어나고 있는지 안내해주세요.
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'flywayInitializer' defined in class path resource [org/springframework/boot/autoconfigure/flyway/FlywayAutoConfiguration$FlywayConfiguration.class]: Invocation of init method failed; nested exception is org.flywaydb.core.api.FlywayException: Validate failed. Migration Checksum mismatch for migration 2
-> Applied to database : 1499248173
-> Resolved locally : -1729781252
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1578) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:296) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1054) ~[spring-context-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:829) ~[spring-context-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:538) ~[spring-context-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.refresh(EmbeddedWebApplicationContext.java:118) ~[spring-boot-1.3.1.RELEASE.jar:1.3.1.RELEASE]
at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:764) [spring-boot-1.3.1.RELEASE.jar:1.3.1.RELEASE]
at org.springframework.boot.SpringApplication.doRun(SpringApplication.java:357) [spring-boot-1.3.1.RELEASE.jar:1.3.1.RELEASE]
at org.springframework.boot.SpringApplication.run(SpringApplication.java:305) [spring-boot-1.3.1.RELEASE.jar:1.3.1.RELEASE]
at org.springframework.boot.SpringApplication.run(SpringApplication.java:1124) [spring-boot-1.3.1.RELEASE.jar:1.3.1.RELEASE]
at org.springframework.boot.SpringApplication.run(SpringApplication.java:1113) [spring-boot-1.3.1.RELEASE.jar:1.3.1.RELEASE]
at com.boot.App.main(App.java:9) [classes/:na]
Caused by: org.flywaydb.core.api.FlywayException: Validate failed. Migration Checksum mismatch for migration 2
-> Applied to database : 1499248173
-> Resolved locally : -1729781252
at org.flywaydb.core.Flyway.doValidate(Flyway.java:1108) ~[flyway-core-3.2.1.jar:na]
at org.flywaydb.core.Flyway.access$300(Flyway.java:62) ~[flyway-core-3.2.1.jar:na]
at org.flywaydb.core.Flyway$1.execute(Flyway.java:1012) ~[flyway-core-3.2.1.jar:na]
at org.flywaydb.core.Flyway$1.execute(Flyway.java:1006) ~[flyway-core-3.2.1.jar:na]
at org.flywaydb.core.Flyway.execute(Flyway.java:1418) ~[flyway-core-3.2.1.jar:na]
at org.flywaydb.core.Flyway.migrate(Flyway.java:1006) ~[flyway-core-3.2.1.jar:na]
at org.springframework.boot.autoconfigure.flyway.FlywayMigrationInitializer.afterPropertiesSet(FlywayMigrationInitializer.java:66) ~[spring-boot-autoconfigure-1.3.1.RELEASE.jar:1.3.1.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
... 18 common frames omitted
application.properties
logging.level.org.springframework.web=DEBUG
server.port=8080
spring.h2.console.enabled=true
spring.h2.console.path=/h2
## For H2 DB
#spring.datasource.url=jdbc:h2:file:~/dasboot
#spring.datasource.username=sa
#spring.datasource.password=
#spring.datasource.driver-class-name=org.h2.Driver
## For MYSQL DB
spring.datasource.url=jdbc:mysql://localhost:3306/dasboot
spring.datasource.username=root
spring.datasource.password=root
spring.datasource.driver-class-name=com.mysql.jdbc.Driver
spring.datasource.max-active=10
spring.datasource.max-idle=8
spring.datasource.max-wait=10000
spring.datasource.min-evictable-idle-time-millis=1000
spring.datasource.min-idle=8
spring.datasource.time-between-eviction-runs-millis=1
flyway.baseline-on-migrate=true
spring.jpa.hibernate.ddl-auto=false;
#datasource.flyway.url=jdbc:h2:file:~/dasboot
#datasource.flyway.username=sa
#datasource.flyway.password=
#datasource.flyway.driver-class-name=org.h2.Driver
datasource.flyway.url=jdbc:mysql://localhost:3306/dasboot
datasource.flyway.username=root
datasource.flyway.password=root
datasource.flyway.driver-class-name=com.mysql.jdbc.Driver
pom.xml
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.3.1.RELEASE</version>
</parent>
<name>das-boot</name>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<dependency>
<groupId>com.h2database</groupId>
<artifactId>h2</artifactId>
</dependency>
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
</dependency>
</dependencies>
V2__create_shipwreck.sql
-- For H2 DB
--CREATE TABLE SHIPWRECK(
-- ID INT AUTO_INCREMENT,
-- NAME VARCHAR(255),
-- DESCRIPTION VARCHAR(2000),
-- CONDITION VARCHAR(255),
-- DEPTH INT,
-- LATITUDE DOUBLE,
-- LONGITUDE DOUBLE,
-- YEAR_DISCOVERED INT
--);
CREATE TABLE `dasboot`.`shipwreck` (
`ID` INT NOT NULL AUTO_INCREMENT,
`NAME` VARCHAR(255) NULL,
`DESCRIPTION` VARCHAR(2000) NULL,
`CONDITION` VARCHAR(255) NULL,
`DEPTH` INT NULL,
`LATITUDE` DOUBLE NULL,
`LONGITUDE` DOUBLE NULL,
`YEAR_DISCOVERED` INT NULL,
PRIMARY KEY (`ID`));
Flyway는 SQL 스크립트의 체크섬을 이전에 실행한 체크섬과 비교하고 있습니다.이 예외는 일반적으로 Flyway에서 이미 적용된 SQL 스크립트를 변경하여 체크섬 불일치가 발생할 경우 발생합니다.
개발 중인 경우 데이터베이스를 삭제하고 처음부터 마이그레이션을 시작할 수 있습니다.
실제 가동 중인 경우 이미 적용된 SQL 스크립트를 편집하지 마십시오.향후 새로운 SQL 스크립트만 만듭니다.
여기에서는 로컬 시스템에서 이 문제가 발생했을 때 도움이 된 솔루션이 나와 있습니다.
- DB에서 flyway_schema_history로 이동합니다.
- SQL 마이그레이션 스크립트가 포함된 행을 삭제합니다.
같은 문제가 발생하여 데이터베이스에서 스키마 전체를 삭제했지만, 문제는 해결되지 않았습니다.
는 ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★repair()다음 중 하나:
flyway.repair();
또는 Flyway Maven 플러그인:
mvn flyway:repair
pom.xml에 Maven 플러그인 추가:
<plugin>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>5.2.4</version>
</plugin>
BTW: 나는 정확히 무엇이 잘못되었는지 찾지 못했다.
Gradle과 함께(Raf의 코멘트에 따라):
./gradlew flywayRepair
가장 좋은 해결책은 다음 단계를 수행하는 것입니다.
- V2__create_shipwreck.sql 파일을 삭제하고 프로젝트를 정리한 후 다시 빌드합니다.
프로젝트를 다시 실행하고 h2에 로그인한 후 "schema_version"이라는 테이블을 삭제합니다.
드롭 테이블 schema_version;
이제 ddl을 사용하여 V2__create_shipwreck.sql 파일을 만들고 프로젝트를 다시 실행합니다.
이것을 기억해 주세요.flyway-core 버전 4.1.2를 pom.xml에 추가합니다.
<dependency> <groupId>org.flywaydb</groupId> <artifactId>flyway-core</artifactId> <version>4.1.2</version> </dependency>
이제 작동해야 합니다.이게 도움이 되길 바라.
가동 중이 아닌 를 .flywayTable데이터베이스에서 적용된 스크립트의 이름이 포함된 행을 삭제합니다.
flywayTable는 플라이웨이가 사용하는 DB 내의 테이블 이름을 정의하는 프로젝트 옵션입니다.이 DB 버전에는 이미 적용된 스크립트의 정보가 포함되어 있습니다.
적용할 마이그레이션에서 벗어난 마이그레이션을 schema_version에서 삭제하기만 하면 됩니다.이렇게 하면 가지고 있을 수 있는 테스트 데이터가 폐기되지 않습니다.
예를 들어 다음과 같습니다.
SELECT * from schema_version order by installed_on desc
V_005_five.sql
V_004_four.sql
V_003_three.sql
V_002_two.sql
V_001_one.sql
적용할 이행
V_005_five.sql
* V_004_addUserTable.sql *
V_003_three.sql
V_002_two.sql
V_001_one.sql
해결책은 schema_version에서 삭제하는 것입니다.
V_005_five.sql
V_004_four.sql
데이터베이스 변경은 모두 원래대로 되돌립니다.예를 들어 스키마가 새 테이블을 생성한 경우 마이그레이션을 실행하기 전에 해당 테이블을 삭제해야 합니다.
플라이웨이를 주행할 때 다시 적용되기만 합니다.
V_005_five.sql
* V_004_addUserTable.sql *
새로운 schema_version은
V_005_five.sql
* V_004_addUserTable.sql *
V_003_three.sql
V_002_two.sql
V_001_one.sql
도움이 되었으면 좋겠다
SQL 파일의 수정이 기존 스키마에 영향을 미치지 않는 경우 기존 스키마의 체크섬도 업데이트할 수 있습니다.
sql 파일을 약간 변경한 후 이 작업을 수행했습니다.
체크섬을 갱신한 방법은 다음과 같습니다.
update flyway_schema_history set checksum = '-1934991199' where installed_rank = '1';
Flyway는 체크섬을 계산하는 방법을 버전 3에서 버전 5로 변경했습니다.체크섬을 다시 계산할 수 있습니다.Flyway 플러그인은 Spring 데이터 소스 속성을 제대로 읽지 않으므로 명령줄에서 수동으로 지정해야 합니다(또는 Flyway가 허용하는 다른 다양한 방법 중 하나).
mvn flyway:repair -Dflyway.user=root -Dflyway.password= -Dflyway.url=jdbc:mysql://localhost:3306/mydatabase -Dflyway.table=schema_version
에 Flyway도 해야 .flyway-table=schema_version이전 테이블을 사용하지 않으면 경고(버전 6의 오류도 있을 수 있음)가 표시됩니다.
[INFO] Repairing Schema History table for version 2 (Description: create sources, Type: SQL, Checksum: 2125962141) ...
[INFO] Repairing Schema History table for version 3 (Description: create stats, Type: SQL, Checksum: 389912194) ...
[INFO] Repairing Schema History table for version 4 (Description: add user encrypted, Type: SQL, Checksum: 182607572) ...
로컬 DB에서 이 쿼리를 사용합니다.
schema_version에서 schema_version delete에서 *를 선택합니다. 여기서 체크섬 열 = -1729781252;
주의: -1729781252는 "로컬로 해결됨" 값입니다.
서버를 빌드하여 기동합니다.
이 문제에 직면했을 때, 저는 DB에 접속하여 잘못된 버전에 대응하는 체크섬 필드를 업데이트하고 FlyWay에서 로컬로 해결된 값을 거기에 저장했습니다.
다음 오류의 경우:
nested exception is org.flywaydb.core.api.FlywayException: Validate failed.
Migration Checksum mismatch for migration 1.12
-> Applied to database : 1029320280
-> Resolved locally : -236187247
난 그냥 이렇게 했어:
UPDATE schema_version SET checksum = -236187247 WHERE version_rank = 12 AND checksum = 1029320280;
그리고 문제는 해결되었다.
메모: 스키마가 실제로 올바른지 확인하고 테이블과 그 구조를 확인해야 합니다.모든 것이 정상이라면 이 솔루션을 적용할 수 있습니다.그렇지 않으면 먼저 플레인 및 네이티브 SQL을 사용하여 스키마를 수동으로 복구해야 합니다.
저도 같은 문제가 있었습니다만, Linux와 Windows(Mac도 마찬가지)의 체크섬 때문에 발생한 것이라고 생각합니다.넌 할 수 있다.use repair()휘를맡맡 맡맡맡다다
flyway.repair();
에 있는 파일을 하십시오.SQL 파일을 할 때 " " " 를 실행할 때 입니다.flyway.repair();하는 것을 합니다.
추가만 하면 됩니다.
spring.flyway.enabled=false
응용 프로그램 실행 시마다 체크섬을 체크하지 않도록 하려면 application.properties 파일에 저장하십시오.
.sql을 DB에 적용한 후 .sql을 편집하면 flyway에서 이 오류가 나타날 수 있습니다.
Postgresql을 사용하는 경우 빠른 솔루션
"flyway_schema_histrory" 테이블과 .sql이 작성한 테이블을 삭제한 후 오류가 사라졌습니다.테이블 삭제
schema_version 레코드를 갱신하여 "로컬로 해결됨" 값(이 경우 -1729781252)을 마하합니다.
실제로는 다른 솔루션이 있습니다만, 이것은 회피책입니다.적절하게 관리되는 프로젝트에서는 실행할 수 없습니다.하지만 좋은 길을 갈 수 없는 상황을 만났다:)
schame_version 테이블을 업데이트하여 체크섬을 새 테이블로 변경할 수 있습니다.이로 인해 이행이 진행되지만 다른 부작용이 발생할 수 있습니다.
다른 환경(테스트, uat, prod 등)에 도입할 경우 더 많은 환경에서 동일한 체크섬을 업데이트해야 할 수 있습니다.또한 gitflow나 브랜치 릴리스에 관해서는 전체를 쉽게 혼재시킬 수 있습니다.
간단한 솔루션은 application.properties의 spring.spring.source.url=jdboot.file:~/dasboot을 spring.spring.spring.source.url=jdbc:h2:file:~/dasboots와 같은 새 파일 이름으로 변경하는 것입니다.
1-이행 파일을 삭제합니다.2-데이터베이스에 접속하여 이행에 의해 작성된 테이블을 드롭합니다.3-이행파일을 적절한 SQL로 재작성합니다.
운영 환경에 문제가 있는 경우 V2_create_shipwreck가 필요합니다.sql은 최신 버전에서 변경되지 않은 것과 동일합니다.
그러면 체크섬이 다시 정확해집니다.
동일한 문제가 발생하여 모든 옵션(스키마 삭제, 특정 행 삭제, 체크섬 업데이트)을 시도했지만 아무 것도 작동하지 않습니다.
저 같은 경우에는 플라이웨이 코어 의존성이 어떻게든 손상되었습니다.
솔루션:
~.m2\local 저장소 경로에서 flyway-core 폴더 삭제...\syslog\flywaydb\flyway-core.
"매븐 클린 인스톨"을 실행하여 새로운 클린 인스톨을 다운로드하여 프로젝트에 추가합니다.
이게 도움이 됐으면 좋겠어요.
개발 중에 이 문제를 해결하는 방법은 세 가지가 있습니다.이 문제는 아래에서 누구나 해결할 수 있습니다.
1)과 버전 1)의 증분 SQL의 합니다.
합니다 2) dburl dburl dburl dburl 。
file:~/flyway.url=jdbc:h2:file:~/filename3
file:~/filename4 flyway.url=jdbc:h2:file:~/filename4
3) 3) . 및 파일을 합니다.
/filenamefilename: mv cart3.mv 및 c c://users/filename/filename 3.120
검증하지 않음:
flyway.setValidateOnMigrate(false);
이 에러는, 다음의 3개의 순서로 수정했습니다.
- 데이터베이스에서 flyway_schema_history 테이블로 이동합니다.
- 최신 플라이웨이 이행 스크립트('V6__xxx' 등)가 포함된 마지막 행을 삭제합니다.
애플리케이션을 재기동합니다.일부 테이블에 행을 삽입하기 위한 SQL 덤프 같은 Flyway 오류 메시지가 표시됩니다.
- 해당 테이블로 이동하여 새 행을 삭제합니다.
플라이웨이 이행 스크립트는 다시 실행하려고 했지만 이미 한 번 실행되어 동일한 작업을 다시 시도하고 있었습니다. 같은 행을 삽입하면 마지막 충돌/오류입니다.이러한 행을 삭제하면 정상/정상적으로 실행할 수 있습니다.
저도 비슷한 문제에 직면한 적이 있습니다.그리고 해결책은...
DAO 클래스를 변경하지 마십시오. 데이터베이스를 변경하려고 하면 플라이웨이가 허용되지 않습니다.
언급URL : https://stackoverflow.com/questions/41147768/caused-by-org-flywaydb-core-api-flywayexception-validate-failed-migration-che
'programing' 카테고리의 다른 글
| Java를 사용하여 문자열에서 중복된 공백을 제거하려면 어떻게 해야 합니까? (0) | 2022.09.05 |
|---|---|
| 사용자 'User'@%'와 'User'@'localhost'가 같지 않습니까? (0) | 2022.09.05 |
| Vue: 등록하기 전에 vuex 스토어에서 사용자 설정 (0) | 2022.09.05 |
| Gson을 사용하는 Android에서 @SerializedName 주석의 기본 목적은 무엇입니까? (0) | 2022.09.05 |
| 어떻게 하면 PHP 타입 힌트에서 "캐치 가능한 치명적인 오류"를 잡을 수 있을까요? (0) | 2022.09.05 |