Nulles dīkstāves izvietojums un datu bāzes

Šajā rakstā detalizēti skaidrots, kā risināt problēmas, kas saistītas ar datu bāzu saderību, veicot izvietošanu. Mēs pastāstīsim, kas var notikt ar jūsu ražošanas lietojumprogrammām, ja mēģināsiet veikt izvietošanu bez iepriekšējas sagatavošanas. Pēc tam mēs iziesim cauri lietojumprogrammas dzīves cikla posmiem, kas ir nepieciešami, lai nodrošinātu nulles dīkstāvi (piezīme: turpmāk – nulles dīkstāve). Mūsu darbību rezultāts būs atpakaļsaderīgu datu bāzes izmaiņu piemērošana.

Ja vēlaties iepazīties ar rakstā iekļautajiem kodu piemēriem, jūs tos atradīsiet GitHub.

Ievads

Nulles dīkstāves izvietošana

Kas ir šis noslēpumainais nulles dīkstāves izvietojums? Можно сказать, это когда ваше приложение развернуто так, что вы можете успешно вводить новую версию приложения на продакшн, в то время как пользователь не замечает его недоступности. С точки зрения пользователя и компании, это наилучший из возможных сценариев деплоя, поскольку таким образом можно вводить новые функции и устранять ошибки без перебоев в работе.

Kā to sasniegt? Ir vairāki veidi; šis ir viens no tiem:

• izvietojiet savu pakalpojuma versiju Nr. 1
• veiciet datu bāzes migrāciju
• izvietojiet pakalpojuma versiju Nr. 2 paralēli versijai Nr. 1
• uzreiz, kad redzat, ka versija Nr. 2 darbojas pareizi, noņemiet versiju Nr. 1
• gatavs!

Viegls, vai ne? Diemžēl tas nav tik vienkārši, un mēs vēlāk par to detalizēti diskutēsim. Tagad paskatīsimies uz vēl vienu diezgan izplatītu izvietošanas procesu — zibens zaļo izvietošanu.

Vai esat dzirdējuši par zibens zaļo izvietošanu? С Cloud Foundry это чрезвычайно легко сделать. Просто гляньте на šai rakstam, kur mēs to aprakstām sīkāk. Īsi sakot, atgādināsim, kā veikt zibens zaļo izvietošanu:

• nodrošiniet, lai divas jūsu ražošanas koda kopijas (“zila” un “zaļa”) darbotos;
• virziet visu trafiku uz zilo vidi, t.i., lai ražošanas URL norādītu uz to;
• izvietojiet un pārbaudiet visus lietojumprogrammas izmaiņu zaļajā vidē;
• pārslēdziet URL adreses no zilās uz zaļo vidi

Zibens zaļā izvietošana ir pieeja, kas ļauj jums viegli ieviest jaunas funkcijas, neriskējot, ka ražošanas vide sabojāsies. Tas saistīts ar to, ka pat ja kaut kas notiek, jūs varat viegli atgriezties iepriekšējā vidē, vienkārši „pārslēdzot slēdzi”.

Izlasot iepriekš minēto, jūs varētu uzdot jautājumu: kāda saistība ir nulles dīkstāvei ar zibens zaļo izvietošanu?

Nu, tām ir diezgan daudz kopīga, jo divu vienas un tās pašas vides kopiju uzturēšana prasa dubultus centienus to apkalpošanai. Tādēļ daži komandas, kā apgalvo Martins Fowlers, ievēro šī pieejas variāciju:

Otra iespēja ir izmantot to pašu datu bāzi, izveidojot zilzaļās slēdžus tīmekļa un domēna slāņiem. Šādā pieejā datu bāzes bieži var kļūt par problēmu, īpaši, ja jums ir jāpārveido tās shēma, lai atbalstītu jauno programmatūras versiju.

Un šeit mēs nonākam pie galvenās problēmas šajā rakstā. Datu bāze. Apskatīsim šo frāzi vēlreiz.

veiciet datu bāzes migrāciju.

