ნულოვანი შეფერხების განლაგება და მონაცემთა ბაზები

ეს სტატია დეტალურად განმარტავს, თუ როგორ უნდა გადაჭრას მონაცემთა ბაზის თავსებადობის საკითხები განლაგებისას. ჩვენ გეტყვით, რა შეიძლება დაემართოს თქვენს საწარმოო აპლიკაციებს, თუ შეეცდებით განათავსოთ წინასწარი მომზადების გარეშე. შემდეგ ჩვენ გავივლით აპლიკაციის სასიცოცხლო ციკლის ეტაპებს, რომლებიც საჭიროა ნულოვანი შეფერხებისთვის (დაახლ. ზოლი: შემდგომი - ნულოვანი შეფერხების დრო). ჩვენი ოპერაციების შედეგი იქნება მონაცემთა ბაზის უკუშეთავსებადი ცვლილების გამოყენება უკუღმა თავსებადი გზით.

თუ გსურთ გაიგოთ კოდის მაგალითები სტატიიდან, შეგიძლიათ იპოვოთ ისინი აქ GitHub.

შესავალი

ნულოვანი შეფერხების განლაგება

რა მისტიკურია ნულოვანი შეფერხების განლაგება? შეიძლება ითქვას, რომ ეს ხდება მაშინ, როდესაც თქვენი აპლიკაცია განლაგებულია ისე, რომ თქვენ წარმატებით შეძლებთ აპლიკაციის ახალი ვერსიის წარმოებაში წარდგენას, ხოლო მომხმარებელი ვერ შეამჩნევს მის მიუწვდომლობას. მომხმარებლისა და კომპანიის პერსპექტივიდან, ეს არის განლაგების საუკეთესო შესაძლო სცენარი, რადგან ის საშუალებას აძლევს ახალი ფუნქციების დანერგვას და შეცდომების გამოსწორებას შეფერხების გარეშე.

როგორ მივაღწიოთ ამას? რამდენიმე გზა არსებობს, აქ არის ერთი მათგანი:

• განათავსეთ თქვენი სერვისის ნომერი 1 ვერსია
• შეასრულეთ მონაცემთა ბაზის მიგრაცია
• განათავსეთ თქვენი სერვისის #2 ვერსია #1 ვერსიის პარალელურად
• როგორც კი დაინახავთ, რომ ვერსია No2 მუშაობს ისე, როგორც უნდა, წაშალეთ ვერსია No1
• მზად არის!

ადვილია, არა? სამწუხაროდ, ეს არც ისე მარტივია და ამას დეტალურად მოგვიანებით განვიხილავთ. ახლა მოდით შევამოწმოთ კიდევ ერთი საკმაოდ გავრცელებული განლაგების პროცესი - ლურჯი მწვანე განლაგება.

გსმენიათ ოდესმე ლურჯი მწვანე განლაგება? Cloud Foundry ამას ძალიან მარტივს ხდის. უბრალოდ შეხედე ამ მუხლის, სადაც ამას უფრო დეტალურად აღვწერთ. მოკლედ რომ შევაჯამოთ, შეგახსენებთ, როგორ გავაკეთოთ ლურჯი მწვანე განლაგება:

• დარწმუნდით, რომ თქვენი წარმოების კოდის ორი ასლი („ლურჯი“ და „მწვანე“) მუშაობს;
• მთელი ტრაფიკი ლურჯ გარემოში, ე.ი. ისე, რომ წარმოების URL-ები მიუთითებს იქ;
• განათავსეთ და შეამოწმეთ აპლიკაციის ყველა ცვლილება მწვანე გარემოში;
• urls-ის შეცვლა ლურჯიდან მწვანე გარემოზე

ლურჯი მწვანე განლაგება არის მიდგომა, რომელიც საშუალებას გაძლევთ მარტივად შემოიტანოთ ახალი ფუნქციები წარმოების დარღვევის შესახებ ფიქრის გარეშე. ეს გამოწვეულია იმით, რომ მაშინაც კი, თუ რამე მოხდება, თქვენ შეგიძლიათ მარტივად გადახვიდეთ წინა გარემოში, უბრალოდ „გადამრთველის დაჭერით“.

ყოველივე ზემოაღნიშნულის წაკითხვის შემდეგ შეიძლება დაგისვათ კითხვა: რა კავშირი აქვს ნულოვანი შეფერხების დრო ლურჯ მწვანე განლაგებას?

კარგად, მათ საკმაოდ ბევრი საერთო აქვთ, რადგან ერთი და იგივე გარემოს ორი ასლის შენარჩუნება მოითხოვს ორმაგ ძალისხმევას მათ შესანარჩუნებლად. ამიტომაც ამტკიცებს ზოგიერთი გუნდი მარტინ ფაულერიმიჰყევით ამ მიდგომის ვარიაციას:

