🥇शून्य डाउनटाइम परिनियोजन और डेटाबेस

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

यदि आप लेख से कोड उदाहरणों को समझना चाहते हैं, तो आप उन्हें यहां पा सकते हैं GitHub.

परिचय

शून्य डाउनटाइम परिनियोजन

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

इसे कैसे हासिल करें? इसके कई तरीके हैं, उनमें से एक यहां दिया गया है:

अपनी सेवा का संस्करण क्रमांक 1 तैनात करें
डेटाबेस माइग्रेशन निष्पादित करें
अपनी सेवा के संस्करण #2 को संस्करण #1 के समानांतर तैनात करें
जैसे ही आप देखें कि संस्करण क्रमांक 2 उसी तरह काम करता है जैसा उसे करना चाहिए, संस्करण क्रमांक 1 को हटा दें
तैयार!

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

क्या तुमने कभी सुना है नीला हरा परिनियोजन? क्लाउड फाउंड्री इसे बेहद आसान बनाती है। बस देखो यह लेख, जहां हम इसका अधिक विस्तार से वर्णन करते हैं। संक्षेप में संक्षेप में बताने के लिए, आइए हम आपको याद दिलाएँ कि नीला हरा परिनियोजन कैसे करें:

सुनिश्चित करें कि आपके उत्पादन कोड की दो प्रतियां ("नीली" और "हरी") काम करती हैं;
सभी ट्रैफ़िक को नीले वातावरण की ओर निर्देशित करें, अर्थात ताकि उत्पादन यूआरएल वहीं इंगित करें;
हरित वातावरण में सभी एप्लिकेशन परिवर्तनों को तैनात करना और उनका परीक्षण करना;
यूआरएल को नीले से हरे वातावरण में बदलें

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

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

खैर, उनमें काफी समानताएं हैं, क्योंकि एक ही वातावरण की दो प्रतियों को बनाए रखने के लिए उन्हें बनाए रखने के लिए दोगुने प्रयास की आवश्यकता होती है। यही कारण है कि कुछ टीमें दावा करती हैं मार्टिन फाउलर, इस दृष्टिकोण की एक भिन्नता का पालन करें:

एक अन्य विकल्प वेब और डोमेन परतों के लिए नीले-हरे स्विच बनाकर उसी डेटाबेस का उपयोग करना है। इस दृष्टिकोण में, डेटाबेस अक्सर एक समस्या हो सकता है, खासकर जब आपको सॉफ़्टवेयर के नए संस्करण का समर्थन करने के लिए इसकी स्कीमा को बदलने की आवश्यकता होती है।

और यहां हम इस लेख में मुख्य समस्या पर आते हैं। डेटाबेस. आइए इस वाक्यांश पर एक और नज़र डालें।

डेटाबेस माइग्रेशन निष्पादित करें.

अब आपको खुद से सवाल पूछना होगा - क्या होगा यदि डेटाबेस परिवर्तन पश्चगामी संगत नहीं है? क्या ऐप का मेरा पहला संस्करण टूट नहीं जाएगा? दरअसल, यही होगा...

इसलिए, शून्य डाउनटाइम/ब्लू ग्रीन परिनियोजन के भारी लाभों के बावजूद, कंपनियां अपने अनुप्रयोगों को तैनात करने के लिए निम्नलिखित सुरक्षित प्रक्रिया का पालन करती हैं:

एप्लिकेशन के नए संस्करण के साथ एक पैकेज तैयार करें
चल रहे एप्लिकेशन को बंद करें
डेटाबेस को माइग्रेट करने के लिए स्क्रिप्ट चलाएँ
एप्लिकेशन का एक नया संस्करण तैनात और लॉन्च करें

इस आलेख में, हम विस्तार से बताएंगे कि शून्य डाउनटाइम परिनियोजन का लाभ उठाने के लिए आप अपने डेटाबेस और कोड के साथ कैसे काम कर सकते हैं।

डेटाबेस की समस्याएं

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

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

