ການນຳໃຊ້ສູນການຢຸດເຮັດວຽກ ແລະຖານຂໍ້ມູນ

ບົດ​ຄວາມ​ນີ້​ອະ​ທິ​ບາຍ​ໃນ​ລະ​ອຽດ​ວິ​ທີ​ແກ້​ໄຂ​ບັນ​ຫາ​ຄວາມ​ເຂົ້າ​ກັນ​ໄດ້​ຂອງ​ຖານ​ຂໍ້​ມູນ​ໃນ​ການ​ນໍາ​ໃຊ້​. ພວກເຮົາຈະບອກທ່ານວ່າສິ່ງທີ່ສາມາດເກີດຂຶ້ນກັບຄໍາຮ້ອງສະຫມັກການຜະລິດຂອງທ່ານຖ້າຫາກວ່າທ່ານພະຍາຍາມທີ່ຈະນໍາໃຊ້ໂດຍບໍ່ມີການກະກຽມເບື້ອງຕົ້ນ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາຈະຜ່ານຂັ້ນຕອນວົງຈອນຊີວິດຂອງແອັບພລິເຄຊັນທີ່ຕ້ອງບໍ່ມີເວລາຢຸດເຮັດວຽກ (ປະມານ lane: ເພີ່ມເຕີມ - ບໍ່ມີເວລາຢຸດ). ຜົນໄດ້ຮັບຂອງການດໍາເນີນງານຂອງພວກເຮົາແມ່ນຈະນໍາໃຊ້ການປ່ຽນແປງຖານຂໍ້ມູນທີ່ບໍ່ເຂົ້າກັນໄດ້ໃນແບບທີ່ເຂົ້າກັນໄດ້ກັບຫຼັງ.

ຖ້າທ່ານຕ້ອງການເຂົ້າໃຈຕົວຢ່າງລະຫັດຈາກບົດຄວາມ, ທ່ານສາມາດຊອກຫາພວກເຂົາໄດ້ທີ່ GitHub.

ການນໍາສະເຫນີ

ການນຳໃຊ້ສູນການຢຸດເຮັດວຽກ

ອັນໃດເປັນຄວາມລຶກລັບ ການນຳໃຊ້ສູນການຢຸດເຮັດວຽກ? ທ່ານສາມາດເວົ້າໄດ້ວ່ານີ້ແມ່ນເວລາທີ່ແອັບພລິເຄຊັນຂອງທ່ານຖືກນໍາໄປໃຊ້ໃນລັກສະນະທີ່ເຈົ້າສາມາດແນະນໍາເວີຊັນໃຫມ່ຂອງແອັບພລິເຄຊັນໃນການຜະລິດໄດ້ຢ່າງສໍາເລັດຜົນ, ໃນຂະນະທີ່ຜູ້ໃຊ້ບໍ່ໄດ້ສັງເກດເຫັນຄວາມບໍ່ມີຂອງມັນ. ຈາກທັດສະນະຂອງຜູ້ໃຊ້ແລະບໍລິສັດ, ນີ້ແມ່ນສະຖານະການການນໍາໃຊ້ທີ່ດີທີ່ສຸດທີ່ເປັນໄປໄດ້ເພາະວ່າມັນອະນຸຍາດໃຫ້ຄຸນນະສົມບັດໃຫມ່ໄດ້ຮັບການນໍາສະເຫນີແລະຂໍ້ບົກພ່ອງທີ່ຈະແກ້ໄຂໂດຍບໍ່ມີການລົບກວນ.

ວິທີການບັນລຸນີ້? ມີຫຼາຍວິທີ, ນີ້ແມ່ນ ໜຶ່ງ ໃນນັ້ນ:

• ນຳໃຊ້ສະບັບເລກທີ 1 ຂອງການບໍລິການຂອງທ່ານ
• ປະຕິບັດການເຄື່ອນຍ້າຍຖານຂໍ້ມູນ
• ນຳໃຊ້ເວີຊັ່ນ #2 ຂອງການບໍລິການຂອງເຈົ້າຂະໜານກັບເວີຊັນ #1
• ທັນທີທີ່ທ່ານເຫັນວ່າສະບັບເລກທີ 2 ເຮັດວຽກຕາມທີ່ມັນຄວນຈະເປັນ, ເອົາສະບັບເລກທີ 1
• ສຳ ເລັດແລ້ວ!

ງ່າຍ, ບໍ່ແມ່ນບໍ? ແຕ່ຫນ້າເສຍດາຍ, ມັນບໍ່ແມ່ນເລື່ອງງ່າຍດາຍ, ແລະພວກເຮົາຈະເບິ່ງລາຍລະອຽດໃນພາຍຫຼັງ. ຕອນນີ້ໃຫ້ກວດເບິ່ງຂະບວນການນຳໃຊ້ທົ່ວໄປອີກອັນໜຶ່ງ - blue green deployment .

