가동 중지 시간이 없는 배포 및 데이터베이스

이 문서에서는 배포 시 데이터베이스 호환성 문제를 해결하는 방법을 자세히 설명합니다. 사전 준비 없이 배포하려고 하면 프로덕션 애플리케이션에 어떤 일이 발생할 수 있는지 알려드리겠습니다. 그런 다음 가동 중지 시간이 없어야 하는 애플리케이션 수명 주기 단계를 살펴보겠습니다(대략. 차선: 추가 - 가동 중지 시간 없음). 우리 작업의 결과는 이전 버전과 호환되지 않는 데이터베이스 변경 사항을 이전 버전과 호환되는 방식으로 적용하는 것입니다.

기사의 코드 예제를 이해하려면 다음에서 찾을 수 있습니다. GitHub의.

소개

다운타임 없는 배포

정말 신비로운데요? 다운타임 없는 배포? 이는 사용자가 사용할 수 없음을 인식하지 못하는 동안 애플리케이션의 새 버전을 프로덕션에 성공적으로 도입할 수 있는 방식으로 애플리케이션이 배포되는 때라고 말할 수 있습니다. 사용자 및 회사 관점에서 볼 때 이는 중단 없이 새로운 기능을 도입하고 버그를 수정할 수 있기 때문에 가능한 최상의 배포 시나리오입니다.

이것을 달성하는 방법은 무엇입니까? 여러 가지 방법이 있는데, 그 중 하나는 다음과 같습니다.

• 서비스 버전 1을 배포하세요.
• 데이터베이스 마이그레이션 수행
• 버전 2과 병렬로 서비스 버전 1를 배포합니다.
• 버전 2가 정상적으로 작동하는 것을 확인하자마자 버전 1을 제거하십시오.
• 끝난!

쉽지요? 불행하게도 이는 그렇게 간단하지 않습니다. 이에 대해서는 나중에 자세히 살펴보겠습니다. 이제 또 다른 일반적인 배포 프로세스인 파란색 녹색 배포를 확인해 보겠습니다.

들어본 적이 있나요? 블루 그린 배포? Cloud Foundry를 사용하면 이를 매우 쉽게 수행할 수 있습니다. 그냥 봐 이 문서, 여기서 이에 대해 더 자세히 설명합니다. 간략하게 요약하자면, 블루 그린 배포를 수행하는 방법을 상기시켜 드리겠습니다.

• 프로덕션 코드 사본 XNUMX개("파란색" 및 "녹색")가 작동하는지 확인합니다.
• 모든 트래픽을 블루 환경으로 보냅니다. 즉, 프로덕션 URL이 그곳을 가리키도록 합니다.
• 친환경 환경에서 모든 애플리케이션 변경 사항을 배포하고 테스트합니다.
• URL을 파란색에서 녹색 환경으로 전환

블루 그린 배포는 프로덕션 중단에 대한 걱정 없이 새로운 기능을 쉽게 도입할 수 있는 접근 방식입니다. 무슨 일이 일어나더라도 '스위치를 살짝 누르는 것'만으로 쉽게 이전 환경으로 롤백할 수 있기 때문이다.

위의 내용을 모두 읽은 후 다음과 같은 질문이 생길 수 있습니다. 다운타임 제로가 블루 그린 배포와 어떤 관련이 있습니까?

글쎄요, 동일한 환경의 두 복사본을 유지하려면 두 배의 노력이 필요하기 때문에 공통점이 많습니다. 이것이 일부 팀이 주장하는 이유입니다. 마틴 파울러, 이 접근 방식의 변형을 따르십시오.

또 다른 옵션은 동일한 데이터베이스를 사용하여 웹 및 도메인 레이어에 대한 청록색 스위치를 만드는 것입니다. 이 접근 방식에서는 특히 새 버전의 소프트웨어를 지원하기 위해 데이터베이스의 스키마를 변경해야 하는 경우 데이터베이스가 문제가 될 수 있습니다.

그리고 여기서 우리는 이 글의 주요 문제에 도달합니다. 데이터베이스. 이 문구를 다시 살펴보겠습니다.

데이터베이스 마이그레이션을 수행합니다.

이제 스스로에게 질문을 던져야 합니다. 데이터베이스 변경 사항이 이전 버전과 호환되지 않으면 어떻게 될까요? 앱의 첫 번째 버전이 중단되지 않나요? 실제로 이런 일이 실제로 일어날 것입니다 ...

