शून्य डाउनटाइम डिप्लोयमेन्ट र डाटाबेसहरू

यस आलेखले विस्तारमा कसरी डाटाबेस अनुकूलता समस्याहरू डिप्लोयमेन्टमा समाधान गर्ने भनेर बताउँछ। यदि तपाईंले प्रारम्भिक तयारी बिना नै डिप्लोय गर्ने प्रयास गर्नुभयो भने हामी तपाईंको उत्पादन अनुप्रयोगहरूलाई के हुन सक्छ भन्ने कुरा बताउनेछौं। त्यसपछि हामी आवेदन जीवनचक्र चरणहरू पार गर्नेछौं जुन शून्य डाउनटाइम (लगभग। लेन: थप - शून्य डाउनटाइम)। हाम्रो अपरेसनको नतिजा ब्याकवर्ड-असंगत डाटाबेस परिवर्तनलाई ब्याकवर्ड-कम्प्याटिबल तरिकाले लागू गर्ने हो।

यदि तपाइँ लेखबाट कोड उदाहरणहरू बुझ्न चाहनुहुन्छ भने, तपाइँ तिनीहरूलाई फेला पार्न सक्नुहुन्छ GitHub.

परिचय

शून्य डाउनटाइम तैनाती

कस्तो रहस्यमय शून्य डाउनटाइम तैनाती? तपाइँ यो भन्न सक्नुहुन्छ जब तपाइँको एप्लिकेसन यस्तो तरिकाले डिप्लोइ गरिएको छ कि तपाइँ उत्पादनमा एप्लिकेसनको नयाँ संस्करण सफलतापूर्वक परिचय गर्न सक्नुहुन्छ, जबकि प्रयोगकर्ताले यसको अनुपलब्धतालाई याद गर्दैन। प्रयोगकर्ता र कम्पनीको परिप्रेक्ष्यबाट, यो उत्तम सम्भावित परिनियोजन परिदृश्य हो किनभने यसले नयाँ सुविधाहरू प्रस्तुत गर्न र बगहरू बिना अवरोध समाधान गर्न अनुमति दिन्छ।

यो कसरी हासिल गर्ने? त्यहाँ धेरै तरिकाहरू छन्, यहाँ तिनीहरूमध्ये एउटा हो:

• तपाइँको सेवाको संस्करण नम्बर 1 प्रयोग गर्नुहोस्
• डाटाबेस माइग्रेसन गर्नुहोस्
• संस्करण # 2 सँग समानान्तर रूपमा तपाईंको सेवाको संस्करण # 1 प्रयोग गर्नुहोस्
• जसरी तपाईंले त्यो संस्करण नम्बर 2 ले जस्तै काम गरेको देख्नुहुन्छ, संस्करण नम्बर 1 हटाउनुहोस्
• तयार छ!

सजिलो, हैन? दुर्भाग्यवश, यो त्यति सरल छैन, र हामी यसलाई पछि विस्तारमा हेर्नेछौं। अब हामी अर्को एकदम सामान्य तैनाती प्रक्रिया जाँच गरौं - नीलो हरियो तैनाती।

के तपाइँ कहिल्यै सुन्नुभएको छ नीलो हरियो परिनियोजन? क्लाउड फाउन्ड्रीले यो अत्यन्तै सजिलो बनाउँछ। हेरे मात्रै यो लेख, जहाँ हामी यसलाई थप विवरणमा वर्णन गर्छौं। छोटकरीमा संक्षेप गर्न, हामी तपाईंलाई निलो हरियो डिप्लोइमेन्ट कसरी गर्ने भनेर सम्झाउने गरौं:

• तपाईंको उत्पादन कोड ("नीलो" र "हरियो") को दुई प्रतिहरू काम गरेको सुनिश्चित गर्नुहोस्;
• सबै ट्राफिकलाई निलो वातावरणमा निर्देशित गर्नुहोस्, अर्थात्। ताकि उत्पादन URL ले त्यहाँ देखाउँछ;
• हरियो वातावरणमा सबै अनुप्रयोग परिवर्तनहरू तैनात र परीक्षण गर्नुहोस्;
• नीलोबाट हरियो वातावरणमा यूआरएलहरू बदल्नुहोस्