ເຈົ້າເຄີຍໄດ້ຍິນ ການ​ນໍາ​ໃຊ້​ສີ​ຟ້າ​ສີ​ຂຽວ​? Cloud Foundry ເຮັດໃຫ້ມັນງ່າຍທີ່ສຸດ. ພຽງແຕ່ເບິ່ງ ຫົວ​ຂໍ້​ນີ້, ບ່ອນທີ່ພວກເຮົາອະທິບາຍນີ້ໃນລາຍລະອຽດເພີ່ມເຕີມ. ເພື່ອສະຫຼຸບໂດຍຫຍໍ້, ໃຫ້ພວກເຮົາເຕືອນທ່ານກ່ຽວກັບວິທີການນໍາໃຊ້ສີຂຽວສີຟ້າ:

• ໃຫ້ແນ່ໃຈວ່າສອງສໍາເນົາຂອງລະຫັດການຜະລິດຂອງທ່ານ ("ສີຟ້າ" ແລະ "ສີຂຽວ") ເຮັດວຽກ;
• ຊີ້ນໍາການຈະລາຈອນທັງຫມົດໄປສູ່ສະພາບແວດລ້ອມສີຟ້າ, i.e. ດັ່ງນັ້ນ URLs ການຜະລິດຊີ້ໃຫ້ເຫັນ;
• ນຳໃຊ້ ແລະທົດສອບການປ່ຽນແປງແອັບພລິເຄຊັນທັງໝົດໃນສະພາບແວດລ້ອມສີຂຽວ;
• ປ່ຽນ urls ຈາກສີຟ້າເປັນສີຂຽວສະພາບແວດລ້ອມ

ການນຳໃຊ້ສີຂຽວສີຟ້າເປັນວິທີການທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດແນະນຳຄຸນສົມບັດໃໝ່ໄດ້ຢ່າງງ່າຍດາຍໂດຍບໍ່ຕ້ອງກັງວົນກ່ຽວກັບການແຕກແຍກຂອງການຜະລິດ. ນີ້ແມ່ນເນື່ອງມາຈາກຄວາມຈິງທີ່ວ່າເຖິງແມ່ນວ່າບາງສິ່ງບາງຢ່າງເກີດຂຶ້ນ, ທ່ານສາມາດກັບຄືນສູ່ສະພາບແວດລ້ອມທີ່ຜ່ານມາໄດ້ຢ່າງງ່າຍດາຍໂດຍພຽງແຕ່ "flicking ສະຫຼັບ."

ຫຼັງຈາກອ່ານທັງຫມົດຂ້າງເທິງ, ເຈົ້າອາດຈະຖາມຄໍາຖາມ: ການເຮັດວຽກທີ່ບໍ່ມີການຢຸດເຮັດວຽກກັບ Blue Green ແມ່ນຫຍັງ?

ດີ, ພວກມັນມີຄວາມຄ້າຍຄືກັນຫຼາຍ, ເພາະວ່າການຮັກສາສອງສໍາເນົາຂອງສະພາບແວດລ້ອມດຽວກັນຮຽກຮ້ອງໃຫ້ມີຄວາມພະຍາຍາມສອງເທົ່າເພື່ອຮັກສາພວກມັນ. ນີ້ແມ່ນເຫດຜົນທີ່ທີມງານບາງຄົນອ້າງ Martin Fowler, ປະຕິບັດຕາມການປ່ຽນແປງຂອງວິທີການນີ້:

ທາງເລືອກອື່ນແມ່ນການນໍາໃຊ້ຖານຂໍ້ມູນດຽວກັນ, ການສ້າງສະຫຼັບສີຟ້າສີຂຽວສໍາລັບຊັ້ນເວັບແລະໂດເມນ. ໃນວິທີການນີ້, ຖານຂໍ້ມູນມັກຈະເປັນບັນຫາ, ໂດຍສະເພາະໃນເວລາທີ່ທ່ານຕ້ອງການປ່ຽນແປງ schema ຂອງຕົນເພື່ອສະຫນັບສະຫນູນສະບັບໃຫມ່ຂອງຊອບແວ.

ແລະໃນທີ່ນີ້ພວກເຮົາມາຮອດບັນຫາຕົ້ນຕໍໃນບົດຄວາມນີ້. ຖານຂໍ້ມູນ. ລອງພິຈາລະນາເບິ່ງປະໂຫຍກນີ້ອີກ.

ປະຕິບັດການເຄື່ອນຍ້າຍຖານຂໍ້ມູນ.

