2017-03-22 6 views
2

이동 경로 DB 마이그레이션과 관련된 질문이 있습니다. 동일한 DB 스키마를 다루는 여러 프로젝트 (마이크로 서비스)를 일반적으로 관리하는 방법. 각 프로젝트의 이동 경로 마이그레이션 스크립트는 다른 프로젝트에 의해 수정 된 경우 시작을 허용하지 않습니다. 그들은 동일한 문서 또는 모범 사례를 가지고 있습니까?단일 스키마 및 다중 프로젝트로 이동 경로 이동

+0

각 마이크로 서비스는 자체 데이터를 관리하고 별도의 DB 스키마가 있어야하는 것이 이상적입니다. 그것은 나쁜 연습과 서비스 사이의 DB 스키마를 공유하는 마이크로 서비스 아키텍처의 규칙을 깰. – sezerug

+1

DB 스키마를 단일 모듈로 관리 (마이그레이션 포함)해야한다는 것이 중요하지만 여러 모듈에서 공유 할 수 있습니다. 공유 DB가있는 마이크로 서비스 아키텍처는 새로운 것이 아니며 수천 개의 유스 케이스에서 널리 사용되는 아키텍처라고 생각합니다. – user3808122

답변

1

무엇이 가치있는 일인지, 이것이 우리가 한 일입니다. 스키마가 여러 프로젝트에서 공유되었으므로이 스키마를 유지 관리하는 작업을 수행하는 단일 프로젝트로 스키마를 관리했습니다. 스키마 생성 및 유지 관리의 집중화는 우리가 단일 변경의 위치를 ​​가졌다는 점에서 다른 이점을 제공합니다. 우리는 변화를 위해 여러 프로젝트를 스캔 할 필요가 없습니다.

솔직히 말해서 이것이 최선의 해결책이라고 생각합니다. 나는 flyway가 프로젝트 간 스키마 의존성 관리를한다고 생각하지 않는다.

+0

이 별도의 프로젝트에는 이동 경로 설정 및 마이그레이션 파일 만 포함 되었습니까? 아니면 모든 응용 프로그램 SQL 문 (일반 'SELECT'등)을이 중앙 프로젝트로 이동 했습니까? –

0

우리는이 작업을 진행하고 있습니다. 우리는 스키마 생성/관리를 관리하는 하나의 중앙 프로젝트를 가지고 있으며, 다른 프로젝트는 자체적 인 이동 경로 버전 관리를 통해 자신의 함수 생성을 처리합니다. 이 작업은 다른 프로젝트가 스키마 버전을 확인하는 테이블의 이름을 변경하고 migrate의 기준선을 true로 설정하여 수행됩니다. 우리는 spring/flyway-db 설정을 사용하고 있기 때문에 첫 번째 파일뿐 아니라 각 프로젝트에 대해 다음을 application.properties에 간단하게 추가했습니다.

flyway.baselineOnMigrate=true 
flyway.table=schema_verison_*<some_other_identifier>* 

나는 귀하의 질문에 명시 적으로 스프링 구성에서 지정할하지 않았다 알고 있지만, 나는 이것이 당신이 이동 경로를 사용하는 방법에 문제가되지 구성 할 수 있다고 생각합니다. 나는 그 질문을 가장 먼저 찾았을 때 대답을 게시하고 싶었고, 그 대답은 내 대답이 누군가를 도와 줄 수 있다고 생각했다.