इस लेख में हम प्रयोग करेंगे 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 एक टेबल है और एफirst_name и last_name - ये इसमें फ़ील्ड हैं). हम नाम बदलना चाहते हैं last_name в surname.

मान्यताओं

विवरण में जाने से पहले, हमें अपने अनुप्रयोगों के बारे में कुछ धारणाएँ बनाने की आवश्यकता है। मुख्य परिणाम जो हम प्राप्त करना चाहते हैं वह काफी सरल प्रक्रिया होगी।

नोट। बिजनेस प्रो-टिप। प्रक्रियाओं को सरल बनाने से आप समर्थन पर बहुत सारा पैसा बचा सकते हैं (जितने अधिक लोग आपकी कंपनी के लिए काम करेंगे, उतना अधिक पैसा आप बचा सकते हैं)!

डेटाबेस को रोलबैक करने की कोई आवश्यकता नहीं है

यह परिनियोजन प्रक्रिया को सरल बनाता है (कुछ डेटाबेस रोलबैक लगभग असंभव हैं, जैसे विलोपन रोलबैक)। हम केवल एप्लिकेशन वापस लेना पसंद करते हैं। इस तरह, भले ही आपके पास अलग-अलग डेटाबेस हों (उदाहरण के लिए, SQL और NoSQL), आपकी परिनियोजन पाइपलाइन एक जैसी दिखेगी।

एप्लिकेशन को एक संस्करण में वापस रोल करना हमेशा संभव होना चाहिए (अब और नहीं)

आवश्यक होने पर ही रोलबैक किया जाना चाहिए। यदि वर्तमान संस्करण में कोई बग है जिसे आसानी से ठीक नहीं किया जा सकता है, तो हमें नवीनतम कार्यशील संस्करण पर वापस लौटने में सक्षम होना चाहिए। हम मानते हैं कि यह नवीनतम कार्यशील संस्करण पिछला संस्करण है। एक से अधिक रोलआउट के लिए कोड और डेटाबेस संगतता बनाए रखना बेहद कठिन और महंगा होगा।

Заметка. अधिक पठनीयता के लिए, इस लेख में हम एप्लिकेशन के प्रमुख संस्करण को बदल देंगे।

चरण 1: प्रारंभिक अवस्था

अनुप्रयोग संस्करण: 1.0.0
डीबी संस्करण: v1

टिप्पणी

यह एप्लिकेशन की प्रारंभिक स्थिति होगी.

डेटाबेस परिवर्तन

डीबी में शामिल है 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

डीबी संस्करण: v2bad

टिप्पणी

वर्तमान परिवर्तन हमें एक ही समय में दो उदाहरण (पुराने और नए) चलाने की अनुमति नहीं देते हैं। इस प्रकार, शून्य डाउनटाइम परिनियोजन प्राप्त करना कठिन होगा (यदि मान्यताओं को ध्यान में रखा जाए, तो यह वास्तव में असंभव है)।

ए/बी परीक्षण

वर्तमान स्थिति यह है कि हमारे पास एक एप्लिकेशन संस्करण है 1.0.0, उत्पादन और डेटाबेस में तैनात किया गया v1. हमें एप्लिकेशन का दूसरा उदाहरण, संस्करण तैनात करने की आवश्यकता है 2.0.0.BAD, और डेटाबेस को अद्यतन करें v2bad.

कदम:

संस्करण एप्लिकेशन का एक नया उदाहरण तैनात किया गया है 2.0.0.BADजो डेटाबेस को अपडेट करता है v2bad
डेटाबेस में v2bad स्तंभ last_name अब अस्तित्व में नहीं है - इसे बदल दिया गया था surname
डेटाबेस और एप्लिकेशन अद्यतन सफल रहा और कुछ इंस्टेंस चल रहे हैं 1.0.0, अन्य - में 2.0.0.BAD. सब कुछ डेटाबेस से जुड़ा हुआ है v2bad
संस्करण के सभी उदाहरण 1.0.0 त्रुटियाँ उत्पन्न करना शुरू कर देंगे क्योंकि वे कॉलम में डेटा डालने का प्रयास करेंगे last_nameजो अब अस्तित्व में नहीं है
संस्करण के सभी उदाहरण 2.0.0.BAD बिना किसी समस्या के काम करेंगे