नीलो हरियो तैनाती एक दृष्टिकोण हो जसले तपाईंलाई उत्पादन तोड्ने बारे चिन्ता नगरी सजिलैसँग नयाँ सुविधाहरू परिचय गर्न अनुमति दिन्छ। यो यस तथ्यको कारणले हो कि यदि केहि भयो भने पनि, तपाईं सजिलैसँग "स्विच फ्लिक" गरेर अघिल्लो वातावरणमा फर्कन सक्नुहुन्छ।

माथिका सबै पढिसकेपछि, तपाईंले प्रश्न सोध्न सक्नुहुन्छ: शून्य डाउनटाइमले नीलो हरियो परिनियोजनसँग के गर्छ?

ठीक छ, तिनीहरूमा धेरै समानता छ, किनकि एउटै वातावरणको दुई प्रतिलिपिहरू कायम राख्न तिनीहरूलाई कायम राख्न दोब्बर प्रयास चाहिन्छ। यही कारणले केही टोलीले दाबी गरिरहेका छन् मार्टिन फाउलर, यस दृष्टिकोणको भिन्नता अनुसरण गर्नुहोस्:

अर्को विकल्प भनेको समान डाटाबेस प्रयोग गर्नु हो, वेब र डोमेन तहहरूको लागि नीलो-हरियो स्विचहरू सिर्जना गर्ने। यस दृष्टिकोणमा, डाटाबेस प्राय: समस्या हुन सक्छ, विशेष गरी जब तपाइँ सफ्टवेयरको नयाँ संस्करण समर्थन गर्न यसको स्कीमा परिवर्तन गर्न आवश्यक छ।

र यहाँ हामी यस लेखमा मुख्य समस्या आउछौं। डाटाबेस। यस वाक्यांशलाई अर्को हेरौं।

डाटाबेस माइग्रेसन गर्नुहोस्।

अब तपाईले आफैलाई प्रश्न सोध्नु पर्छ - यदि डाटाबेस परिवर्तन पछाडि अनुकूल छैन भने के हुन्छ? मेरो एपको पहिलो संस्करण टुट्ने छैन? वास्तवमा, यो वास्तवमा के हुनेछ ...

त्यसोभए, शून्य डाउनटाइम / नीलो हरियो डिप्लोइमेन्टको ठूला फाइदाहरूको साथ पनि, कम्पनीहरूले उनीहरूको अनुप्रयोगहरू प्रयोग गर्नको लागि निम्न सुरक्षित प्रक्रियालाई पछ्याउँछन्:

• अनुप्रयोगको नयाँ संस्करणको साथ प्याकेज तयार गर्नुहोस्
• चलिरहेको अनुप्रयोग बन्द गर्नुहोस्
• डाटाबेस माइग्रेट गर्न स्क्रिप्टहरू चलाउनुहोस्
• लागू गर्नुहोस् र अनुप्रयोगको नयाँ संस्करण सुरु गर्नुहोस्

यस लेखमा, हामी तपाइँ कसरी तपाइँको डाटाबेस र कोडसँग शून्य डाउनटाइम डिप्लोयमेन्टको फाइदा लिनको लागि काम गर्न सक्नुहुन्छ भन्ने विवरण दिनेछौं।

डाटाबेस मुद्दाहरू

यदि तपाइँसँग स्टेटलेस एप्लिकेसन छ जुन डाटाबेसमा कुनै पनि डाटा भण्डार गर्दैन, तपाइँ तुरुन्तै शून्य डाउनटाइम डिप्लोइमेन्ट प्राप्त गर्न सक्नुहुन्छ। दुर्भाग्यवश, धेरै सफ्टवेयरले डेटा कतै भण्डारण गर्न आवश्यक छ। यसकारण तपाईंले सर्किटमा कुनै पनि परिवर्तन गर्नु अघि दुई पटक सोच्नुपर्छ। हामीले स्किमा कसरी परिवर्तन गर्ने भनेर विवरणमा जानु अघि कुनै-डाउनटाइम डिप्लोइमेन्ट सम्भव छ, पहिले संस्करणिंग स्कीमामा ध्यान केन्द्रित गरौं।