კიდევ ერთი ვარიანტია იგივე მონაცემთა ბაზის გამოყენება, ლურჯ-მწვანე კონცენტრატორების შექმნა ვებსა და დომენის ფენებისთვის. ამ მიდგომით, მონაცემთა ბაზა ხშირად შეიძლება იყოს პრობლემა, განსაკუთრებით მაშინ, როდესაც გჭირდებათ მისი სქემის შეცვლა პროგრამული უზრუნველყოფის ახალი ვერსიის მხარდასაჭერად.

და აქ მივედით მთავარ პრობლემამდე ამ სტატიაში. Მონაცემთა ბაზა. მოდით კიდევ ერთხელ შევხედოთ ამ ფრაზას.

შეასრულეთ მონაცემთა ბაზის მიგრაცია.

ახლა თქვენ უნდა დაუსვათ საკუთარ თავს კითხვა - რა მოხდება, თუ მონაცემთა ბაზის ცვლილება არ არის უკუთავსებადი? არ წყდება აპლიკაციის ჩემი პირველი ვერსია? სინამდვილეში, ეს არის ზუსტად ის, რაც მოხდება ...

ასე რომ, მიუხედავად ნულოვანი შეფერხების / ლურჯი მწვანე განლაგების უზარმაზარი უპირატესობებისა, კომპანიები მიდრეკილნი არიან დაიცვას შემდეგი უსაფრთხო პროცესი მათი აპლიკაციების განსათავსებლად:

• მოამზადეთ პაკეტი აპლიკაციის ახალი ვერსიით
• გაშვებული აპლიკაციის გათიშვა
• გაუშვით სკრიპტები მონაცემთა ბაზის მიგრაციისთვის
• განათავსეთ და გაუშვით აპლიკაციის ახალი ვერსია

ამ სტატიაში ჩვენ დეტალურად განვიხილავთ, თუ როგორ შეგიძლიათ იმუშაოთ თქვენს მონაცემთა ბაზასთან და კოდთან, რომ ისარგებლოთ ნულოვანი შეფერხებით.

მონაცემთა ბაზის საკითხები

თუ თქვენ გაქვთ მოქალაქეობის არმქონე აპლიკაცია, რომელიც არ ინახავს მონაცემებს მონაცემთა ბაზაში, მაშინვე შეგიძლიათ მიიღოთ ნულოვანი შეფერხების დრო. სამწუხაროდ, პროგრამული უზრუნველყოფის უმეტესობას სჭირდება მონაცემების სადმე შენახვა. ამიტომ ორჯერ უნდა დაფიქრდეთ წრეში რაიმე ცვლილების შეტანამდე. სანამ შევისწავლით დეტალებს, თუ როგორ უნდა შეცვალოთ სქემა ისე, რომ შესაძლებელი იყოს შეფერხების გარეშე განლაგება, მოდით პირველ რიგში ყურადღება გავამახვილოთ ვერსიების სქემაზე.

ვერსიების სქემა

ამ სტატიაში ჩვენ გამოვიყენებთ მფრინავი როგორც ვერსიის კონტროლის ინსტრუმენტი (დაახლ. თარგმანი: ჩვენ ვსაუბრობთ მონაცემთა ბაზის მიგრაციაზე). ბუნებრივია, ჩვენ ასევე დავწერთ Spring Boot აპლიკაციას, რომელსაც აქვს ჩაშენებული Flyway მხარდაჭერა და შეასრულებს სქემის მიგრაციას აპლიკაციის კონტექსტის დაყენებისას. 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, თქვენ მიიღებთ 2 დიდ სარგებელს:

• თქვენ განასხვავებთ მონაცემთა ბაზის ცვლილებებს კოდის ცვლილებებისგან
• მონაცემთა ბაზის მიგრაცია ხდება თქვენი აპლიკაციის გაშვებასთან ერთად, ე.ი. თქვენი განლაგების პროცესი გამარტივებულია

მონაცემთა ბაზის პრობლემების მოგვარება

სტატიის შემდეგ ნაწილში ჩვენ ყურადღებას გავამახვილებთ მონაცემთა ბაზის ცვლილებების ორ მიდგომაზე.

• ჩამორჩენილი შეუთავსებლობა
• ჩამორჩენილი თავსებადობა

პირველი განიხილება, როგორც გაფრთხილება, რომ არ უნდა შეასრულოთ ნულოვანი შეფერხება წინასწარი მომზადების გარეშე... მეორე გვთავაზობს გამოსავალს, თუ როგორ შეგიძლიათ განახორციელოთ განლაგება შეფერხების გარეშე და ამავე დროს შეინარჩუნოთ უკან თავსებადობა.

