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

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

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

परिचय

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

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

इसे कैसे प्राप्त किया जाए? कई तरीके हैं, उनमें से एक है:

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

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

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

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

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

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

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

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

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

डेटाबेस माइग्रेट करें।

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

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

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

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

डेटाबेस समस्याएँ

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

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

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

• आप कोड परिवर्तन से अलग डेटाबेस परिवर्तन
• डेटाबेस माइग्रेशन आपके एप्लिकेशन के रोलआउट के साथ होता है, अर्थात आपकी परिनियोजन प्रक्रिया सरल है

डेटाबेस मुद्दों को हल करना

लेख के अगले भाग में, हम डेटाबेस परिवर्तनों के लिए दो दृष्टिकोणों पर विचार करेंगे।

• पिछड़ी असंगति
• पिछड़ी संगतता

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

हमारा प्रोजेक्ट, जिस पर हम काम करेंगे, एक साधारण स्प्रिंग बूट फ्लाईवे एप्लिकेशन होगा जिसमें डेटाबेस में पहले_ irst_name और irst_name एक Person है ( लगभग। Person : एक तालिका है, और f irst_name और irst_name इसमें फ़ील्ड हैं )। हम surname लिए last_name का नाम बदलना चाहते हैं।

मान्यताओं

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

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

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

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

एप्लिकेशन को एक संस्करण वापस रोल करना संभव नहीं है (अधिक नहीं)

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

नोट। अधिक पठनीयता के लिए, इस लेख के ढांचे के भीतर हम आवेदन के प्रमुख संस्करण को बदल देंगे।

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

आवेदन संस्करण: 1.0.0
DB संस्करण: v1

टिप्पणी

यह आवेदन की प्रारंभिक स्थिति होगी।

DB बदल जाता है

डेटाबेस में last_name. शामिल है 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

टिप्पणी

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

ए / बी परीक्षण

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

कदम:

1. एप्लिकेशन संस्करण 2.0.0.BAD का एक नया उदाहरण तैनात किया है, जो डेटाबेस को v2bad अपडेट करता है
2. v2bad कॉलम अब v2bad डेटाबेस में मौजूद नहीं है - इसे surname में बदल दिया गया था
3. डेटाबेस और एप्लिकेशन अपडेट सफल रहे, और कुछ उदाहरणों में 1.0.0 , 2.0.0.BAD में अन्य काम करते हैं। सभी संबंधित v2bad
4. संस्करण 1.0.0 सभी उदाहरण त्रुटियों को फेंकना शुरू कर देंगे क्योंकि वे last_name कॉलम में डेटा डालने की कोशिश करेंगे, जो अब नहीं है
5. संस्करण 2.0.0.BAD सभी उदाहरण समस्याओं के बिना काम करेंगे

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

रोलबैक आवेदन

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

कदम:

1. हम आवेदन उदाहरण संस्करण 2.0.0.BAD
2. डेटाबेस अभी भी v2bad
3. संस्करण 1.0.0 बाद से समझ में नहीं आता है कि surname क्या 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"} 

DB बदल जाता है

माइग्रेशन स्क्रिप्ट जो 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'); 

एक स्क्रिप्ट जो last_name का नाम बदल देती है।

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

कोड परिवर्तन

हमने surname नाम फ़ील्ड नाम बदल दिया है।

स्तंभ का नाम पीछे संगत तरीके से रखना

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

नोट। याद रखें कि हमारे पास एक डेटाबेस संस्करण v1 । इसमें कॉलम first_name और last_name । हमें surname बदलने के लिए last_name बदलना चाहिए। हमारे पास एक एप्लिकेशन संस्करण 1.0.0, भी है जो अभी तक surname उपयोग नहीं करता है।

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

आवेदन संस्करण: 2.0.0
DB संस्करण: v2

टिप्पणी

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

हम नया संस्करण बनाते हैं

कदम:

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

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

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

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

ए / बी परीक्षण

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

कदम:

1. अनुप्रयोग संस्करण 2.0.0 का एक नया उदाहरण तैनात किया है, जो डेटाबेस को v2 अपडेट करता है
2. इस बीच, कुछ अनुरोधों को संस्करण 1.0.0 उदाहरणों द्वारा नियंत्रित किया गया था
3. अपडेट सफल रहा, और आपके पास एप्लिकेशन संस्करण 1.0.0 और शेष संस्करण 2.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: last_name कोड से निकाल रहा है

आवेदन संस्करण: 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

DB बदल जाता है

डेटाबेस में कोई संरचनात्मक परिवर्तन नहीं हैं। निम्न स्क्रिप्ट निष्पादित होती है, जो पुराने डेटा के अंतिम माइग्रेशन को निष्पादित करती है:

 -- 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. दोनों में डेटा संग्रहीत करते हैं 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, परिनियोजित करें 2.0.0, जो last_name और surname में डेटा बचाता है। आवेदन last_name से पढ़ता है। डेटाबेस संस्करण v2 , जिसमें last_name और surname. surname दोनों के कॉलम हैं surname. surname surname. surname l ast_name की एक प्रति है। (: not null)
3. 3.0.0 , surname surname. , last_name surname . NOT NULL 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

Spring Boot Sample Flyway.

http://localhost:8080/flyway , .

H2 ( http://localhost:8080/h2-console ), (URL jdbc — jdbc:h2:mem:testdb ).

इसके साथ ही

• Database Refactoring patterns
• Continuous Delivery

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

• कुबेरनेट्स: सिस्टम संसाधन प्रबंधन स्थापित करना इतना महत्वपूर्ण क्यों है?
• टेक्टन पाइपलाइन - कुबेरनेट्स-देशी पाइपलाइन
• Nginx के लिए गतिशील मॉड्यूल का निर्माण
• हाशिकॉर्प कंसल के कुबेरनेट्स प्राधिकरण का परिचय
• प्राधिकरण के साथ ClickHouse को प्राधिकरण के बिना ClickHouse से माइग्रेशन का परिणाम क्या था
• नगीनेक्स वेब सर्वर के साथ स्प्रिंग एप्लीकेशन की ब्लू-ग्रीन तैनाती