따라서 가동 중지 시간 없음/블루 그린 배포의 엄청난 이점에도 불구하고 기업은 애플리케이션 배포를 위해 다음과 같은 보다 안전한 프로세스를 따르는 경향이 있습니다.

• 새 버전의 애플리케이션으로 패키지 준비
• 실행 중인 애플리케이션 종료
• 스크립트를 실행하여 데이터베이스 마이그레이션
• 새 버전의 애플리케이션 배포 및 실행

이 문서에서는 가동 중지 시간 없는 배포를 활용하기 위해 데이터베이스 및 코드로 작업하는 방법을 자세히 설명합니다.

데이터베이스 문제

데이터베이스에 데이터를 저장하지 않는 상태 비저장 애플리케이션이 있는 경우 가동 중지 시간이 없는 배포를 즉시 얻을 수 있습니다. 불행하게도 대부분의 소프트웨어는 데이터를 어딘가에 저장해야 합니다. 이것이 회로를 변경하기 전에 두 번 생각해야 하는 이유입니다. 가동 중지 시간 없는 배포가 가능하도록 스키마를 변경하는 방법을 자세히 알아보기 전에 먼저 버전 관리 스키마에 중점을 두겠습니다.

버전 관리 체계

이 기사에서 우리는 플라이웨이 버전 관리 도구(대략. 번역: 우리는 데이터베이스 마이그레이션에 대해 이야기하고 있습니다.). 당연히 우리는 Flyway 지원이 내장된 Spring Boot 애플리케이션도 작성하고 애플리케이션 컨텍스트를 설정하는 동안 스키마 마이그레이션을 수행할 것입니다. Flyway를 사용하면 프로젝트 폴더에 마이그레이션 스크립트를 저장할 수 있습니다(기본적으로 classpath:db/migration). 여기에서 이러한 마이그레이션 파일의 예를 볼 수 있습니다.

└── db
 └── migration
     ├── V1__init.sql
     ├── V2__Add_surname.sql
     ├── V3__Final_migration.sql
     └── V4__Remove_lastname.sql

이 예에서는 이전에 실행되지 않은 경우 애플리케이션이 시작될 때 차례로 실행되는 4개의 마이그레이션 스크립트를 볼 수 있습니다. 파일 중 하나를 살펴보겠습니다(V1__init.sql) 예로서.

CREATE TABLE PERSON (
id BIGINT GENERATED BY DEFAULT AS IDENTITY,
first_name varchar(255) not null,
last_name varchar(255) not null
);

insert into PERSON (first_name, last_name) values ('Dave', 'Syer');

모든 것이 완벽하게 설명이 필요합니다. SQL을 사용하여 데이터베이스 수정 방법을 정의할 수 있습니다. Spring Boot 및 Flyway에 대한 자세한 내용은 다음을 확인하세요. 스프링 부트 문서.

Spring Boot와 함께 소스 제어 도구를 사용하면 두 가지 큰 이점을 얻을 수 있습니다.

• 데이터베이스 변경 사항과 코드 변경 사항을 분리합니다.
• 데이터베이스 마이그레이션은 애플리케이션 출시와 함께 발생합니다. 배포 프로세스가 단순화됩니다.

데이터베이스 문제 해결

기사의 다음 섹션에서는 데이터베이스 변경에 대한 두 가지 접근 방식을 살펴보는 데 중점을 둘 것입니다.

• 이전 버전과의 비호환성
• 하위 호환성

첫 번째는 사전 준비 없이 제로 다운타임 배포를 수행하면 안 된다는 경고로 간주됩니다... 두 번째는 다운타임 없이 배포를 수행하는 동시에 이전 버전과의 호환성을 유지할 수 있는 방법에 대한 솔루션을 제공합니다.

우리가 작업할 프로젝트는 간단한 Spring Boot Flyway 애플리케이션이 될 것입니다. Person с first_name и last_name 데이터베이스(대략. 번역: Person 는 테이블이고 f입니다irst_name и last_name - 이것은 그 안에 있는 필드입니다.). 이름을 바꾸고 싶습니다 last_name в surname.

가정

세부 사항을 살펴보기 전에 애플리케이션에 대해 몇 가지 가정을 해야 합니다. 우리가 달성하고자 하는 주요 결과는 상당히 간단한 프로세스입니다.

메모. 비즈니스 프로팁. 프로세스를 단순화하면 지원 비용을 많이 절약할 수 있습니다. 회사에서 일하는 사람이 많을수록 더 많은 비용을 절약할 수 있습니다!