संस्करण योजना

यस लेखमा हामी प्रयोग गर्नेछौं फ्लाईवे संस्करण नियन्त्रण उपकरणको रूपमा (लगभग। प्रति।: हामी डाटाबेस माइग्रेसनको बारेमा कुरा गर्दैछौं)। स्वाभाविक रूपमा, हामीले स्प्रिङ बुट एप्लिकेसन पनि लेख्ने छौँ जसमा फ्लाईवे सपोर्ट बिल्ट-इन छ र एप्लिकेसन कन्टेक्स्ट सेटअप गर्दा स्किमा माइग्रेसन गर्नेछ। 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 प्रयोग गर्न सक्नुहुन्छ। वसन्त बुट र फ्लाईवे बारे थप जानकारीको लागि, जाँच गर्नुहोस् वसन्त बुट कागजात.

वसन्त बुटको साथ स्रोत नियन्त्रण उपकरण प्रयोग गरेर, तपाईंले 2 ठूला फाइदाहरू प्राप्त गर्नुहुन्छ:

• तपाईले डाटाबेस परिवर्तनहरू कोड परिवर्तनहरूबाट अलग गर्नुहुन्छ
• डाटाबेस माइग्रेसन तपाईंको एप्लिकेसनको रोलआउटसँगै हुन्छ, अर्थात्। तपाइँको तैनाती प्रक्रिया सरलीकृत छ

डाटाबेस समस्याहरूको निवारण

लेखको अर्को खण्डमा, हामी डाटाबेस परिवर्तनहरूका लागि दुई दृष्टिकोणहरू हेर्नमा ध्यान केन्द्रित गर्नेछौं।

• पछाडिको असंगति
• पछाडि अनुकूलता

पहिलोलाई चेतावनीको रूपमा मानिनेछ कि तपाईंले प्रारम्भिक तयारी बिना शून्य डाउनटाइम डिप्लोइमेन्ट प्रदर्शन गर्नु हुँदैन... दोस्रोले तपाइँ कसरी डाउनटाइम बिना डिप्लोयमेन्ट गर्न सक्नुहुन्छ र एकै समयमा पछाडि अनुकूलता कायम राख्न सक्नुहुन्छ भन्ने समाधान प्रदान गर्दछ।