जैसा कि आप देख सकते हैं, यदि हम डेटाबेस और एप्लिकेशन में पीछे की ओर असंगत परिवर्तन करते हैं, तो ए/बी परीक्षण असंभव है।

एप्लिकेशन रोलबैक

आइए मान लें कि ए/बी परिनियोजन करने का प्रयास करने के बाद (लगभग। प्रति.: लेखक का आशय शायद यहां ए/बी परीक्षण से है) हमने निर्णय लिया कि हमें एप्लिकेशन को संस्करण में वापस लाने की आवश्यकता है 1.0.0. मान लीजिए कि हम डेटाबेस को रोलबैक नहीं करना चाहते हैं।

कदम:

हम संस्करण एप्लिकेशन इंस्टेंस को रोकते हैं 2.0.0.BAD
डेटाबेस अभी भी है v2bad
संस्करण के बाद से 1.0.0 समझ में नहीं आता कि यह क्या है surname, हम त्रुटियाँ देखेंगे
नरक टूट गया है, हम अब वापस नहीं जा सकते

जैसा कि आप देख सकते हैं, यदि हम डेटाबेस और एप्लिकेशन में पीछे की ओर असंगत परिवर्तन करते हैं, तो हम पिछले संस्करण में वापस नहीं आ सकते।

स्क्रिप्ट निष्पादन लॉग

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
डीबी संस्करण: v2

टिप्पणी

एक नया कॉलम जोड़कर और उसकी सामग्री की प्रतिलिपि बनाकर, हम पश्चगामी संगत डेटाबेस परिवर्तन बनाते हैं। उसी समय, यदि हम JAR को रोलबैक करते हैं या पुराना JAR चालू रखते हैं, तो यह निष्पादन के दौरान नहीं टूटेगा।

हम एक नया संस्करण ला रहे हैं

कदम:

नया कॉलम बनाने के लिए डेटाबेस माइग्रेशन करें surname. अब आपका DB संस्करण v2
से डेटा कॉपी करें last_name в surname. ध्यान देंयदि आपके पास यह डेटा बहुत अधिक है, तो आपको बैच माइग्रेशन पर विचार करना चाहिए!
वह कोड लिखें जहां उनका उपयोग किया जाता है दोनों и नयाऔर पुराने स्तंभ। अब आपका ऐप संस्करण 2.0.0
कॉलम से मान पढ़ें surname, यदि यह नहीं है null, या एल सेast_name, अगर surname निर्दिष्ट नहीं है। आप हटा सकते हैं getLastName() कोड से, क्योंकि यह आउटपुट होगा null अपना आवेदन वापस लाते समय 3.0.0 से 2.0.0.

यदि आप स्प्रिंग बूट फ्लाईवे का उपयोग कर रहे हैं, तो ये दो चरण संस्करण स्टार्टअप के दौरान निष्पादित किए जाएंगे 2.0.0 अनुप्रयोग। यदि आप डेटाबेस वर्जनिंग टूल को मैन्युअल रूप से चलाते हैं, तो आपको ऐसा करने के लिए दो अलग-अलग काम करने होंगे (पहले डीबी संस्करण को मैन्युअल रूप से अपडेट करें और फिर नया एप्लिकेशन तैनात करें)।

यह महत्वपूर्ण है। याद रखें कि नव निर्मित कॉलम नहीं चाहिए होने के लिए अशक्त नहीं. यदि आप रोलबैक करते हैं, तो पुराने एप्लिकेशन को नए कॉलम के बारे में पता नहीं चलेगा और वह इसे इंस्टॉल नहीं करेगा Insert. लेकिन यदि आप यह बाधा जोड़ते हैं और आपका डीबी होगा v2, इसके लिए नए कॉलम का मान सेट करने की आवश्यकता होगी। जिससे प्रतिबंधों का उल्लंघन होगा.