데이터베이스를 롤백할 필요가 없습니다.

이는 배포 프로세스를 단순화합니다(삭제 롤백과 같은 일부 데이터베이스 롤백은 거의 불가능함). 우리는 애플리케이션만 롤백하는 것을 선호합니다. 이렇게 하면 서로 다른 데이터베이스(예: SQL 및 NoSQL)가 있더라도 배포 파이프라인이 동일하게 보입니다.

애플리케이션을 한 버전 이전으로 롤백하는 것은 항상 가능해야 합니다(더 이상은 가능하지 않음).

롤백은 필요한 경우에만 수행해야 합니다. 현재 버전에 쉽게 수정되지 않는 버그가 있는 경우 최신 작업 버전으로 되돌릴 수 있어야 합니다. 우리는 이 최신 작업 버전이 이전 버전이라고 가정합니다. 둘 이상의 롤아웃에 대해 코드 및 데이터베이스 호환성을 유지하는 것은 매우 어렵고 비용이 많이 듭니다.

참고 :. 가독성을 높이기 위해 이 문서에서는 애플리케이션의 주요 버전을 변경합니다.

1단계: 초기 상태

앱 버전 : 1.0.0
DB 버전: v1

논평

이것이 애플리케이션의 초기 상태가 됩니다.

데이터베이스 변경

DB에는 다음이 포함됩니다. last_name.

CREATE TABLE PERSON (
    id BIGINT GENERATED BY DEFAULT AS IDENTITY,
    first_name varchar(255) not null,
    last_name varchar(255) not null
);

insert into PERSON (first_name, last_name) values ('Dave', 'Syer');

코드 변경

응용 프로그램은 개인 데이터를 다음 위치에 저장합니다. last_name:

/*
 * Copyright 2012-2016 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package sample.flyway;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

@Entity
public class Person {
    @Id
    @GeneratedValue
    private Long id;
    private String firstName;
    private String lastName;

    public String getFirstName() {
        return this.firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    public String getLastName() {
        return this.lastName;
    }

    public void setLastName(String lastname) {
        this.lastName = lastname;
    }

    @Override
    public String toString() {
        return "Person [firstName=" + this.firstName + ", lastName=" + this.lastName
                + "]";
    }
}

이전 버전과 호환되지 않는 열 이름 바꾸기

열 이름을 변경하는 방법의 예를 살펴보겠습니다.

주의. 다음 예제에서는 의도적으로 작업을 중단합니다. 우리는 데이터베이스 호환성 문제를 보여주기 위해 이것을 보여줍니다.

앱 버전 : 2.0.0.BAD

DB 버전: v2bad

논평

현재 변경 사항으로 인해 두 개의 인스턴스(이전 인스턴스와 새 인스턴스)를 동시에 실행할 수 없습니다. 따라서 가동 중지 시간 제로 배포는 달성하기 어렵습니다(가정을 고려하면 실제로는 불가능합니다).

A/B 테스트

현재 상황은 애플리케이션 버전이 있다는 것입니다. 1.0.0, 프로덕션 및 데이터베이스에 배포 v1. 애플리케이션의 두 번째 인스턴스 버전을 배포해야 합니다. 2.0.0.BAD, 데이터베이스를 다음으로 업데이트합니다. v2bad.

단계 :

1. 버전 애플리케이션의 새 인스턴스가 배포됩니다. 2.0.0.BAD데이터베이스를 업데이트합니다. v2bad
2. 데이터베이스에서 v2bad 열 last_name 더 이상 존재하지 않습니다. 다음으로 변경되었습니다. surname
3. 데이터베이스 및 애플리케이션 업데이트가 성공했으며 일부 인스턴스가 실행 중입니다. 1.0.0, 기타 - 에 2.0.0.BAD. 모든 것이 데이터베이스에 연결되어 있습니다 v2bad
4. 버전의 모든 인스턴스 1.0.0 열에 데이터를 삽입하려고 시도하기 때문에 오류가 발생하기 시작합니다. last_name더 이상 존재하지 않는 사람
5. 버전의 모든 인스턴스 2.0.0.BAD 문제 없이 작동할 것이다

보시다시피, 데이터베이스와 애플리케이션에 이전 버전과 호환되지 않는 변경 사항을 적용하면 A/B 테스트가 불가능합니다.

애플리케이션 롤백

A/B 배포를 시도한 후 (대략. 당: 저자는 아마도 여기서 A/B 테스트를 의미했을 것입니다.) 우리는 애플리케이션을 이전 버전으로 롤백해야 한다고 결정했습니다. 1.0.0. 데이터베이스를 롤백하고 싶지 않다고 가정해 보겠습니다.

단계 :

1. 버전 애플리케이션 인스턴스를 중지합니다. 2.0.0.BAD
2. 데이터베이스는 아직 v2bad
3. 버전부터 1.0.0 그게 뭔지 이해하지 못해요 surname, 오류가 표시됩니다
4. 지옥이 풀렸어, 우린 더 이상 돌아갈 수 없어

보시다시피, 데이터베이스와 애플리케이션에 이전 버전과 호환되지 않는 변경 사항을 적용하면 이전 버전으로 롤백할 수 없습니다.

스크립트 실행 로그

Backward incompatible scenario:

01) Run 1.0.0
02) Wait for the app (1.0.0) to boot
03) Generate a person by calling POST localhost:9991/person to version 1.0.0
04) Run 2.0.0.BAD
05) Wait for the app (2.0.0.BAD) to boot
06) Generate a person by calling POST localhost:9991/person to version 1.0.0 <-- this should fail
07) Generate a person by calling POST localhost:9992/person to version 2.0.0.BAD <-- this should pass

Starting app in version 1.0.0
Generate a person in version 1.0.0
Sending a post to 127.0.0.1:9991/person. This is the response:

{"firstName":"b73f639f-e176-4463-bf26-1135aace2f57","lastName":"b73f639f-e176-4463-bf26-1135aace2f57"}

Starting app in version 2.0.0.BAD
Generate a person in version 1.0.0
Sending a post to 127.0.0.1:9991/person. This is the response:

curl: (22) The requested URL returned error: 500 Internal Server Error

Generate a person in version 2.0.0.BAD
Sending a post to 127.0.0.1:9995/person. This is the response:

{"firstName":"e156be2e-06b6-4730-9c43-6e14cfcda125","surname":"e156be2e-06b6-4730-9c43-6e14cfcda125"}

데이터베이스 변경

이름을 바꾸는 마이그레이션 스크립트 last_name в surname

소스 플라이웨이 스크립트:

CREATE TABLE PERSON (
    id BIGINT GENERATED BY DEFAULT AS IDENTITY,
    first_name varchar(255) not null,
    last_name varchar(255) not null
);

insert into PERSON (first_name, last_name) values ('Dave', 'Syer');

이름을 바꾸는 스크립트 last_name.

-- This change is backward incompatible - you can't do A/B testing
ALTER TABLE PERSON CHANGE last_name surname VARCHAR;

코드 변경

필드명을 변경했습니다 lastName 에 surname.

이전 버전과 호환되는 방식으로 열 이름 바꾸기

이것이 우리가 직면할 수 있는 가장 일반적인 상황입니다. 이전 버전과 호환되지 않는 변경을 해야 합니다. 우리는 다운타임 없는 배포를 위해 추가 단계 없이 단순히 데이터베이스 마이그레이션을 적용해서는 안 된다는 것을 이미 입증했습니다. 기사의 이 섹션에서는 이전 버전과의 호환성을 유지하면서 원하는 결과를 얻기 위해 데이터베이스 마이그레이션과 함께 3가지 애플리케이션 배포를 수행합니다.

메모. 버전 데이터베이스가 있다는 것을 기억하세요 v1. 열이 포함되어 있습니다. first_name и last_name. 우리는 변해야 해 last_name 에 surname. 앱 버전도 있습니다 1.0.0, 아직 사용되지 않은 것 surname.

2단계: 성 추가

앱 버전 : 2.0.0
DB 버전: v2

논평

새 열을 추가하고 해당 내용을 복사하여 이전 버전과 호환되는 데이터베이스 변경 사항을 만듭니다. 동시에 JAR을 롤백하거나 이전 JAR을 실행 중인 경우 실행 중에 중단되지 않습니다.

우리는 새로운 버전을 출시하고 있습니다

단계 :

1. 데이터베이스 마이그레이션을 수행하여 새 열 생성 surname. 이제 DB 버전 v2
2. 데이터 복사 last_name в surname. 주의이 데이터가 많으면 일괄 마이그레이션을 고려해야 합니다!
3. 사용되는 곳에 코드를 작성하세요. 둘 다 и 새로운과 오래 된 열. 이제 앱 버전 2.0.0
4. 열에서 값을 읽습니다. surname, 그렇지 않은 경우 null, 아니면 내가ast_name, if surname 명시되지 않은. 삭제할 수 있습니다 getLastName() 코드에서 출력되므로 null 애플리케이션을 롤백할 때 3.0.0 에 2.0.0.

Spring Boot Flyway를 사용하는 경우 버전 시작 중에 이 두 단계가 수행됩니다. 2.0.0 응용 프로그램. 데이터베이스 버전 관리 도구를 수동으로 실행하는 경우 이를 수행하려면 두 가지 다른 작업을 수행해야 합니다(먼저 db 버전을 수동으로 업데이트한 다음 새 애플리케이션을 배포).

그것은 중요합니다. 새로 생성된 열은 하지 말아야한다 있다 NULL 아님. 롤백을 수행하는 경우 이전 애플리케이션은 새 열에 대해 알지 못하므로 롤백 중에 이를 설치하지 않습니다. Insert. 하지만 이 제약 조건을 추가하면 DB는 v2, 새 열의 값을 설정해야 합니다. 이는 제한 위반으로 이어질 것입니다.

그것은 중요합니다. 메서드를 제거해야 합니다. getLastName(), 버전에서는 3.0.0 코드에는 열 개념이 없습니다. last_name. 이는 null이 거기에 설정된다는 것을 의미합니다. 메소드를 종료하고 다음에 대한 검사를 추가할 수 있습니다. null하지만 훨씬 더 나은 해결책은 논리에서 다음을 확인하는 것입니다. getSurname() XNUMX이 아닌 올바른 값을 선택했습니다.

A/B 테스트

현재 상황은 애플리케이션 버전이 있다는 것입니다. 1.0.0, 프로덕션에 배포되고 데이터베이스는 v1. 버전 애플리케이션의 두 번째 인스턴스를 배포해야 합니다. 2.0.0데이터베이스를 다음으로 업데이트합니다. v2.

단계 :

1. 버전 애플리케이션의 새 인스턴스가 배포됩니다. 2.0.0데이터베이스를 업데이트합니다. v2
2. 그 동안 일부 요청이 버전 인스턴스에 의해 처리되었습니다. 1.0.0
3. 업데이트가 성공했으며 버전 애플리케이션의 실행 중인 인스턴스가 여러 개 있습니다. 1.0.0 그리고 다른 버전 2.0.0. 모든 사람은 데이터베이스와 통신합니다. v2
4. 버전 1.0.0 데이터베이스의 성 열을 사용하지 않지만 버전 2.0.0 사용합니다. 서로 간섭하지 않으며 오류가 없어야 합니다.
5. 버전 2.0.0 이전 열과 새 열 모두에 데이터를 저장하여 이전 버전과의 호환성을 보장합니다.

그것은 중요합니다. 이전/새 열의 값을 기준으로 항목 수를 계산하는 쿼리가 있는 경우 이제 중복된 값이 있다는 점을 기억해야 합니다(아직 마이그레이션 중일 가능성이 높음). 예를 들어, 성(열 이름에 관계없이)이 문자로 시작하는 사용자 수를 계산하려는 경우 A, 데이터 마이그레이션이 완료될 때까지(old → new 열) 새 열을 쿼리하면 데이터가 일관되지 않을 수 있습니다.

애플리케이션 롤백

이제 앱 버전이 생겼습니다 2.0.0 그리고 데이터베이스 v2.

단계 :

1. 애플리케이션을 버전으로 롤백 1.0.0.
2. 버전 1.0.0 데이터베이스의 열을 사용하지 않습니다. surname이므로 롤백이 성공해야 합니다.

DB 변경

데이터베이스에는 다음과 같은 열이 포함되어 있습니다. last_name.

플라이웨이 소스 스크립트:

CREATE TABLE PERSON (
    id BIGINT GENERATED BY DEFAULT AS IDENTITY,
    first_name varchar(255) not null,
    last_name varchar(255) not null
);

insert into PERSON (first_name, last_name) values ('Dave', 'Syer');

스크립트 추가 surname.

주의. 추가하는 열에는 NOT NULL 제약 조건을 추가할 수 없다는 점을 기억하세요. JAR을 롤백하면 이전 버전은 추가된 열에 대해 전혀 모르고 자동으로 NULL로 설정됩니다. 그러한 제한이 있는 경우 이전 애플리케이션은 단순히 중단됩니다.

-- NOTE: This field can't have the NOT NULL constraint cause if you rollback, the old version won't know about this field
-- and will always set it to NULL
ALTER TABLE PERSON ADD surname varchar(255);

-- WE'RE ASSUMING THAT IT'S A FAST MIGRATION - OTHERWISE WE WOULD HAVE TO MIGRATE IN BATCHES
UPDATE PERSON SET PERSON.surname = PERSON.last_name

코드 변경

우리는 데이터를 다음과 같이 저장합니다. last_name,에서 surname. 동시에 우리는 다음을 읽었습니다. last_name, 이 열이 가장 관련성이 높기 때문입니다. 배포 프로세스 중에 아직 업데이트되지 않은 애플리케이션 인스턴스에 의해 일부 요청이 처리되었을 수 있습니다.

/*
 * Copyright 2012-2016 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package sample.flyway;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

@Entity
public class Person {
    @Id
    @GeneratedValue
    private Long id;
    private String firstName;
    private String lastName;
    private String surname;

    public String getFirstName() {
        return this.firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    /**
     * Reading from the new column if it's set. If not the from the old one.
     *
     * When migrating from version 1.0.0 -> 2.0.0 this can lead to a possibility that some data in
     * the surname column is not up to date (during the migration process lastName could have been updated).
     * In this case one can run yet another migration script after all applications have been deployed in the
     * new version to ensure that the surname field is updated.
     *
     * However it makes sense since when looking at the migration from 2.0.0 -> 3.0.0. In 3.0.0 we no longer
     * have a notion of lastName at all - so we don't update that column. If we rollback from 3.0.0 -> 2.0.0 if we
     * would be reading from lastName, then we would have very old data (since not a single datum was inserted
     * to lastName in version 3.0.0).
     */
    public String getSurname() {
        return this.surname != null ? this.surname : this.lastName;
    }

    /**
     * Storing both FIRST_NAME and SURNAME entries
     */
    public void setSurname(String surname) {
        this.lastName = surname;
        this.surname = surname;
    }

    @Override
    public String toString() {
        return "Person [firstName=" + this.firstName + ", lastName=" + this.lastName + ", surname=" + this.surname
                + "]";
    }
}