हामीले काम गर्ने हाम्रो परियोजना एक साधारण वसन्त बुट फ्लाईवे अनुप्रयोग हुनेछ Person с first_name и last_name डाटाबेसमा (लगभग। अनुवाद: Person एउटा तालिका र first_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, वा l बाटast_nameयदि surname तोकिएको छैन। मेटाउन सक्नुहुन्छ getLastName() कोडबाट, किनकि यसले आउटपुट गर्नेछ null बाट आफ्नो आवेदन फिर्ता गर्दा 3.0.0 गर्न 2.0.0.

यदि तपाइँ Spring Boot Flyway प्रयोग गर्दै हुनुहुन्छ भने, यी दुई चरणहरू संस्करण स्टार्टअपको समयमा प्रदर्शन गरिनेछ 2.0.0 अनुप्रयोगहरू। यदि तपाइँ म्यानुअल रूपमा डाटाबेस संस्करण उपकरण चलाउनुहुन्छ भने, तपाइँले यो गर्न दुई फरक चीजहरू गर्नुपर्नेछ (पहिले db संस्करण म्यानुअल रूपमा अपडेट गर्नुहोस् र त्यसपछि नयाँ अनुप्रयोग प्रयोग गर्नुहोस्)।

यो महत्वपूर्ण छ। याद गर्नुहोस् कि नयाँ सिर्जना गरिएको स्तम्भ गर्नु हुँदैन हुनु होइन। यदि तपाइँ एक रोलब्याक गर्नुहुन्छ भने, पुरानो अनुप्रयोगलाई नयाँ स्तम्भको बारेमा थाहा छैन र यो समयमा स्थापना हुनेछैन। Insert. तर यदि तपाइँ यो बाधा थप्नुहुन्छ र तपाइँको db हुनेछ v2, यसले नयाँ स्तम्भको मान सेट गर्न आवश्यक हुनेछ। जसले प्रतिबन्धको उल्लङ्घन गर्न नेतृत्व गर्नेछ।

यो महत्वपूर्ण छ। तपाईंले विधि हटाउनु पर्छ getLastName(), किनभने संस्करणमा 3.0.0 कोडमा स्तम्भको कुनै अवधारणा छैन last_name। यसको मतलब त्यहाँ शून्य सेट हुनेछ। तपाइँ विधि छोड्न सक्नुहुन्छ र चेकहरू थप्न सक्नुहुन्छ null, तर धेरै राम्रो समाधान तर्क मा सुनिश्चित गर्न को लागी हुनेछ getSurname() तपाईंले सही गैर-शून्य मान चयन गर्नुभयो।

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.

ध्यान। याद गर्नुहोस् कि तपाईले थप्नु भएको स्तम्भमा कुनै पनि शून्य बाधाहरू थप्न सक्नुहुन्न। यदि तपाईंले 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: कोडबाट अन्तिम_नाम हटाउँदै

अनुप्रयोग संस्करण: 3.0.0

DB संस्करण:v3

टिप्पणी

नोट प्रति।: स्पष्ट रूपमा, मूल लेखमा लेखकले गल्तीले चरण 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, यदि यो शून्य छैन, अन्यथा -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;

कोड परिवर्तन

नोट प्रति।: यस ब्लकको विवरण पनि गल्तीले चरण 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: डाटाबेसबाट अन्तिम_नाम हटाउँदै

अनुप्रयोग संस्करण: 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। (नोट: यो स्तम्भमा शून्य अवरोध हुनुहुँदैन)
3. आवेदन संस्करण को तैनाती 3.0.0, जसले डाटा मात्र भण्डारण गर्छ surname र उपनामबाट पढ्छ। डाटाबेसको लागि, अन्तिम माइग्रेसन भइरहेको छ last_name в surname। पनि एक सीमा होइन बाट हटाइयो last_name। डाटाबेस अहिले संस्करणमा छ v3
4. आवेदन संस्करण को तैनाती 4.0.0 - कोडमा कुनै परिवर्तन गरिएको छैन। डाटाबेस परिनियोजन v4, जसले हटाउँछ last_name। यहाँ तपाईँले डाटाबेसमा कुनै पनि छुटेका बाधाहरू थप्न सक्नुहुन्छ।

यो दृष्टिकोण पछ्याएर तपाईले डाटाबेस/एप्लिकेशन अनुकूलता तोड्न बिना सधैं एउटा संस्करण फिर्ता गर्न सक्नुहुन्छ।

कोड

यस लेखमा प्रयोग गरिएका सबै कोडहरू उपलब्ध छन् Github। तल अतिरिक्त विवरण छ।

परियोजनाहरू

भण्डार क्लोन गरेपछि, तपाईंले निम्न फोल्डर संरचना देख्नुहुनेछ।

├── 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 पाइपलाइन - Kubernetes-स्थानीय पाइपलाइन
• Nginx को लागि गतिशील मोड्युलहरू निर्माण गर्दै
• Hashicorp Consul को Kubernetes प्राधिकरण को परिचय
• प्राधिकरण बिना क्लिकहाउसबाट क्लिकहाउसमा प्राधिकरणको साथ माइग्रेसनले के निम्त्यायो?
• Nginx वेब सर्भरको साथ वसन्त अनुप्रयोगहरूको निलो-हरियो तैनाती

स्रोत: www.habr.com