यह महत्वपूर्ण है। आपको विधि हटा देनी चाहिए getLastName(), क्योंकि संस्करण में 3.0.0 कोड में किसी कॉलम की कोई अवधारणा नहीं है last_name. इसका मतलब है कि वहां null सेट कर दिया जाएगा. आप विधि छोड़ सकते हैं और चेक जोड़ सकते हैं null, लेकिन एक बेहतर समाधान यह सुनिश्चित करना होगा कि तर्क में getSurname() आपने सही गैर-शून्य मान चुना है.

ए/बी परीक्षण

वर्तमान स्थिति यह है कि हमारे पास एक एप्लिकेशन संस्करण है 1.0.0, उत्पादन पर तैनात किया गया है, और डेटाबेस में v1. हमें संस्करण एप्लिकेशन का दूसरा उदाहरण तैनात करने की आवश्यकता है 2.0.0जो डेटाबेस को अपडेट करेगा v2.

कदम:

संस्करण एप्लिकेशन का एक नया उदाहरण तैनात किया गया है 2.0.0जो डेटाबेस को अपडेट करता है v2
इस बीच कुछ अनुरोधों को संस्करण उदाहरणों द्वारा संसाधित किया गया था 1.0.0
अद्यतन सफल रहा और आपके पास संस्करण एप्लिकेशन के कई चल रहे उदाहरण हैं 1.0.0 और अन्य संस्करण 2.0.0. हर कोई डेटाबेस के साथ संचार करता है v2
संस्करण 1.0.0 डेटाबेस में उपनाम कॉलम का उपयोग नहीं करता है, बल्कि संस्करण का उपयोग करता है 2.0.0 उपयोग करता है. वे एक-दूसरे के साथ हस्तक्षेप नहीं करते हैं और कोई त्रुटि नहीं होनी चाहिए।
संस्करण 2.0.0 बैकवर्ड संगतता सुनिश्चित करते हुए, डेटा को पुराने और नए दोनों कॉलम में संग्रहीत करता है

यह महत्वपूर्ण है। यदि आपके पास कोई प्रश्न है जो पुराने/नए कॉलम के मूल्यों के आधार पर वस्तुओं की गणना करता है, तो आपको याद रखना चाहिए कि अब आपके पास डुप्लिकेट मान हैं (संभवतः वे अभी भी माइग्रेट हो रहे हैं)। उदाहरण के लिए, यदि आप उन उपयोगकर्ताओं की संख्या गिनना चाहते हैं जिनका अंतिम नाम (जो भी कॉलम कहा जाता है) अक्षर से शुरू होता है A, तब तक जब तक डेटा माइग्रेशन पूरा नहीं हो जाता (old → new column) यदि आप किसी नए कॉलम पर क्वेरी करते हैं तो आपके पास असंगत डेटा हो सकता है।

एप्लिकेशन रोलबैक

अब हमारे पास ऐप संस्करण है 2.0.0 और डेटाबेस में v2.

कदम:

अपने एप्लिकेशन को संस्करण में वापस रोल करें 1.0.0.
संस्करण 1.0.0 डेटाबेस में किसी कॉलम का उपयोग नहीं करता surname, इसलिए रोलबैक सफल होना चाहिए

डीबी बदलता है

डेटाबेस में नाम का एक कॉलम होता है 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: कोड से अंतिम नाम हटाना

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

डीबी संस्करण:v3

टिप्पणी

टिप्पणी प्रति.: जाहिरा तौर पर, मूल लेख में लेखक ने गलती से इस ब्लॉक के पाठ को चरण 2 से कॉपी कर लिया है। इस चरण में, कॉलम का उपयोग करने वाली कार्यक्षमता को हटाने के उद्देश्य से एप्लिकेशन कोड में परिवर्तन किए जाने चाहिए last_name.