3단계: 코드에서 last_name 제거

앱 버전 : 3.0.0

DB 버전:v3

논평

메모 per.: 분명히 원본 기사에서 작성자는 실수로 2단계에서 이 블록의 텍스트를 복사했습니다. 이 단계에서는 해당 열을 사용하는 기능을 제거하기 위한 목적으로 애플리케이션 코드를 변경해야 합니다. last_name.

새 열을 추가하고 해당 내용을 복사하여 이전 버전과 호환되는 데이터베이스 변경 사항을 만들었습니다. 또한 JAR을 롤백하거나 이전 JAR을 실행 중인 경우 실행 중에 중단되지 않습니다.

애플리케이션 롤백

현재 앱 버전이 있습니다. 3.0.0 및 데이터베이스 v3... 버전 3.0.0 데이터를 저장하지 않습니다 last_name. 이는 다음을 의미합니다. surname 가장 최신 정보가 저장됩니다.

단계 :

1. 애플리케이션을 버전으로 롤백 2.0.0.
2. 버전 2.0.0 용도와 last_name и surname.
3. 버전 2.0.0 취할 것 surname, XNUMX이 아닌 경우, 그렇지 않은 경우 -last_name

데이터베이스 변경

데이터베이스에는 구조적 변화가 없습니다. 이전 데이터의 최종 마이그레이션을 수행하기 위해 다음 스크립트가 실행됩니다.