Tagad jums jāuzdod sev jautājums - kas notiks, ja datu bāzes izmaiņas būs neapmierinošas? Vai mana pirmā lietotnes versija nesabruks? Patiesībā, tieši tas notiks...

Tādējādi, neraugoties uz milzīgajām priekšrocībām, kas saistītas ar zero downtime / blue green deployment, uzņēmumi mēdz ievērot šādu drošāku lietotņu izvietošanas procesu:

• sagatavot pakotni ar jauno lietotnes versiju
• izslēgt palaisto lietotni
• izpildīt skriptus datu bāzes migrācijai
• izvietot un palaist jauno lietotnes versiju

Šajā rakstā mēs detalizēti aprakstīsim, kā jūs varat strādāt ar datu bāzi un kodu, lai gūtu labumu no zero downtime deployment.

Problēmas ar datu bāzi

Ja jums ir stateless lietotne, kas neglabā nekādus datus datu bāzē, jūs varat iegūt zero downtime deployment uzreiz. Diemžēl lielākā daļa programmatūras ir jāuzglabā kaut kur. Tāpēc jums ir divreiz jāpārdomā, pirms veicat jebkādas izmaiņas shēmā. Pirms mēs iegrimsim detaļās par to, kā mainīt shēmu tā, lai būtu iespējams izvietot bez dīkstāves, vispirms koncentrēsimies uz versiju vadības shēmu.

Versiju vadības shēma

Šajā rakstā mēs izmantosim Flyway kā versiju vadības rīku (piezīme: runa ir par datu bāzes migrācijām). Protams, mēs arī uzrakstīsim Spring Boot lietotni, kurai ir iebūvēta Flyway atbalsts un kas veiks shēmas migrāciju lietotnes konteksta iestatīšanas laikā. Izmantojot Flyway, jūs varat saglabāt migrācijas skriptus savus projektu mapēs (pēc noklusējuma classpath:db/migration). Šeit jūs varat redzēt šādu migrācijas failu piemēru

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

Šajā piemērā mēs redzam 4 migrācijas scenārijus, kas, ja tie iepriekš nebija veikti, tiks izpildīti viens pēc otra, palaižot lietojumprogrammu. Apskatīsim vienu no failiem (V1__init.sql) kā piemēru.

IZVEIDOT TABULU PERSON (
id BIGINT GENERATED BY DEFAULT AS IDENTITY,
fist_name varchar(255) not null,
last_name varchar(255) not null
);

ielikt iekšā PERSON (first_name, last_name) vērtības ('Dave', 'Syer');

Viss skaisti runā pats par sevi: jūs varat izmantot SQL, lai noteiktu, kā jūsu datubāze būtu jāmaina. Lai iegūtu papildu informāciju par Spring Boot un Flyway, iepazīstieties ar Spring Boot dokumentāciju.

Izmantojot versiju pārvaldības rīku kopā ar Spring Boot, jūs saņemat 2 lielas priekšrocības:

• jūs atdalāt datubāzes izmaiņas no koda izmaiņām
• datubāzes migrācija notiek vienlaikus ar jūsu lietojumprogrammas laišanu tirgū, tas ir, jūsu izvietošanas process tiek atvieglots

Problēmu risināšana saistībā ar datubāzi

Nākošajā sadaļā mēs koncentrēsimies uz divu pieeju pārskatu saistībā ar datubāzes izmaiņām.

• atpakaļsaderība
• atpakaļsaderības

Pirmais tiks apskatīts kā brīdinājums, ka nevajadzētu veikt bezdarbības izvietojumus bez iepriekšējas sagatavošanās… Otrais piedāvā risinājumu, kā var veikt izvietošanu bez pārtraukumiem un vienlaikus saglabāt atpakaļsaderību.

Mūsu projekts, ar kuru mēs strādāsim, būs vienkārša Spring Boot Flyway lietojumprogramma, kurā ir Person ar first_name un last_name datubāzē (piezīme: Person ir tabula, bet first_name un last_name — tas ir lauks tajā). Mēs vēlamies pārdēvēt last_name par uzvārdu.

Pieņēmumi

