2014-07-15 5 views
0

우리는 "멀티 스키마"전략을 사용하는 멀티 테넌트 SaaS 애플리케이션을 보유하고 있습니다. 즉, 모든 고객은 동일한 데이터베이스 인스턴스에 전용 스키마를 가지고 있습니다. 우리는 MS SQL Server를 SQL Server "사용자"의 "기본 스키마"설정을 통해 스키마를 전환하는 데이터베이스로 사용하고 있습니다. 예를 들어 고객 A, B와 C는 SQL Server의 구성 내용은 다음과 같다 :다중 스키마 MS SQL Server 환경에서 Flyway를 사용하는 방법은 무엇입니까?

  • 고객 A를 : 기본 스키마 user_Aschema_A
  • 고객 B : 기본 스키마 user_Bschema_B
  • 고객 C를 : 기본적으로 user_C 스키마 schema_C ... 등등. 우리의 응용 프로그램에서

, 우리는 모든 쿼리하기 전에 다음과 같은 SQL을 실행하여 연결에 SQL 서버 "사용자"를 설정하여 각 고객에 대한 스키마를 수정 가리 키도록 데이터 소스 연결을 전환 :

EXECUTE AS USER = 'user_A'; 

이 포즈를 Flyway를 스키마 버전의 상태를 관리하기 위해 글로벌 방식으로 사용하려고 할 때 우리에게 몇 가지 문제가 있습니다. 이동 경로의 스키마 지원은 스키마 이름 목록 만 가져 오기 때문에 MS SQL Server에서는 작동하지 않습니다. Flyway는 DataSource 구성과 함께 제공되는 사용자의 기본 스키마에서 마이그레이션을 수행합니다. SQL Server의 경우 "사용자"는 고객/스키마별로 다를 필요가 있습니다.

FlywayCallback.beforeEachSchemaMigrate(Connection)과 같은 콜백을 사용하면 스키마 당 각 마이그레이션 전에 "사용자로 실행"문을 실행하여 스키마 당 원하는 사용자 컨텍스트를 설정할 수 있습니다. 그 고리가 왜 없는지 잘 모르겠습니까?

플라이 웨이의 또 다른 단점은 schema_version 테이블을 보유하고있는 스키마 목록에서 첫 번째 스키마를 사용하는 규칙입니다. SQL Server 기반 다중 테넌트 환경에서는이 작업이 바람직하지 않습니다. schema_version 테이블을 포함하는 스키마는 실제 고객 스키마라고 가정 할 수 없기 때문에. 우리와 같은 SaaS 애플리케이션에서 염두에두면, 세입자/고객 별 스키마는 즉시 작성/파괴됩니다. 사용자 로그인이되면 프로비져닝 프로세스의 일부가 일부 규칙에 따라 새 스키마를 만듭니다. 따라서 스키마 목록은 우리에게 동적입니다.

이상적으로 우리는 해당 스키마에서 마이 그 레이션을 실행하지 않고 주어진 스키마를 사용하여 schema_version 테이블을 생성하도록 Flyway에 지시 할 수 있습니다. 일반적으로이 스키마는 dbo 스키마 (SQL Server의 기본 스키마)입니다. 우리는 dbo 스키마를 사용하여 모든 테넌트에서 전역 적으로 테이블을 보유하고 schema_version은 전역 테이블로 간주합니다. 그래서 이주 완료 후 결국

, 우리의 데이터베이스는 다음과 같이한다 :

- dbo.schema_version 
- schema_A.my_tables 
- schema_B.my_tables 
- schema_C.my_tables 

지시 및 dbo.schema_version 테이블에 의해 제어 같은 "주"위의 스키마의 존재, 모두를.

현재 가능합니까?

답변

0

문제를 다르게 처리해야합니다. 모두를위한 이동 경로의 실행 대신 스키마 당 하나씩 이동하십시오. Flyway를 루프로 랩핑하고 반복마다 한 명의 세입자에 대해 올바른 구성으로 피드 할 수 있습니다. 세입자 당 하나의 schema_version 테이블로 끝나지 만, 모두 개별적으로 이름을 지정하고 dbo 스키마에 계속 살 수 있습니다.

+0

사실입니다. 이미 각 스키마를 반복하고 각 스키마에 대해 새로운 Flyway 인스턴스를 만드는 개념 증명 작업이 있습니다. 이는 잘 작동합니다 (계획은 B입니다). 사실이 경우 우리는 schema_version 테이블을 "글로벌"이 아니기 때문에 dbo에 넣지 않을 것이고, 그것들은 각각의 스키마에있을 것입니다. 그러나 이것의 단점은 동일한 데이터베이스의 모든 스키마가 동일한 "상태"에 있다는 보장이 없다는 것입니다. 한 스키마는 버전 2.0.1이고 다른 스키마는 2.0.2 일 수 있습니다. 이는 우리가 피하려고하는 것입니다. 스키마 콜백이없는 이유는 무엇입니까? –

+0

지금 우리는 스키마 당 별도의 이동 경로 인스턴스를 사용할 것입니다. 많은 다른 이유로 더 나은 접근 방법이 될 수 있습니다. –