ຕອນນີ້ເຈົ້າຕ້ອງຖາມຕົວເອງວ່າ - ຈະເຮັດແນວໃດຖ້າການປ່ຽນແປງຖານຂໍ້ມູນບໍ່ເຂົ້າກັນໄດ້ກັບຫລັງ? ແອັບເວີຊັ່ນທຳອິດຂອງຂ້ອຍຈະບໍ່ຢຸດບໍ? ໃນຄວາມເປັນຈິງ, ນີ້ແມ່ນສິ່ງທີ່ຈະເກີດຂຶ້ນ ...

ດັ່ງນັ້ນ, ເຖິງແມ່ນວ່າຈະມີຜົນປະໂຫຍດອັນໃຫຍ່ຫຼວງຂອງການໃຊ້ສູນການຢຸດເຮັດວຽກ / ສີຂຽວສີຟ້າ, ບໍລິສັດມີແນວໂນ້ມທີ່ຈະປະຕິບັດຕາມຂະບວນການທີ່ປອດໄພກວ່າຕໍ່ໄປນີ້ເພື່ອນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກຂອງພວກເຂົາ:

• ກະກຽມຊຸດທີ່ມີຄໍາຮ້ອງສະຫມັກສະບັບໃຫມ່
• ປິດແອັບພລິເຄຊັນທີ່ເຮັດວຽກຢູ່
• ແລ່ນສະຄຣິບເພື່ອຍ້າຍຖານຂໍ້ມູນ
• ນຳໃຊ້ ແລະເປີດແອັບພລິເຄຊັນເວີຊັນໃໝ່

ໃນບົດຄວາມນີ້, ພວກເຮົາຈະອະທິບາຍວິທີທີ່ທ່ານສາມາດເຮັດວຽກກັບຖານຂໍ້ມູນ ແລະລະຫັດຂອງທ່ານເພື່ອໃຊ້ປະໂຫຍດຈາກການນຳໃຊ້ສູນການຢຸດເຮັດວຽກ.

ບັນຫາຖານຂໍ້ມູນ

ຖ້າທ່ານມີແອັບພລິເຄຊັນທີ່ບໍ່ມີລັດທີ່ບໍ່ເກັບຮັກສາຂໍ້ມູນໃດໆໃນຖານຂໍ້ມູນ, ທ່ານສາມາດໄດ້ຮັບການນໍາໃຊ້ສູນການຢຸດເຮັດວຽກທັນທີ. ແຕ່ຫນ້າເສຍດາຍ, ຊອບແວສ່ວນໃຫຍ່ຕ້ອງການເກັບຮັກສາຂໍ້ມູນຢູ່ບ່ອນໃດຫນຶ່ງ. ນີ້ແມ່ນເຫດຜົນທີ່ທ່ານຄວນຄິດສອງຄັ້ງກ່ອນທີ່ຈະເຮັດການປ່ຽນແປງໃດໆຕໍ່ວົງຈອນ. ກ່ອນທີ່ພວກເຮົາຈະເຂົ້າໄປໃນລາຍລະອຽດຂອງວິທີການປ່ຽນ schema ເພື່ອບໍ່ໃຫ້ມີການຢຸດເວລາເຮັດວຽກ, ທໍາອິດໃຫ້ພວກເຮົາເອົາໃຈໃສ່ກັບ schema ສະບັບ.

ໂຄງ​ການ​ສະ​ບັບ​

ໃນບົດຄວາມນີ້ພວກເຮົາຈະໃຊ້ ເສັ້ນທາງບິນ ເປັນ​ເຄື່ອງ​ມື​ການ​ຄວບ​ຄຸມ​ສະ​ບັບ (ປະມານ ການແປ: ພວກເຮົາເວົ້າກ່ຽວກັບການເຄື່ອນຍ້າຍຖານຂໍ້ມູນ). ຕາມທໍາມະຊາດ, ພວກເຮົາຍັງຈະຂຽນຄໍາຮ້ອງສະຫມັກ Spring Boot ທີ່ສະຫນັບສະຫນູນ Flyway ໃນຕົວແລະຈະປະຕິບັດການເຄື່ອນຍ້າຍ schema ໃນຂະນະທີ່ກໍານົດສະພາບການຄໍາຮ້ອງສະຫມັກ. ເມື່ອໃຊ້ 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 Docs.

ໂດຍການນໍາໃຊ້ເຄື່ອງມືຄວບຄຸມແຫຼ່ງກັບ Spring Boot, ທ່ານໄດ້ຮັບຜົນປະໂຫຍດອັນໃຫຍ່ຫຼວງ 2:

• ທ່ານແຍກການປ່ຽນແປງຖານຂໍ້ມູນຈາກການປ່ຽນແປງລະຫັດ
• ການ​ເຄື່ອນ​ຍ້າຍ​ຖານ​ຂໍ້​ມູນ​ເກີດ​ຂຶ້ນ​ພ້ອມ​ກັບ​ການ​ເປີດ​ຕົວ​ຂອງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ຂອງ​ທ່ານ​, i.e. ຂະ​ບວນ​ການ​ນໍາ​ໃຊ້​ຂອງ​ທ່ານ​ແມ່ນ​ງ່າຍ​ດາຍ​