Pirms mēs iedziļināmies detaļās, nepieciešams izvirzīt pāris pieņēmumus attiecībā uz mūsu lietojumprogrammām. Galvenais rezultāts, ko mēs vēlamies sasniegt, būs diezgan vienkāršs process.

Piezīme. Business PRO-TIP. Procesu vienkāršošana var ietaupīt jums daudz naudas atbalstam (jo vairāk cilvēku strādā jūsu uzņēmumā, jo vairāk naudas jūs varat ietaupīt)!

Nav nepieciešams veikt datubāzes atgriešanu

Tas atvieglo izvietošanas procesu (dažas datubāzes atgriešanas ir praktiski neiespējamas, piemēram, dzēšanas atgriešana). Mēs dodam priekšroku atgriezt tikai lietojumprogrammas. Tādējādi, pat ja jums ir dažādas datubāzes (piemēram, SQL un NoSQL), jūsu izvietošanas līnija izskatīsies vienādi.

Ir jānodrošina, lai vienmēr būtu iespēja atgriezt lietojumprogrammu par vienu versiju atpakaļ (ne vairāk)

Atgriešana jāveic tikai nepieciešamības gadījumā. Ja pašreizējā versijā ir kļūda, kuru nav viegli novērst, mums jābūt spējīgiem atgriezties pie pēdējās darba versijas. Mēs pieņemam, ka šī pēdējā darba versija ir iepriekšējā. Atbalstīt saderību ar kodu un datu bāzi vairāk nekā vienai izlaidumam būtu ārkārtīgi grūti un dārgi.

Piezīme. Lai uzlabotu lasāmību, šajā rakstā mēs mainīsim lietojumprogrammas galveno versiju.

1. solis: sākotnējais stāvoklis

Lietojumprogrammas versija: 1.0.0
Datu bāzes versija: v1

Komentārs

Tas būs lietojumprogrammas sākotnējais stāvoklis.

Datu bāzes izmaiņas

Datu bāze satur 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');

Koda izmaiņas

Lietojumprogramma saglabā datus Person 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
                + "]";
    }
}

Atpakaļ nesavienojama kolonnas pārdēvēšana

Apskatīsim piemēru, kā mainīt kolonnas nosaukumu:

Uzmanību. Nākamais piemērs apzināti izraisa kļūmi. Mēs to rādām, lai demonstrētu datu bāzes saderības problēmu.

Lietojumprogrammas versija: 2.0.0.BAD

Datu bāzes versija: v2bad

Komentārs

Pašreizējās izmaiņas NEļauj mums palaist divus instancus (veco un jauno) vienlaikus. Tādējādi bezpārtraukta izvietošana būs grūti sasniedzama (ņemot vērā pieņēmumus, tas patiesībā ir neiespējami).

A/B testēšana

Pašreizējā situācija ir tāda, ka mums ir lietojumprogramma versijā 1.0.0, izvietota ražošanas vidē, un datu bāze v1. Mums jāizvieto otrais lietojumprogrammas instants, versijā 2.0.0.BAD, un jāatjaunina datu bāze līdz v2bad.

Soli pa solim:

1. ir izvietots jaunais lietojumprogrammas instants versijā 2.0.0.BAD, kas atjaunina datu bāzi līdz v2bad
2. datu bāzē v2bad kolonna last_name vairs neeksistē — to ir mainījusi uzvārdu
3. datu bāzes un lietojumprogrammas atjauninājums ir veiksmīgi pabeigts, un daži instanci darbojas 1.0.0, citi — 2.0.0.BAD. Visi ir saistīti ar datu bāzi v2bad
4. visi instanci versijā 1.0.0 sāks izsist kļūdas, jo tie centīsies ievietot datus kolonnā last_name, kuru vairs nav
5. visi instanci versijā 2.0.0.BAD darbojas bez problēmām

Kā redzat, ja mēs veicam atpakaļ nesavienojamas datu bāzes un lietojumprogrammas izmaiņas, A/B testēšana nav iespējama.

Lietojumprogrammas atgriešana