ჩვენი პროექტი, რომელზეც ჩვენ ვიმუშავებთ, იქნება მარტივი Spring Boot Flyway აპლიკაცია, რომელსაც აქვს Person с first_name и last_name მონაცემთა ბაზაში (დაახლ. თარგმანი: Person არის მაგიდა და ვirst_name и last_name - ეს არის ველები მასში). ჩვენ გვინდა გადარქმევა last_name в surname.

ვარაუდები

სანამ დეტალებს შევეხებით, არის რამდენიმე ვარაუდი, რომელიც უნდა გავაკეთოთ ჩვენს აპლიკაციებთან დაკავშირებით. მთავარი შედეგი, რომლის მიღწევაც გვინდა, საკმაოდ მარტივი პროცესი იქნება.

შენიშვნა. ბიზნეს PRO-TIP. პროცესების გამარტივებამ შეიძლება დაზოგოთ ბევრი ფული მხარდაჭერაზე (რაც მეტი ადამიანი გყავთ დასაქმებული თქვენს კომპანიაში, მით მეტი ფულის დაზოგვა შეგიძლიათ)!

არ არის საჭირო მონაცემთა ბაზის უკან დაბრუნება

ეს ამარტივებს განლაგების პროცესს (ზოგიერთი მონაცემთა ბაზის უკან დაბრუნება თითქმის შეუძლებელია, როგორიცაა წაშლის უკან დაბრუნება). ჩვენ ურჩევნიათ მხოლოდ აპლიკაციების უკან დაბრუნება. ამ გზით, მაშინაც კი, თუ თქვენ გაქვთ სხვადასხვა მონაცემთა ბაზა (მაგალითად, 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

წყარო Flyway სკრიპტი:

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 on surname.

სვეტის გადარქმევა უკუღმა თავსებადი გზით

ეს არის ყველაზე გავრცელებული სიტუაცია, რომელიც შეიძლება შეგვხვდეს. ჩვენ უნდა განვახორციელოთ უკუღმა შეუთავსებელი ცვლილებები. ჩვენ უკვე დავამტკიცეთ, რომ ნულოვანი შეფერხების განლაგებისთვის, ჩვენ არ უნდა გამოვიყენოთ მონაცემთა ბაზის მიგრაცია დამატებითი ნაბიჯების გარეშე. სტატიის ამ ნაწილში ჩვენ შევასრულებთ აპლიკაციის 3 განლაგებას მონაცემთა ბაზის მიგრაციებთან ერთად, რათა მივაღწიოთ სასურველ შედეგს და შევინარჩუნოთ უკან თავსებადობა.

შენიშვნა. შეგახსენებთ, რომ ჩვენ გვაქვს ვერსიების მონაცემთა ბაზა v1. ის შეიცავს სვეტებს first_name и last_name. ჩვენ უნდა შევიცვალოთ last_name on 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თუ 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() თქვენ აირჩიეთ სწორი არა-ნულოვანი მნიშვნელობა.

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.

Flyway წყაროს სკრიპტი:

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

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 ასლია ლast_name. (შენიშვნა: ამ სვეტს არ უნდა ჰქონდეს ნულოვანი შეზღუდვა)
3. აპლიკაციის ვერსიის განთავსება 3.0.0, რომელიც მხოლოდ მონაცემებს ინახავს surname და გვარიდან კითხულობს. რაც შეეხება მონაცემთა ბაზას, ბოლო მიგრაცია ხდება last_name в surname. ასევე შეზღუდვა 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

საგაზაფხულო ჩექმის ნიმუში Flyway

ყველა მაგალითი აღებულია Spring Boot Sample Flyway.

შეგიძლიათ გადახედოთ http://localhost:8080/flyway, არის სკრიპტების სია.

ეს მაგალითი ასევე მოიცავს H2 კონსოლს (at http://localhost:8080/h2-console) ასე რომ თქვენ შეგიძლიათ ნახოთ მონაცემთა ბაზის სტატუსი (ნაგულისხმევი jdbc URL არის jdbc:h2:mem:testdb).

გარდა ამისა

• მონაცემთა ბაზის რეფაქტორირების შაბლონები
• უწყვეტი მიწოდების

ასევე წაიკითხეთ სხვა სტატიები ჩვენს ბლოგზე:

• Kubernetes: რატომ არის ასე მნიშვნელოვანი სისტემის რესურსების მართვის კონფიგურაცია?
• Tekton Pipeline - Kubernetes-ის მშობლიური მილსადენები
• დინამიური მოდულების აგება Nginx-ისთვის
• Hashicorp-ის კონსულის Kubernetes ავტორიზაციის შესავალი
• რას მოჰყვა მიგრაცია ClickHouse-დან ავტორიზაციის გარეშე ClickHouse-ში ავტორიზაციის მქონე?
• გაზაფხულის აპლიკაციების ცისფერი-მწვანე განლაგება Nginx ვებ სერვერით

წყარო: www.habr.com