ແກ້ໄຂບັນຫາຖານຂໍ້ມູນ

ໃນພາກຕໍ່ໄປຂອງບົດຄວາມ, ພວກເຮົາຈະສຸມໃສ່ການເບິ່ງສອງວິທີການໃນການປ່ຽນແປງຖານຂໍ້ມູນ.

• ຄວາມບໍ່ເຂົ້າກັນໄດ້ກັບຫຼັງ
• ຄວາມເຂົ້າກັນໄດ້ກັບຫຼັງ

ອັນທໍາອິດຈະຖືກພິຈາລະນາເປັນຄໍາເຕືອນວ່າທ່ານບໍ່ຄວນປະຕິບັດການວາງເວລາ downtime ໂດຍບໍ່ມີການກະກຽມເບື້ອງຕົ້ນ ... ອັນທີສອງສະເຫນີວິທີແກ້ໄຂກ່ຽວກັບວິທີທີ່ທ່ານສາມາດດໍາເນີນການ deployment ໂດຍບໍ່ມີການ downtime ແລະໃນເວລາດຽວກັນຮັກສາຄວາມເຂົ້າກັນໄດ້ກັບຄືນໄປບ່ອນ.

ໂຄງການຂອງພວກເຮົາທີ່ພວກເຮົາຈະເຮັດວຽກຈະເປັນຄໍາຮ້ອງສະຫມັກ Spring Boot Flyway ງ່າຍດາຍທີ່ມີ Person с first_name и last_name ໃນ​ຖານ​ຂໍ້​ມູນ (ປະມານ ການແປ: Person ແມ່ນຕາຕະລາງແລະ first_name и last_name - ເຫຼົ່ານີ້ແມ່ນທົ່ງນາໃນມັນ). ພວກເຮົາຕ້ອງການປ່ຽນຊື່ last_name в surname.

ສົມມຸດຕິຖານ

ກ່ອນທີ່ພວກເຮົາຈະເຂົ້າໄປໃນລາຍລະອຽດ, ມີສອງສົມມຸດຕິຖານທີ່ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ເຮັດກ່ຽວກັບຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາ. ຜົນໄດ້ຮັບຕົ້ນຕໍທີ່ພວກເຮົາຕ້ອງການທີ່ຈະບັນລຸຈະເປັນຂະບວນການງ່າຍດາຍພົບທົ່ວໄປ.

ບັນທຶກ. ທຸລະກິດ PRO-TIP. ຂະບວນການທີ່ລຽບງ່າຍສາມາດປະຫຍັດເງິນໃຫ້ທ່ານໄດ້ຫຼາຍໃນການສະຫນັບສະຫນູນ (ຫຼາຍຄົນທີ່ທ່ານເຮັດວຽກສໍາລັບບໍລິສັດຂອງທ່ານ, ເງິນຫຼາຍທ່ານສາມາດປະຫຍັດໄດ້)!

ບໍ່ຈໍາເປັນຕ້ອງ rollback ຖານຂໍ້ມູນ

ອັນນີ້ເຮັດໃຫ້ຂະບວນການນຳໃຊ້ງ່າຍ (ບາງ rollback ຖານຂໍ້ມູນເກືອບເປັນໄປບໍ່ໄດ້, ເຊັ່ນ: ການລຶບ rollback). ພວກເຮົາຕ້ອງການກັບຄືນພຽງແຕ່ຄໍາຮ້ອງສະຫມັກ. ວິທີນີ້, ເຖິງແມ່ນວ່າທ່ານມີຖານຂໍ້ມູນທີ່ແຕກຕ່າງກັນ (ຕົວຢ່າງ, SQL ແລະ NoSQL), ທໍ່ການນໍາໄປໃຊ້ຂອງທ່ານຈະມີລັກສະນະດຽວກັນ.

ມັນ​ຕ້ອງ​ເປັນ​ໄປ​ໄດ້​ສະ​ເຫມີ​ທີ່​ຈະ​ກັບ​ຄືນ​ໄປ​ບ່ອນ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ຫນຶ່ງ​ສະ​ບັບ​ກັບ​ຄືນ​ໄປ​ບ່ອນ (ບໍ່​ມີ​ຕໍ່​ໄປ​)