Pieņemsim, ka pēc mēģinājuma veikt A/B izvietošanu (piezīme: iespējams, autors šeit domāja A/B testēšanu) mēs nolemjam, ka mums jāpārgatavojas lietojumprogrammai uz versiju 1.0.0. Pieņemsim, ka mēs nevēlamies veikt datu bāzes atgriešanu.

Soli pa solim:

1. mēs apturām programmas instanci versijā 2.0.0.BAD
2. datubāze joprojām v2bad
3. jo versija 1.0.0 neizprot, kas ir uzvārdu, mēs redzēsim kļūdas
4. ellē izlauzās brīvībā, mēs vairs nevaram atgriezties

Kā redzat, ja veicam atpakaļ nesaderīgas izmaiņas BД un programmā, mēs nevaram atgriezties pie iepriekšējās versijas.

Izpildes skriptu žurnāli

Atpakaļ nesaderīgs scenārijs:

01) Izpildiet 1.0.0
02) Gaidiet, līdz programma (1.0.0) ielādējas
03) Radiet personu, zvanot POST localhost:9991/person versijai 1.0.0
04) Izpildiet 2.0.0.BAD
05) Gaidiet, līdz programma (2.0.0.BAD) ielādējas
06) Radiet personu, zvanot POST localhost:9991/person versijai 1.0.0 <-- tam jāneizdodas
07) Radiet personu, zvanot POST localhost:9992/person versijai 2.0.0.BAD <-- tam jāizdodas

Sākot programmu versijā 1.0.0
Radīšana personai versijā 1.0.0
Sūtot pieprasījumu uz 127.0.0.1:9991/person. Tas ir atbildes rezultāts:

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

Sākot programmu versijā 2.0.0.BAD
Radīšana personai versijā 1.0.0
Sūtot pieprasījumu uz 127.0.0.1:9991/person. Tas ir atbildes rezultāts:

curl: (22) Pieprasītā URL atgrieza kļūdu: 500 Iekšējā servera kļūda

Radīšana personai versijā 2.0.0.BAD
Sūtot pieprasījumu uz 127.0.0.1:9995/person. Tas ir atbildes rezultāts:

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

Datu bāzes izmaiņas

Migrācijas skripts, kas pārdēvē last_name par uzvārdu

Oriģinālais Flyway skripts:

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');

Skripts, kas pārdēvē last_name.

-- Šī izmaiņa ir atpakaļ nesaderīga - jums nav iespējams veikt A/B testēšanu
ALTER TABLE PERSON CHANGE last_name surname VARCHAR;

Koda izmaiņas

Mēs mainījām lauka nosaukumu lastName uz uzvārdu.

Kolonnas pārdēvēšana atpakaļ saderīgā veidā

Tā ir visbiežāk sastopamā situācija, ar kuru mēs varam saskarties. Mums jāveic atpakaļ nesaderīgas izmaiņas. Mēs jau esam pierādījuši, ka, lai izvairītos no dīkstāves, mums nav jāpiemēro datubāzes migrācijas bez papildu darbībām. Šajā raksta sadaļā mēs veiksim 3 programmatūras izvietošanas kopā ar datubāzu migrācijām, lai sasniegtu vēlamo rezultātu, saglabājot atpakaļ saderību.

Piezīme. Atgādinām, ka mums ir DБ versija v1. Tā satur kolonnas first_name un last_name. Mums jāmaina last_name uz uzvārdu. Mums arī ir programma versijā 1.0.0, , kas pagaidām neizmanto uzvārdu.

2. solis: Pievienojam surname

Lietojumprogrammas versija: 2.0.0
Datu bāzes versija: v2

Komentārs

Pievienojot jaunu kolonnu un kopējot tās saturu, mēs izveidojam atpakaļ saderīgas DБ izmaiņas. Tajā pašā laikā, ja mēs atgriezīsim JAR vai mums būs strādājošs vecais JAR, tas nepiesprāgs izpildes laikā.

Izlaižam jauno versiju

Soli pa solim:

1. veiciet DБ migrāciju, lai izveidotu jauno kolonnu uzvārdu. Tagad jūsu DБ versija v2
2. nokopējiet datus no last_name par uzvārdu. Lūdzu, ņemiet vērā,, ja jums ir daudz šo datu, jums jāpārdomā partiju migrācija!
3. uzrakstiet kodu, kur tiek izmantots ABI un jauns, un vecais kolonna. Tagad jūsu lietojumprogrammas versija 2.0.0
4. izlasiet vērtību no kolonnas uzvārdu, ja tā nav null, vai no last_name, ja uzvārdu nav norādīts. Jūs varat dzēst getLastName() no koda, jo tas atgriezīs null atgriežot jūsu lietojumprogrammu ar 3.0.0 līdz 2.0.0.

Ja jūs izmantojat Spring Boot Flyway, šie divi soļi tiks izpildīti versijas sākumā 2.0.0 lietojumprogrammas. Ja jūs manuāli palaižat datu bāzes versiju vadības rīku, jums būs jāveic divi atsevišķi soļi (vispirms manuāli atjauniniet db versiju un pēc tam izvietojiet jaunu lietojumprogrammu).

Svarīgi. Atcerieties, ka jaunizveidotajai kolonnai NEDRĪKST būt NOT NULL. Ja jūs veicat atgriešanos, vecā lietojumprogramma nezinās par jauno kolonnu un neiestatīs to laikā Insert. Bet, ja jūs pievienosiet šo ierobežojumu, un jūsu DB būs v2, tas prasīs jauno kolonnas vērtību iestatīšanu. Tas radīs ierobežojumu pārkāpumus.

Svarīgi. Jums vajadzētu izdzēst metodi getLastName(), jo versijā 3.0.0 koda konceptā nav kolonnas last_name. Tas nozīmē, ka tur tiks iestatīti null. Jūs varat saglabāt metodi un pievienot pārbaudes uz null, bet daudz labāks risinājums būtu pārliecināties, ka loģikā getSurname() jūs esat izvēlējušies pareizo nenobīdošo vērtību.

A/B testēšana

Pašreizējā situācija ir tāda, ka mums ir lietojumprogramma versijā 1.0.0, izvietota uz produkcijas, un DB ir v1. Mums jāizvieto otra versijas lietojumprogrammas instance 2.0.0, kas atjaunos datu bāzi līdz v2.

Soli pa solim:

1. ir izvietots jaunais lietojumprogrammas instants versijā 2.0.0, kas atjaunina datu bāzi līdz v2
2. tajā pašā laikā daži pieprasījumi tika apstrādāti ar versijas instancēm 1.0.0
3. atjaunināšana noritēja veiksmīgi, un jums ir vairākas darbīgas versijas lietojumprogrammas instancēs 1.0.0 un pārējās versijas 2.0.0. Visi sazinās ar DB, kas v2
4. versija 1.0.0 neizmanto datu bāzē kolonnas surname, bet versija 2.0.0 izmanto. Viņi netraucē viens otram, un kļūdām nevajadzētu būt.
5. versija 2.0.0 saglabā datus gan vecajā, gan jaunajā kolonnā, kas nodrošina atpakaļsavienojamību.

Svarīgi. Ja jums ir kādi pieprasījumi, kas skaita elementus, pamatojoties uz vērtībām no vecās / jaunās kolonnas, jums jāatceras, ka tagad jums ir duplikāti vērtībās (droši vien tie joprojām migrē). Piemēram, ja vēlaties saskaitīt lietotājus, kuru uzvārds (kā to sauc) sākas ar burtu A, tad līdz datu migrācijas pabeigšanai (vecā → jauns kolonna) jums var būt nekonsistenti dati, ja jūs pieprasāt no jaunās kolonnas.

Lietojumprogrammas atgriešana

Tagad mums ir versijas lietojumprogrammas 2.0.0 un datu bāze ir v2.

Soli pa solim:

1. atgrieziet savu lietojumprogrammu uz versiju 1.0.0.
2. versija 1.0.0 neizmanto datu bāzē kolonnu uzvārdu, tāpēc atjaunošanai jābūt veiksmīgai

Izmaiņas DB

DB satur kolonnu ar nosaukumu last_name.