-- WE'RE ASSUMING THAT IT'S A FAST MIGRATION - OTHERWISE WE WOULD HAVE TO MIGRATE IN BATCHES
-- ALSO WE'RE NOT CHECKING IF WE'RE NOT OVERRIDING EXISTING ENTRIES. WE WOULD HAVE TO COMPARE
-- ENTRY VERSIONS TO ENSURE THAT IF THERE IS ALREADY AN ENTRY WITH A HIGHER VERSION NUMBER
-- WE WILL NOT OVERRIDE IT.
UPDATE PERSON SET PERSON.surname = PERSON.last_name;

-- DROPPING THE NOT NULL CONSTRAINT; OTHERWISE YOU WILL TRY TO INSERT NULL VALUE OF THE LAST_NAME
-- WITH A NOT_NULL CONSTRAINT.
ALTER TABLE PERSON MODIFY COLUMN last_name varchar(255) NULL DEFAULT NULL;

코드 변경

메모 per.: 이 블록에 대한 설명도 작성자가 2단계에서 실수로 복사했습니다. 기사의 논리에 따라 이 단계의 코드 변경 사항은 열과 함께 작동하는 요소를 제거하는 것을 목표로 해야 합니다. last_name.

우리는 데이터를 다음과 같이 저장합니다. last_name,에서 surname. 게다가 칼럼을 읽어보니 last_name, 가장 관련성이 높기 때문입니다. 배포 프로세스 중에 아직 업그레이드되지 않은 인스턴스에서 일부 요청이 처리될 수 있습니다.