Rollback ຄວນເຮັດເມື່ອມີຄວາມຈໍາເປັນເທົ່ານັ້ນ. ຖ້າມີ bug ໃນສະບັບປະຈຸບັນທີ່ບໍ່ໄດ້ຮັບການແກ້ໄຂໄດ້ງ່າຍ, ພວກເຮົາຄວນຈະສາມາດກັບຄືນໄປສະບັບຫລ້າສຸດທີ່ເຮັດວຽກໄດ້. ພວກ​ເຮົາ​ສົມ​ມຸດ​ວ່າ​ສະ​ບັບ​ທີ່​ເຮັດ​ວຽກ​ຫລ້າ​ສຸດ​ນີ້​ແມ່ນ​ການ​ທີ່​ຜ່ານ​ມາ​. ການຮັກສາລະຫັດແລະຄວາມເຂົ້າກັນໄດ້ຂອງຖານຂໍ້ມູນສໍາລັບການເປີດຕົວຫຼາຍກວ່າຫນຶ່ງຄັ້ງຈະເປັນການຍາກທີ່ສຸດແລະມີລາຄາແພງ.

ບັນທຶກ. ເພື່ອໃຫ້ສາມາດອ່ານໄດ້ຫຼາຍກວ່າເກົ່າ, ໃນບົດຄວາມນີ້ພວກເຮົາຈະປ່ຽນເວີຊັນທີ່ສໍາຄັນຂອງແອັບພລິເຄຊັນ.

ຂັ້ນຕອນທີ 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, deployed ໃນ​ການ​ຜະ​ລິດ​, ແລະ​ຖານ​ຂໍ້​ມູນ​ 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 (ປະມານ per.: ຜູ້ຂຽນອາດຈະຫມາຍເຖິງການທົດສອບ A/B ຢູ່ທີ່ນີ້) ພວກເຮົາຕັດສິນໃຈວ່າພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ກັບຄືນຄໍາຮ້ອງສະຫມັກເປັນສະບັບ 1.0.0. ໃຫ້ເວົ້າວ່າພວກເຮົາບໍ່ຕ້ອງການ rollback ຖານຂໍ້ມູນ.

ຂັ້ນຕອນ:

1. ພວກ​ເຮົາ​ຢຸດ​ເຊົາ​ການ​ຕົວ​ຢ່າງ​ຂອງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ສະ​ບັບ​ 2.0.0.BAD
2. ຖານຂໍ້ມູນແມ່ນຍັງ v2bad
3. ນັບ​ຕັ້ງ​ແຕ່​ສະ​ບັບ​ 1.0.0 ບໍ່ເຂົ້າໃຈວ່າມັນແມ່ນຫຍັງ surname, ພວກເຮົາຈະເຫັນຄວາມຜິດພາດ
4. hell ໄດ້ແຕກຫັກ, ພວກເຮົາບໍ່ສາມາດກັບຄືນໄດ້

ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, ຖ້າພວກເຮົາເຮັດການປ່ຽນແປງທີ່ບໍ່ເຂົ້າກັນກັບຖານຂໍ້ມູນແລະແອັບພລິເຄຊັນ, ພວກເຮົາບໍ່ສາມາດກັບຄືນໄປຫາສະບັບກ່ອນຫນ້າ.

ບັນທຶກການປະຕິບັດສະຄຣິບ

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

ທີ່ມາ script 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 ສຸດ surname.

ການປ່ຽນຊື່ຖັນໃນແບບທີ່ເຂົ້າກັນໄດ້ກັບຫຼັງ

ນີ້ແມ່ນສະຖານະການທົ່ວໄປທີ່ສຸດທີ່ພວກເຮົາອາດຈະພົບ. ພວກ​ເຮົາ​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ເຮັດ​ໃຫ້​ການ​ປ່ຽນ​ແປງ​ທີ່​ບໍ່​ເຂົ້າ​ກັນ​ກັບ​ຫຼັງ​. ພວກເຮົາໄດ້ພິສູດແລ້ວວ່າສໍາລັບການຕິດຕັ້ງເວລາສູນ, ພວກເຮົາບໍ່ຄວນພຽງແຕ່ນໍາໃຊ້ການເຄື່ອນຍ້າຍຖານຂໍ້ມູນໂດຍບໍ່ມີຂັ້ນຕອນເພີ່ມເຕີມ. ໃນພາກນີ້ຂອງບົດຄວາມ, ພວກເຮົາຈະປະຕິບັດ 3 ການປະຕິບັດຂອງຄໍາຮ້ອງສະຫມັກພ້ອມກັບການເຄື່ອນຍ້າຍຖານຂໍ້ມູນເພື່ອບັນລຸຜົນໄດ້ຮັບທີ່ຕ້ອງການໃນຂະນະທີ່ຮັກສາຄວາມເຂົ້າກັນໄດ້ກັບຫລັງ.

ບັນທຶກ. ຈື່ໄວ້ວ່າພວກເຮົາມີຖານຂໍ້ມູນສະບັບ v1. ມັນປະກອບດ້ວຍຖັນ first_name и last_name. ພວກເຮົາຕ້ອງປ່ຽນແປງ last_name ສຸດ surname. ພວກເຮົາຍັງມີສະບັບ app 1.0.0, ເຊິ່ງຍັງບໍ່ທັນໄດ້ນຳໃຊ້ເທື່ອ surname.