Oriģinālais Flyway skripts:

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');

Pievienojuma skripts uzvārdu.

Uzmanību. Atcerieties, ka NAV JĀPIEVIENO nekādi ierobežojumi NOT NULL pie pievienotās kolonnas. Ja jūs atsaucat JAR, vecā versija nezina par pievienoto kolonnu un automātiski piešķirs tam NULL vērtību. Ja šāds ierobežojums ir, vecā lietotne vienkārši sabruks.

-- PIEZĪME: Šai laukam nevar būt NOT NULL ierobežojums, jo, ja jūs atgriezīsities, vecā versija nezina par šo lauku
-- un vienmēr piešķirs tam NULL
ALTER TABLE PERSON ADD surname varchar(255);

-- PIEVĒRSĪSIMIES, KA TĀ IR ĀTRA MIGRĀCIJA - CITĀGAD MUMS BŪTU JĀMIGRĒ PA ŠAJĀS DAĻĀS
UPDATE PERSON SET PERSON.surname = PERSON.last_name

Koda izmaiņas

Mēs saglabājam datus kā last_name, tā arī uzvārdu. Tajā pašā laikā lasam no last_name, jo šī kolonna ir visaktuālāka. Izvietošanas procesā daži pieprasījumi varēja tikt apstrādāti ar lietotnes instance, kas vēl nebija atjaunināta.