/*
 * Copyright 2012-2016 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package sample.flyway;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

@Entity
public class Person {
    @Id
    @GeneratedValue
    private Long id;
    private String firstName;
    private String surname;

    public String getFirstName() {
        return this.firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    public String getSurname() {
        return this.surname;
    }

    public void setSurname(String lastname) {
        this.surname = lastname;
    }

    @Override
    public String toString() {
        return "Person [firstName=" + this.firstName + ", surname=" + this.surname
                + "]";
    }
}

4단계: 데이터베이스에서 last_name 제거

앱 버전 : 4.0.0

DB 버전: v4

논평

버전 코드 때문에 3.0.0 컬럼을 사용하지 않았습니다 last_name, 롤백하면 실행 중에 나쁜 일이 발생하지 않습니다. 3.0.0 데이터베이스에서 열을 제거한 후.

스크립트 실행 로그

We will do it in the following way:

01) Run 1.0.0
02) Wait for the app (1.0.0) to boot
03) Generate a person by calling POST localhost:9991/person to version 1.0.0
04) Run 2.0.0
05) Wait for the app (2.0.0) to boot
06) Generate a person by calling POST localhost:9991/person to version 1.0.0
07) Generate a person by calling POST localhost:9992/person to version 2.0.0
08) Kill app (1.0.0)
09) Run 3.0.0
10) Wait for the app (3.0.0) to boot
11) Generate a person by calling POST localhost:9992/person to version 2.0.0
12) Generate a person by calling POST localhost:9993/person to version 3.0.0
13) Kill app (3.0.0)
14) Run 4.0.0
15) Wait for the app (4.0.0) to boot
16) Generate a person by calling POST localhost:9993/person to version 3.0.0
17) Generate a person by calling POST localhost:9994/person to version 4.0.0

Starting app in version 1.0.0
Generate a person in version 1.0.0
Sending a post to 127.0.0.1:9991/person. This is the response:

{"firstName":"52b6e125-4a5c-429b-a47a-ef18bbc639d2","lastName":"52b6e125-4a5c-429b-a47a-ef18bbc639d2"}

Starting app in version 2.0.0

Generate a person in version 1.0.0
Sending a post to 127.0.0.1:9991/person. This is the response:

{"firstName":"e41ee756-4fa7-4737-b832-e28827a00deb","lastName":"e41ee756-4fa7-4737-b832-e28827a00deb"}

Generate a person in version 2.0.0
Sending a post to 127.0.0.1:9992/person. This is the response:

{"firstName":"0c1240f5-649a-4bc5-8aa9-cff855f3927f","lastName":"0c1240f5-649a-4bc5-8aa9-cff855f3927f","surname":"0c1240f5-649a-4bc5-8aa9-cff855f3927f"}

Killing app 1.0.0

Starting app in version 3.0.0

Generate a person in version 2.0.0
Sending a post to 127.0.0.1:9992/person. This is the response:
{"firstName":"74d84a9e-5f44-43b8-907c-148c6d26a71b","lastName":"74d84a9e-5f44-43b8-907c-148c6d26a71b","surname":"74d84a9e-5f44-43b8-907c-148c6d26a71b"}

Generate a person in version 3.0.0
Sending a post to 127.0.0.1:9993/person. This is the response:
{"firstName":"c6564dbe-9ab5-40ae-9077-8ae6668d5862","surname":"c6564dbe-9ab5-40ae-9077-8ae6668d5862"}

Killing app 2.0.0

Starting app in version 4.0.0

Generate a person in version 3.0.0
Sending a post to 127.0.0.1:9993/person. This is the response:

{"firstName":"cbe942fc-832e-45e9-a838-0fae25c10a51","surname":"cbe942fc-832e-45e9-a838-0fae25c10a51"}

Generate a person in version 4.0.0
Sending a post to 127.0.0.1:9994/person. This is the response:

{"firstName":"ff6857ce-9c41-413a-863e-358e2719bf88","surname":"ff6857ce-9c41-413a-863e-358e2719bf88"}

DB 변경

관련 v3 우리는 단지 열을 제거합니다 last_name 누락된 제한 사항을 추가합니다.

-- REMOVE THE COLUMN
ALTER TABLE PERSON DROP last_name;

-- ADD CONSTRAINTS
UPDATE PERSON SET surname='' WHERE surname IS NULL;
ALTER TABLE PERSON ALTER COLUMN surname VARCHAR NOT NULL;

코드 변경

코드에는 변경 사항이 없습니다.

출력

여러 가지 이전 버전과 호환되는 배포를 수행하여 이전 버전과 호환되지 않는 열 이름 변경을 성공적으로 적용했습니다. 다음은 수행된 작업을 요약한 것입니다.

1. 애플리케이션 버전 배포 1.0.0 с v1 데이터베이스 스키마(열 이름 = last_name)
2. 애플리케이션 버전 배포 2.0.0, 데이터를 저장하는 곳 last_name и surname. 응용 프로그램은 다음에서 읽습니다. last_name. 데이터베이스 버전이 다음과 같습니다. v2다음과 같은 열을 포함하는 last_name과 surname. surname l의 복사본이에요ast_name. (참고: 이 열에는 null이 아닌 제약 조건이 있어서는 안 됩니다.)
3. 애플리케이션 버전 배포 3.0.0, 데이터만 저장합니다. surname 성에서 읽습니다. 데이터베이스의 경우 마지막 마이그레이션이 진행 중입니다. last_name в surname. 또한 한계 NULL 아님 에서 제거됨 last_name. 데이터베이스가 현재 버전입니다 v3
4. 애플리케이션 버전 배포 4.0.0 - 코드는 변경되지 않습니다. 데이터베이스 배포 v4, 제거 last_name. 여기에서 데이터베이스에 누락된 제약 조건을 추가할 수 있습니다.

이 접근 방식을 따르면 데이터베이스/애플리케이션 호환성을 손상시키지 않고 항상 하나의 버전을 롤백할 수 있습니다.

암호

이 기사에 사용된 모든 코드는 다음에서 사용할 수 있습니다. 깃허브. 아래는 추가 설명입니다.

프로젝트

저장소를 복제하면 다음과 같은 폴더 구조를 볼 수 있습니다.

├── boot-flyway-v1              - 1.0.0 version of the app with v1 of the schema
├── boot-flyway-v2              - 2.0.0 version of the app with v2 of the schema (backward-compatible - app can be rolled back)
├── boot-flyway-v2-bad          - 2.0.0.BAD version of the app with v2bad of the schema (backward-incompatible - app cannot be rolled back)
├── boot-flyway-v3              - 3.0.0 version of the app with v3 of the schema (app can be rolled back)
└── boot-flyway-v4              - 4.0.0 version of the app with v4 of the schema (app can be rolled back)

스크립트

아래 스크립트에 설명된 스크립트를 실행할 수 있으며, 이는 데이터베이스에 대한 이전 버전과 호환되는 변경 사항과 호환되지 않는 변경 사항을 보여줍니다.

확인하려면 이전 버전과 호환되는 변경 사항이 있는 경우, 달리다:

./scripts/scenario_backward_compatible.sh

그리고 보기 위해 이전 버전과 호환되지 않는 변경 사항이 있는 경우, 달리다:

./scripts/scenario_backward_incompatible.sh

스프링 부트 샘플 이동 경로

모든 예제는 다음에서 가져왔습니다. Spring Boot Sample Flyway.

당신은 살펴볼 수 있습니다 http://localhost:8080/flyway, 스크립트 목록이 있습니다.

이 예에는 H2 콘솔도 포함되어 있습니다( http://localhost:8080/h2-console) 데이터베이스 상태를 볼 수 있습니다(기본 jdbc URL은 jdbc:h2:mem:testdb).

추가

• 데이터베이스 리팩토링 패턴
• 연속 배달

블로그에서 다른 기사도 읽어보세요.

• Kubernetes: 시스템 리소스 관리를 설정하는 것이 왜 그렇게 중요한가요?
• Tekton Pipeline - Kubernetes 기반 파이프라인
• Nginx용 동적 모듈 빌드
• Hashicorp Consul의 Kubernetes 인증 소개
• 승인이 없는 ClickHouse에서 승인이 있는 ClickHouse로 마이그레이션한 결과는 무엇입니까?
• Nginx 웹 서버를 사용하여 Spring 애플리케이션의 블루-그린 배포

출처 : habr.com