ຂັ້ນຕອນທີ 2: ເພີ່ມນາມສະກຸນ

ລຸ້ນແອັບ: 2.0.0
ລຸ້ນ DB: v2

ຄວາມຄິດເຫັນ

ໂດຍການເພີ່ມຖັນໃໝ່ ແລະສຳເນົາເນື້ອຫາຂອງມັນ, ພວກເຮົາສ້າງການປ່ຽນແປງຖານຂໍ້ມູນທີ່ເຂົ້າກັນໄດ້ກັບຫຼັງ. ໃນເວລາດຽວກັນ, ຖ້າພວກເຮົາ rollback JAR ຫຼືມີ JAR ເກົ່າແລ່ນ, ມັນຈະບໍ່ແຕກໃນລະຫວ່າງການປະຕິບັດ.

ພວກເຮົາກຳລັງເປີດຕົວເວີຊັນໃໝ່

ຂັ້ນຕອນ:

1. ປະຕິບັດການເຄື່ອນຍ້າຍຖານຂໍ້ມູນເພື່ອສ້າງຖັນໃຫມ່ surname. ໃນປັດຈຸບັນສະບັບ DB ຂອງທ່ານ v2
2. ສຳເນົາຂໍ້ມູນຈາກ last_name в surname. ຈ່າຍເອົາໃຈໃສ່ວ່າຖ້າທ່ານມີຂໍ້ມູນນີ້ຫຼາຍ, ທ່ານຄວນພິຈາລະນາການເຄື່ອນຍ້າຍ batch!
3. ຂຽນລະຫັດບ່ອນທີ່ພວກເຂົາຖືກນໍາໃຊ້ ທັງສອງ и ໃຫມ່ແລະ ອາຍຸ ຖັນ. ໃນປັດຈຸບັນສະບັບ app ຂອງທ່ານ 2.0.0
4. ອ່ານຄ່າຈາກຖັນ surname, ຖ້າມັນບໍ່ແມ່ນ null, ຫຼືຈາກ last_name, ຖ້າເປັນ surname ບໍ່ໄດ້ລະບຸ. ທ່ານສາມາດລຶບ getLastName() ຈາກລະຫັດ, ເນື່ອງຈາກວ່າມັນຈະອອກ null ໃນ​ເວ​ລາ​ທີ່ rolling ກັບ​ຄືນ​ໄປ​ບ່ອນ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ຂອງ​ທ່ານ​ຈາກ​ 3.0.0 ການ 2.0.0.

ຖ້າທ່ານກໍາລັງໃຊ້ Spring Boot Flyway, ສອງຂັ້ນຕອນນີ້ຈະຖືກປະຕິບັດໃນລະຫວ່າງການເລີ່ມຕົ້ນຮຸ່ນ 2.0.0 ຄໍາຮ້ອງສະຫມັກ. ຖ້າທ່ານດໍາເນີນການເຄື່ອງມືການສ້າງສະບັບຖານຂໍ້ມູນດ້ວຍຕົນເອງ, ທ່ານຈະຕ້ອງເຮັດສອງສິ່ງທີ່ແຕກຕ່າງກັນເພື່ອເຮັດສິ່ງນີ້ (ທໍາອິດປັບປຸງສະບັບ db ດ້ວຍຕົນເອງແລະຫຼັງຈາກນັ້ນນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກໃຫມ່).

ມັນເປັນສິ່ງສໍາຄັນ. ຈື່ໄວ້ວ່າຖັນທີ່ສ້າງຂຶ້ນໃຫມ່ ບໍ່​ຄວນ ຈະ ບໍ່ NULL. ຖ້າທ່ານເຮັດ rollback, ແອັບພລິເຄຊັນເກົ່າບໍ່ຮູ້ກ່ຽວກັບຄໍລໍາໃຫມ່ແລະຈະບໍ່ຕິດຕັ້ງມັນໃນລະຫວ່າງ Insert. ແຕ່ຖ້າທ່ານເພີ່ມຂໍ້ຈໍາກັດນີ້ແລະ db ຂອງທ່ານຈະເປັນ v2, ນີ້ຈະຕ້ອງກໍານົດຄ່າຂອງຖັນໃຫມ່. ເຊິ່ງຈະນໍາໄປສູ່ການລະເມີດຂໍ້ຈໍາກັດ.