/*
 * 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. solis: no koda noņemt last_name

Lietojumprogrammas versija: 3.0.0

Datu bāzes versija:v3

Komentārs

Piezīme: Acīmredzot oriģinālajā rakstā autors kļūdaini kopējis šī bloka tekstu no 2. soļa. Šajā solī jāveic izmaiņas lietotnes kodā, kas vērstas uz funkcionalitātes noņemšanu, kas izmanto kolonnu last_name.

Pievienojot jaunu kolonnu un kopējot tās saturu, mēs radījām uz leju saderīgas izmaiņas DB. Turklāt, ja mēs atsaucam JAR vai mums ir strādājošs vecais JAR, tas nesabruks izpildes laikā.

Lietojumprogrammas atgriešana

Šobrīd mums ir lietotne versijā 3.0.0 un datubāze v3. Versija 3.0.0 neglabā datus last_name. Tas nozīmē, ka uzvārdu satur visjaunāko informāciju.

Soli pa solim:

1. atgrieziet savu lietojumprogrammu uz versiju 2.0.0.
2. versija 2.0.0 izmanto un last_name un uzvārdu.
3. versija 2.0.0 paņems uzvārdu, ja tas nav nulles, citādi —last_name

Datu bāzes izmaiņas

Datubāzē nav struktūras izmaiņu. Tiek izpildīts nākamais skripts, kas veic veco datu galīgo migrāciju:

-- PIEVĒRSĪSIMIES, KA TĀ IR ĀTRA MIGRĀCIJA - CITĀGAD MUMS BŪTU JĀMIGRĒ PA ŠAJĀS DAĻĀS
-- ARĪ MĒS NEKONTROLĒJAM, JA MĒS NEPĀRRAUDAMIES VECOS IERAKSTUS. MUMS BŪTU JĀSALĪDZINA
-- IERAKSTU VERSIJAS, LAI PĀRLIECINĀTU, KA, JA JAU IR IERAKSTS AR AUGSTĀKU VERSIJAS NUMURU
-- MĒS NEPĀRRAUDAMIES TO.
UPDATE PERSON SET PERSON.surname = PERSON.last_name;

-- NOŅEMOT NOT NULL IEROBEŽOJUMU; CITĀGAD TIEM MĒS MĒĶAM IEVADĀT NULL VĒRTĪBU LAST_NAME
-- AR NOT NULL IEROBEŽOJUMU.
ALTER TABLE PERSON MODIFY COLUMN last_name varchar(255) NULL DEFAULT NULL;

Koda izmaiņas

Piezīme: Šī bloka apraksts arī tika kļūdaini kopēts autoram no 2. soļa. Saskaņā ar raksta loģiku, izmaiņas kodā šajā solī jābūt vērstām uz elementu noņemšanu, kas strādā ar kolonnu last_name.

Mēs glabājam datus kā last_name, tā arī surname. Turklāt mēs lasām no kolonnas last_name, jo tā ir visatbilstošākā. Izvietošanas procesā daži pieprasījumi var tikt apstrādāti ar instanci, kas vēl nav atjaunināta.

/*
 * 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. solis: Dzēst last_name no DB

Lietojumprogrammas versija: 4.0.0

Datu bāzes versija: v4

Komentārs

Tā kā versijas kods 3.0.0 neizmantot kolonu last_name, izpildes laikā nekas slikts nenotiks, ja mēs atkāpsimies līdz 3.0.0 pēc kolonnas dzēšanas no datubāzes.

Izpildes skriptu žurnāli

Mēs to darīsim šādā veidā:

01) Palaižam 1.0.0
02) Gaidām, kad lietotne (1.0.0) ieslēgsies
03) Ģenerējam personu, izsaucot POST localhost:9991/person uz versiju 1.0.0
04) Palaižam 2.0.0
05) Gaidām, kad lietotne (2.0.0) ieslēgsies
06) Ģenerējam personu, izsaucot POST localhost:9991/person uz versiju 1.0.0
07) Ģenerējam personu, izsaucot POST localhost:9992/person uz versiju 2.0.0
08) Nogalinām lietotni (1.0.0)
09) Palaižam 3.0.0
10) Gaidām, kad lietotne (3.0.0) ieslēgsies
11) Ģenerējam personu, izsaucot POST localhost:9992/person uz versiju 2.0.0
12) Ģenerējam personu, izsaucot POST localhost:9993/person uz versiju 3.0.0
13) Nogalinām lietotni (3.0.0)
14) Palaižam 4.0.0
15) Gaidām, kad lietotne (4.0.0) ieslēgsies
16) Ģenerējam personu, izsaucot POST localhost:9993/person uz versiju 3.0.0
17) Ģenerējam personu, izsaucot POST localhost:9994/person uz versiju 4.0.0

Sākam lietotni versijā 1.0.0
Ģenerējam personu versijā 1.0.0
Sūtot post uz 127.0.0.1:9991/person. Šī ir atbilde:

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

Sākam lietotni versijā 2.0.0

Ģenerējam personu versijā 1.0.0
Sūtot post uz 127.0.0.1:9991/person. Šī ir atbilde:

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

Ģenerējam personu versijā 2.0.0
Sūtot post uz 127.0.0.1:9992/person. Šī ir atbilde:

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

Nogalinām lietotni 1.0.0

Sākam lietotni versijā 3.0.0

Ģenerējam personu versijā 2.0.0
Sūtot post uz 127.0.0.1:9992/person. Šī ir atbilde:
{"firstName":"74d84a9e-5f44-43b8-907c-148c6d26a71b","lastName":"74d84a9e-5f44-43b8-907c-148c6d26a71b","surname":"74d84a9e-5f44-43b8-907c-148c6d26a71b"}

Ģenerējam personu versijā 3.0.0
Sūtot post uz 127.0.0.1:9993/person. Šī ir atbilde:
{"firstName":"c6564dbe-9ab5-40ae-9077-8ae6668d5862","surname":"c6564dbe-9ab5-40ae-9077-8ae6668d5862"}

Nogalinām lietotni 2.0.0

Sākam lietotni versijā 4.0.0

Ģenerējam personu versijā 3.0.0
Sūtot post uz 127.0.0.1:9993/person. Šī ir atbilde:

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

Ģenerējam personu versijā 4.0.0
Sūtot post uz 127.0.0.1:9994/person. Šī ir atbilde:

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

Izmaiņas DB

Attiecībā uz v3 mēs vienkārši dzēšam kolonnu last_name un pievienojam trūkstošos ierobežojumus.

-- DZEST KOLONU
ALTER TABLE PERSON DROP last_name;

-- PIEVIENOT IEROBEŽOJUMUS
UPDATE PERSON SET surname='' WHERE surname IS NULL;
ALTER TABLE PERSON ALTER COLUMN surname VARCHAR NOT NULL;

Koda izmaiņas

Izmaiņas kodā nav.

Izvade

Mēs veiksmīgi pielāgojām atpakaļ nesaderīgu kolonnas nosaukuma izmaiņu, veicot vairākus atpakaļ saderīgus izvietojumus. Zemāk ir veikto darbību kopsavilkums:

1. izvietojums lietotnes versija 1.0.0 ar v1 DB shēma (kolonnas nosaukums = last_name)
2. izvietojums lietotnes versija 2.0.0, kas saglabā datus last_name un uzvārdu. Lietotne lasa no last_name. DB atrodas versijā v2, kas satur kolonnas kā last_name, gan uzvārds. uzvārds ir kopija last_name. (Piezīme: šim laukam nedrīkst būt ierobežojums not null)
3. izvietojums lietotnes versija 3.0.0, kas saglabā datus tikai uzvārdu un lasa no uzvārda. Attiecībā uz DB notiek pēdējā migrācija last_name par uzvārdu. Arī ierobežojums NOT NULL tiek noņemts no last_name. DB pašlaik ir versijā v3
4. izvietojums lietotnes versija 4.0.0 — kodā netiek izdarītas nekādas izmaiņas. Datubāzes izvietošana v4, kas dzēš last_name. Šeit jūs varat pievienot jebkādus trūkstošos ierobežojumus DB.

Izmantojot šo pieeju, jūs vienmēr varat atgriezties uz vienu versiju atpakaļ, nesabojājot datu bāzes / lietotnes saderību.

Kods

Visi kods, kas izmantots šajā rakstā, ir pieejams Github. Zemāk ir papildu apraksts.

Projektu

Pēc repozitorija klonēšanas jūs redzēsiet sekojošo mapju struktūru.

├── boot-flyway-v1              - 1.0.0 versija lietotnei ar v1 shēmu
├── boot-flyway-v2              - 2.0.0 versija lietotnei ar v2 shēmu (atpakaļsaderīga - lietotni var atgriezt)
├── boot-flyway-v2-bad          - 2.0.0.BAD versija lietotnei ar v2bad shēmu (neatpakaļsaderīga - lietotni nevar atgriezt)
├── boot-flyway-v3              - 3.0.0 versija lietotnei ar v3 shēmu (lietotni var atgriezt)
└── boot-flyway-v4              - 4.0.0 versija lietotnei ar v4 shēmu (lietotni var atgriezt)

Skripti

Jūs varat palaist scenārijus, kas aprakstīti zemāk esošajos skriptos, kas demonstrējot atpakaļ saderīgas un nesaderīgas izmaiņas DB.

Lai redzētu gadījumu ar atpakaļ saderīgām izmaiņām, palaižiet:

.\/scripts\/scenario_backward_compatible.sh

Un lai redzētu gadījumu ar atpakaļ nesaderīgām izmaiņām, palaižiet:

.\/scripts\/scenario_backward_incompatible.sh

Spring Boot Sample Flyway

Visi piemēri ņemti no Spring Boot Sample Flyway.

Jūs varat aplūkot http://localhost:8080/flyway, tur ir skriptu saraksts.

Šis piemērs arī iekļauj H2 konsoli (adresē http://localhost:8080/h2-console), lai jūs varētu apskatīt datu bāzes stāvokli (noklusējuma jdbc URL — jdbc:h2:mem:testdb).

Papildus

• Datu bāzes rekonstrukcijas paraugi
• Nepārtrauktu piegādi

Izlasiet arī citus rakstus mūsu emuārā:

• Kubernetes: kāpēc ir svarīgi iestatīt resursu pārvaldību sistēmā?
• Tekton Pipeline — Kubernetes-native pipelines
• Dinamisko moduļu veidošana Nginx
• Ievads Hashicorp Consul Kubernetes autorizācijā
• Kā notika migrācija no ClickHouse bez autorizācijas uz ClickHouse ar autorizāciju
• Blue-Green lietojumu izvietojumi uz Spring ar Nginx tīmekļa serveri

Avots: habr.com