एक नया कॉलम जोड़कर और उसकी सामग्री की प्रतिलिपि बनाकर, हमने पश्चगामी संगत डेटाबेस परिवर्तन बनाए। साथ ही, यदि हम JAR को रोलबैक करते हैं या कोई पुराना JAR चालू रखते हैं, तो यह निष्पादन के दौरान नहीं टूटेगा।

एप्लिकेशन रोलबैक

वर्तमान में हमारे पास ऐप संस्करण है 3.0.0 और डेटाबेस v3. संस्करण 3.0.0 डेटा को सहेजता नहीं है last_name. इसका मतलब यह है कि में surname सबसे अद्यतन जानकारी संग्रहीत की जाती है।

कदम:

अपने एप्लिकेशन को संस्करण में वापस रोल करें 2.0.0.
संस्करण 2.0.0 उपयोग करता है और last_name и surname.
संस्करण 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

डीबी संस्करण: 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"}

डीबी बदलता है

के बारे में 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.0.0 с v1 डेटाबेस स्कीमा (कॉलम नाम = last_name)
एप्लिकेशन संस्करण का परिनियोजन 2.0.0, जो डेटा को स्टोर करता है last_name и surname. एप्लिकेशन से पढ़ता है last_name. डेटाबेस संस्करण में है v2जैसे कॉलम युक्त last_nameऔर surname. surname एल की प्रतिलिपि हैast_name. (नोट: इस कॉलम में शून्य बाधा नहीं होनी चाहिए)
एप्लिकेशन संस्करण का परिनियोजन 3.0.0, जो केवल डेटा संग्रहीत करता है surname और उपनाम से पढ़ता है. जहाँ तक डेटाबेस का सवाल है, अंतिम माइग्रेशन हो रहा है last_name в surname. यह भी एक सीमा है अशक्त नहीं से निकाला गया last_name. डेटाबेस अब संस्करण में है v3
एप्लिकेशन संस्करण का परिनियोजन 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 कंसोल (at) भी शामिल है http://localhost:8080/h2-console) ताकि आप डेटाबेस स्थिति देख सकें (डिफ़ॉल्ट jdbc URL है jdbc:h2:mem:testdb).

इसके अतिरिक्त

हमारे ब्लॉग पर अन्य लेख भी पढ़ें:

स्रोत: www.habr.com

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

परिचय

शून्य डाउनटाइम परिनियोजन

डेटाबेस की समस्याएं

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

डेटाबेस समस्याओं का निवारण

मान्यताओं

डेटाबेस को रोलबैक करने की कोई आवश्यकता नहीं है

चरण 1: प्रारंभिक अवस्था

टिप्पणी

डेटाबेस परिवर्तन

कोड बदलता है

पीछे की ओर असंगत कॉलम का नाम बदलना

टिप्पणी

ए/बी परीक्षण

एप्लिकेशन रोलबैक

स्क्रिप्ट निष्पादन लॉग

डेटाबेस परिवर्तन

कोड बदलता है

किसी कॉलम का नाम पश्च-संगत तरीके से बदलना

चरण 2: उपनाम जोड़ें

टिप्पणी

हम एक नया संस्करण ला रहे हैं

ए/बी परीक्षण

एप्लिकेशन रोलबैक

डीबी बदलता है

कोड बदलता है

चरण 3: कोड से अंतिम नाम हटाना

टिप्पणी

एप्लिकेशन रोलबैक

डेटाबेस परिवर्तन

कोड बदलता है

चरण 4: डेटाबेस से अंतिम_नाम हटाना

टिप्पणी

स्क्रिप्ट निष्पादन लॉग

डीबी बदलता है

कोड बदलता है

उत्पादन

कोड

परियोजनाएं

स्क्रिप्ट

स्प्रिंग बूट नमूना फ्लाईवे

इसके अतिरिक्त

हमारे ब्लॉग पर अन्य लेख भी पढ़ें:

एक टिप्पणी जोड़ें उत्तर रद्द