ມັນເປັນສິ່ງສໍາຄັນ. ທ່ານຄວນເອົາວິທີການອອກ getLastName(), ເນື່ອງຈາກວ່າຢູ່ໃນສະບັບ 3.0.0 ບໍ່ມີແນວຄວາມຄິດຂອງຖັນຢູ່ໃນລະຫັດ last_name. ນີ້ຫມາຍຄວາມວ່າ null ຈະຖືກຕັ້ງຢູ່ທີ່ນັ້ນ. ທ່ານສາມາດອອກຈາກວິທີການແລະເພີ່ມການກວດສອບສໍາລັບ null, ແຕ່ການແກ້ໄຂທີ່ດີກວ່າຫຼາຍແມ່ນເພື່ອເຮັດໃຫ້ແນ່ໃຈວ່າໃນເຫດຜົນ getSurname() ທ່ານເລືອກຄ່າທີ່ບໍ່ແມ່ນສູນທີ່ຖືກຕ້ອງ.

ການທົດສອບ A/B

ສະຖານະການໃນປະຈຸບັນແມ່ນວ່າພວກເຮົາມີສະບັບຄໍາຮ້ອງສະຫມັກ 1.0.0, deployed ສຸດການຜະລິດ, ແລະຖານຂໍ້ມູນໃນ 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 ຖັນ) ທ່ານອາດຈະມີຂໍ້ມູນບໍ່ສອດຄ່ອງຫາກທ່ານສອບຖາມຖັນໃໝ່.

ການ​ເລື່ອນ​ຄືນ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​

ໃນປັດຈຸບັນພວກເຮົາມີ app ສະບັບ 2.0.0 ແລະຖານຂໍ້ມູນໃນ v2.

ຂັ້ນຕອນ:

1. ກັບຄືນແອັບພລິເຄຊັນຂອງທ່ານໃຫ້ເປັນເວີຊັນ 1.0.0.
2. ຮຸ່ນ 1.0.0 ບໍ່ໄດ້ໃຊ້ຖັນໃນຖານຂໍ້ມູນ surname, ດັ່ງນັ້ນ rollback ຄວນຈະປະສົບຜົນສໍາເລັດ

DB ການປ່ຽນແປງ

ຖານຂໍ້ມູນມີຖັນຊື່ last_name.

script ແຫຼ່ງ 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.

ເອົາໃຈໃສ່. ຈື່ໄວ້ວ່າທ່ານບໍ່ສາມາດເພີ່ມຂໍ້ຈໍາກັດ NOLL ໃດໆໃສ່ຖັນທີ່ທ່ານກໍາລັງເພີ່ມ. ຖ້າທ່ານ rollback 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

ຄວາມຄິດເຫັນ

ຫມາຍ​ເຫດ​ per.: ປາກົດຂື້ນ, ໃນບົດຄວາມຕົ້ນສະບັບຜູ້ຂຽນຜິດພາດໄດ້ຄັດລອກຂໍ້ຄວາມຂອງບລັອກນີ້ຈາກຂັ້ນຕອນ 2. ໃນຂັ້ນຕອນນີ້, ຄວນຈະມີການປ່ຽນແປງໃນລະຫັດຄໍາຮ້ອງສະຫມັກທີ່ມີຈຸດປະສົງເພື່ອເອົາຫນ້າທີ່ໃຊ້ຄໍລໍາ. last_name.

ໂດຍການເພີ່ມຖັນໃໝ່ ແລະສຳເນົາເນື້ອຫາຂອງມັນ, ພວກເຮົາສ້າງການປ່ຽນແປງຖານຂໍ້ມູນທີ່ເຂົ້າກັນໄດ້ກັບຫຼັງ. ນອກຈາກນັ້ນ, ຖ້າພວກເຮົາ rollback JAR ຫຼືມີ JAR ເກົ່າແລ່ນ, ມັນຈະບໍ່ແຕກໃນລະຫວ່າງການປະຕິບັດ.

ການ​ເລື່ອນ​ຄືນ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​

ໃນປັດຈຸບັນພວກເຮົາມີ app ສະບັບ 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

ການປ່ຽນແປງຖານຂໍ້ມູນ

ບໍ່ມີການປ່ຽນແປງໂຄງສ້າງໃນຖານຂໍ້ມູນ. script ຕໍ່ໄປນີ້ຖືກປະຕິບັດເພື່ອປະຕິບັດການເຄື່ອນຍ້າຍສຸດທ້າຍຂອງຂໍ້ມູນເກົ່າ:

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

ການປ່ຽນແປງລະຫັດ

ຫມາຍ​ເຫດ​ per.: ຄໍາອະທິບາຍຂອງບລັອກນີ້ຍັງຖືກຄັດລອກຜິດພາດໂດຍຜູ້ຂຽນຈາກຂັ້ນຕອນ 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 schema ຖານຂໍ້ມູນ (ຊື່ຖັນ = last_name)
2. ການນຳໃຊ້ເວີຊັນແອັບພລິເຄຊັນ 2.0.0, ທີ່ເກັບຮັກສາຂໍ້ມູນຢູ່ໃນ last_name и surname. ຄໍາຮ້ອງສະຫມັກອ່ານຈາກ last_name. ຖານຂໍ້ມູນແມ່ນຢູ່ໃນສະບັບ v2ປະກອບມີຖັນເຊັ່ນ last_name, ແລະ surname. surname ແມ່ນສໍາເນົາຂອງ last_name. (ໝາຍເຫດ: ຖັນນີ້ຕ້ອງບໍ່ມີຂໍ້ຈຳກັດທີ່ບໍ່ແມ່ນ null)
3. ການນຳໃຊ້ເວີຊັນແອັບພລິເຄຊັນ 3.0.0, ເຊິ່ງພຽງແຕ່ເກັບຮັກສາຂໍ້ມູນໃນ surname ແລະອ່ານຈາກນາມສະກຸນ. ສໍາລັບຖານຂໍ້ມູນ, ການເຄື່ອນຍ້າຍສຸດທ້າຍແມ່ນເກີດຂຶ້ນ last_name в surname. ຍັງເປັນຂໍ້ຈໍາກັດ ບໍ່ NULL ເອົາ​ອອກ​ຈາກ last_name. ຖານຂໍ້ມູນປະຈຸບັນຢູ່ໃນສະບັບ v3
4. ການນຳໃຊ້ເວີຊັນແອັບພລິເຄຊັນ 4.0.0 - ບໍ່ມີການປ່ຽນແປງລະຫັດ. ການນຳໃຊ້ຖານຂໍ້ມູນ v4, ທີ່ເອົາອອກ last_name. ໃນທີ່ນີ້ທ່ານສາມາດເພີ່ມຂໍ້ຈໍາກັດໃດໆທີ່ຂາດຫາຍໄປໃນຖານຂໍ້ມູນ.

ໂດຍປະຕິບັດຕາມວິທີການນີ້, ທ່ານສະເຫມີສາມາດກັບຄືນຫນຶ່ງສະບັບໂດຍບໍ່ມີການທໍາລາຍຖານຂໍ້ມູນ / ຄໍາຮ້ອງສະຫມັກເຂົ້າກັນໄດ້.

ລະ​ຫັດ

ລະຫັດທັງໝົດທີ່ໃຊ້ໃນບົດຄວາມນີ້ແມ່ນມີຢູ່ GitHub. ຂ້າງລຸ່ມນີ້ແມ່ນຄໍາອະທິບາຍເພີ່ມເຕີມ.

ໂຄງການ

ຫຼັງຈາກ cloning repository, ທ່ານຈະເຫັນໂຄງສ້າງໂຟນເດີຕໍ່ໄປນີ້.

├── 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 ຕົວຢ່າງ Flyway

ຕົວຢ່າງທັງຫມົດແມ່ນເອົາມາຈາກ Spring Boot Sample Flyway.

ທ່ານສາມາດໃຊ້ເວລາເບິ່ງ http://localhost:8080/flyway, ມີບັນຊີລາຍຊື່ຂອງສະຄິບ.

ຕົວຢ່າງນີ້ຍັງປະກອບມີ H2 console (at http://localhost:8080/h2-console) ດັ່ງນັ້ນທ່ານສາມາດເບິ່ງສະຖານະພາບຖານຂໍ້ມູນ ( URL jdbc ເລີ່ມຕົ້ນແມ່ນ jdbc:h2:mem:testdb).

ນອກຈາກນັ້ນ

• ຮູບແບບການປະຕິສັງຂອນຖານຂໍ້ມູນ
• ການຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງ

ອ່ານບົດຄວາມອື່ນໆໃນ blog ຂອງພວກເຮົາ:

• Kubernetes: ເປັນຫຍັງມັນຈຶ່ງສຳຄັນຫຼາຍໃນການຕັ້ງຄ່າການຈັດການຊັບພະຍາກອນຂອງລະບົບ?
• ທໍ່ Tekton - Kubernetes-native pipelines
• ການກໍ່ສ້າງໂມດູນແບບເຄື່ອນໄຫວສໍາລັບ Nginx
• ການແນະນໍາການອະນຸຍາດ Kubernetes ຂອງກົງສຸນ Hashicorp
• ການເຄື່ອນຍ້າຍຈາກ ClickHouse ໂດຍບໍ່ມີການອະນຸຍາດໄປຫາ ClickHouse ດ້ວຍການອະນຸຍາດນໍາໄປສູ່ຫຍັງ?
• ການນຳໃຊ້ສີຟ້າ-ສີຂຽວຂອງແອັບພລິເຄຊັນພາກຮຽນ spring ກັບເຊີບເວີເວັບ Nginx

ແຫຼ່ງຂໍ້ມູນ: www.habr.com