ಪ್ರೊಹೋಸ್ಟರ್ > Блог > ಆಡಳಿತ > ಶೂನ್ಯ ಡೌನ್‌ಟೈಮ್ ನಿಯೋಜನೆ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ಗಳು

ಶೂನ್ಯ ಡೌನ್‌ಟೈಮ್ ನಿಯೋಜನೆ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ಗಳು

ಶೂನ್ಯ ಡೌನ್‌ಟೈಮ್ ನಿಯೋಜನೆ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ಗಳು

ನಿಯೋಜನೆಯಲ್ಲಿ ಡೇಟಾಬೇಸ್ ಹೊಂದಾಣಿಕೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಹೇಗೆ ಪರಿಹರಿಸುವುದು ಎಂಬುದನ್ನು ಈ ಲೇಖನವು ವಿವರವಾಗಿ ವಿವರಿಸುತ್ತದೆ. ಪ್ರಾಥಮಿಕ ಸಿದ್ಧತೆಯಿಲ್ಲದೆ ನೀವು ನಿಯೋಜಿಸಲು ಪ್ರಯತ್ನಿಸಿದರೆ ನಿಮ್ಮ ಉತ್ಪಾದನಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಏನಾಗಬಹುದು ಎಂಬುದನ್ನು ನಾವು ನಿಮಗೆ ತಿಳಿಸುತ್ತೇವೆ. ನಾವು ನಂತರ ಶೂನ್ಯ ಅಲಭ್ಯತೆಯನ್ನು ಹೊಂದಲು ಅಗತ್ಯವಿರುವ ಅಪ್ಲಿಕೇಶನ್ ಜೀವನಚಕ್ರ ಹಂತಗಳ ಮೂಲಕ ಹೋಗುತ್ತೇವೆ (ಅಂದಾಜು ಲೇನ್: ಮುಂದೆ - ಶೂನ್ಯ ಅಲಭ್ಯತೆ) ಹಿಮ್ಮುಖ-ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದ ಡೇಟಾಬೇಸ್ ಬದಲಾವಣೆಯನ್ನು ಹಿಂದಕ್ಕೆ-ಹೊಂದಾಣಿಕೆಯ ರೀತಿಯಲ್ಲಿ ಅನ್ವಯಿಸುವುದು ನಮ್ಮ ಕಾರ್ಯಾಚರಣೆಗಳ ಫಲಿತಾಂಶವಾಗಿದೆ.

ನೀವು ಲೇಖನದಿಂದ ಕೋಡ್ ಉದಾಹರಣೆಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಬಯಸಿದರೆ, ನೀವು ಅವುಗಳನ್ನು ಇಲ್ಲಿ ಕಾಣಬಹುದು GitHub.

ಪರಿಚಯ

ಶೂನ್ಯ ಅಲಭ್ಯತೆಯ ನಿಯೋಜನೆ

ಎಂತಹ ಮಾರ್ಮಿಕ ಶೂನ್ಯ ಅಲಭ್ಯತೆಯ ನಿಯೋಜನೆ? ನೀವು ಅಪ್ಲಿಕೇಶನ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಉತ್ಪಾದನೆಗೆ ಯಶಸ್ವಿಯಾಗಿ ಪರಿಚಯಿಸುವ ರೀತಿಯಲ್ಲಿ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿಯೋಜಿಸಿದಾಗ ನೀವು ಇದನ್ನು ಹೇಳಬಹುದು, ಆದರೆ ಬಳಕೆದಾರರು ಅದರ ಅಲಭ್ಯತೆಯನ್ನು ಗಮನಿಸುವುದಿಲ್ಲ. ಬಳಕೆದಾರ ಮತ್ತು ಕಂಪನಿಯ ದೃಷ್ಟಿಕೋನದಿಂದ, ಇದು ಉತ್ತಮ ಸಂಭವನೀಯ ನಿಯೋಜನೆ ಸನ್ನಿವೇಶವಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಪರಿಚಯಿಸಲು ಮತ್ತು ದೋಷಗಳನ್ನು ಅಡ್ಡಿಯಿಲ್ಲದೆ ಸರಿಪಡಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.

ಇದನ್ನು ಸಾಧಿಸುವುದು ಹೇಗೆ? ಹಲವಾರು ಮಾರ್ಗಗಳಿವೆ, ಅವುಗಳಲ್ಲಿ ಒಂದು ಇಲ್ಲಿದೆ:

  • ನಿಮ್ಮ ಸೇವೆಯ ಆವೃತ್ತಿ ಸಂಖ್ಯೆ 1 ಅನ್ನು ನಿಯೋಜಿಸಿ
  • ಡೇಟಾಬೇಸ್ ವಲಸೆಯನ್ನು ನಿರ್ವಹಿಸಿ
  • ಆವೃತ್ತಿ #2 ರೊಂದಿಗೆ ಸಮಾನಾಂತರವಾಗಿ ನಿಮ್ಮ ಸೇವೆಯ #1 ಆವೃತ್ತಿಯನ್ನು ನಿಯೋಜಿಸಿ
  • ಆವೃತ್ತಿ ಸಂಖ್ಯೆ 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 ದೊಡ್ಡ ಪ್ರಯೋಜನಗಳನ್ನು ಪಡೆಯುತ್ತೀರಿ:

  • ನೀವು ಕೋಡ್ ಬದಲಾವಣೆಗಳಿಂದ ಡೇಟಾಬೇಸ್ ಬದಲಾವಣೆಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತೀರಿ
  • ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ರೋಲ್‌ಔಟ್ ಜೊತೆಗೆ ಡೇಟಾಬೇಸ್ ವಲಸೆ ಸಂಭವಿಸುತ್ತದೆ, ಅಂದರೆ. ನಿಮ್ಮ ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸರಳಗೊಳಿಸಲಾಗಿದೆ

ಡೇಟಾಬೇಸ್ ಸಮಸ್ಯೆಗಳನ್ನು ನಿವಾರಿಸುವುದು

ಲೇಖನದ ಮುಂದಿನ ವಿಭಾಗದಲ್ಲಿ, ಡೇಟಾಬೇಸ್ ಬದಲಾವಣೆಗಳಿಗೆ ಎರಡು ವಿಧಾನಗಳನ್ನು ನೋಡುವುದರ ಮೇಲೆ ನಾವು ಕೇಂದ್ರೀಕರಿಸುತ್ತೇವೆ.

  • ಹಿಂದುಳಿದ ಅಸಾಮರಸ್ಯ
  • ಹಿಂದುಳಿದ ಹೊಂದಾಣಿಕೆ

ಮೊದಲನೆಯದನ್ನು ನೀವು ಪ್ರಾಥಮಿಕ ತಯಾರಿ ಇಲ್ಲದೆ ಶೂನ್ಯ ಅಲಭ್ಯತೆಯ ನಿಯೋಜನೆಯನ್ನು ಮಾಡಬಾರದು ಎಂಬ ಎಚ್ಚರಿಕೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ... ಎರಡನೆಯದು ನೀವು ಅಲಭ್ಯತೆಯನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸಬಹುದು ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಹಿಂದುಳಿದ ಹೊಂದಾಣಿಕೆಯನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸಬಹುದು ಎಂಬುದರ ಕುರಿತು ಪರಿಹಾರವನ್ನು ನೀಡುತ್ತದೆ.

ನಾವು ಕೆಲಸ ಮಾಡುವ ನಮ್ಮ ಯೋಜನೆಯು ಸರಳವಾದ ಸ್ಪ್ರಿಂಗ್ ಬೂಟ್ ಫ್ಲೈವೇ ಅಪ್ಲಿಕೇಶನ್ ಆಗಿರುತ್ತದೆ Person с first_name и last_name ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ (ಅಂದಾಜು ಅನುವಾದ: Person ಒಂದು ಟೇಬಲ್ ಮತ್ತು first_name и last_name - ಇವು ಅದರಲ್ಲಿರುವ ಜಾಗ) ನಾವು ಮರುಹೆಸರಿಸಲು ಬಯಸುತ್ತೇವೆ last_name в surname.

ಊಹೆಗಳ

ನಾವು ವಿವರಗಳನ್ನು ಪಡೆಯುವ ಮೊದಲು, ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಕುರಿತು ನಾವು ಮಾಡಬೇಕಾದ ಕೆಲವು ಊಹೆಗಳಿವೆ. ನಾವು ಸಾಧಿಸಲು ಬಯಸುವ ಮುಖ್ಯ ಫಲಿತಾಂಶವು ಸಾಕಷ್ಟು ಸರಳವಾದ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ.

ಟಿಪ್ಪಣಿ. ವ್ಯಾಪಾರ ಪ್ರೊ-ಟಿಪ್. ಸರಳಗೊಳಿಸುವ ಪ್ರಕ್ರಿಯೆಗಳು ನಿಮಗೆ ಬೆಂಬಲದ ಮೇಲೆ ಬಹಳಷ್ಟು ಹಣವನ್ನು ಉಳಿಸಬಹುದು (ನಿಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ ನೀವು ಹೆಚ್ಚು ಜನರು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೀರಿ, ಹೆಚ್ಚು ಹಣವನ್ನು ನೀವು ಉಳಿಸಬಹುದು)!

ಡೇಟಾಬೇಸ್ ಅನ್ನು ರೋಲ್ಬ್ಯಾಕ್ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ

ಇದು ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ (ಕೆಲವು ಡೇಟಾಬೇಸ್ ರೋಲ್‌ಬ್ಯಾಕ್‌ಗಳು ಬಹುತೇಕ ಅಸಾಧ್ಯ, ಉದಾಹರಣೆಗೆ ಅಳಿಸುವಿಕೆ ರೋಲ್‌ಬ್ಯಾಕ್). ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಮಾತ್ರ ಹಿಂತಿರುಗಿಸಲು ನಾವು ಬಯಸುತ್ತೇವೆ. ಈ ರೀತಿಯಾಗಿ, ನೀವು ವಿಭಿನ್ನ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೂ ಸಹ (ಉದಾಹರಣೆಗೆ, 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

ಮೂಲ ಫ್ಲೈವೇ ಸ್ಕ್ರಿಪ್ಟ್:

CREATE TABLE PERSON (
id BIGINT GENERATED BY DEFAULT AS IDENTITY,
first_name varchar(255) not null,
last_name varchar(255) not null
);

insert into PERSON (first_name, last_name) values ('Dave', 'Syer');

ಮರುಹೆಸರಿಸುವ ಸ್ಕ್ರಿಪ್ಟ್ last_name.

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

ಕೋಡ್ ಬದಲಾವಣೆಗಳು

ನಾವು ಕ್ಷೇತ್ರದ ಹೆಸರನ್ನು ಬದಲಾಯಿಸಿದ್ದೇವೆ lastName ಮೇಲೆ surname.

ಹಿಂದಕ್ಕೆ-ಹೊಂದಾಣಿಕೆಯ ರೀತಿಯಲ್ಲಿ ಕಾಲಮ್ ಅನ್ನು ಮರುಹೆಸರಿಸಲಾಗುತ್ತಿದೆ

ಇದು ನಾವು ಎದುರಿಸಬಹುದಾದ ಸಾಮಾನ್ಯ ಪರಿಸ್ಥಿತಿ. ನಾವು ಹಿಂದಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗದ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಬೇಕಾಗಿದೆ. ಶೂನ್ಯ-ಡೌನ್‌ಟೈಮ್ ನಿಯೋಜನೆಗಾಗಿ, ಹೆಚ್ಚುವರಿ ಹಂತಗಳಿಲ್ಲದೆ ನಾವು ಡೇಟಾಬೇಸ್ ವಲಸೆಯನ್ನು ಸರಳವಾಗಿ ಅನ್ವಯಿಸಬಾರದು ಎಂದು ನಾವು ಈಗಾಗಲೇ ಸಾಬೀತುಪಡಿಸಿದ್ದೇವೆ. ಲೇಖನದ ಈ ವಿಭಾಗದಲ್ಲಿ, ಹಿಂದುಳಿದ ಹೊಂದಾಣಿಕೆಯನ್ನು ಉಳಿಸಿಕೊಂಡು ಬಯಸಿದ ಫಲಿತಾಂಶವನ್ನು ಸಾಧಿಸಲು ನಾವು ಡೇಟಾಬೇಸ್ ವಲಸೆಗಳ ಜೊತೆಗೆ ಅಪ್ಲಿಕೇಶನ್‌ನ 3 ನಿಯೋಜನೆಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತೇವೆ.

ಟಿಪ್ಪಣಿ. ನಮ್ಮಲ್ಲಿ ಆವೃತ್ತಿ ಡೇಟಾಬೇಸ್ ಇದೆ ಎಂದು ನೆನಪಿಸಿಕೊಳ್ಳಿ v1. ಇದು ಕಾಲಮ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ first_name и last_name. ನಾವು ಬದಲಾಗಬೇಕು last_name ಮೇಲೆ surname. ನಾವು ಅಪ್ಲಿಕೇಶನ್ ಆವೃತ್ತಿಯನ್ನು ಸಹ ಹೊಂದಿದ್ದೇವೆ 1.0.0, ಇದು ಇನ್ನೂ ಬಳಸಲಾಗಿಲ್ಲ surname.

ಹಂತ 2: ಉಪನಾಮವನ್ನು ಸೇರಿಸಿ

ಅಪ್ಲಿಕೇಶನ್ ಆವೃತ್ತಿ: 2.0.0
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.

ನೀವು ಸ್ಪ್ರಿಂಗ್ ಬೂಟ್ ಫ್ಲೈವೇ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ಆವೃತ್ತಿಯ ಪ್ರಾರಂಭದ ಸಮಯದಲ್ಲಿ ಈ ಎರಡು ಹಂತಗಳನ್ನು ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ 2.0.0 ಅರ್ಜಿಗಳನ್ನು. ನೀವು ಡೇಟಾಬೇಸ್ ಆವೃತ್ತಿಯ ಪರಿಕರವನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಚಲಾಯಿಸಿದರೆ, ಇದನ್ನು ಮಾಡಲು ನೀವು ಎರಡು ವಿಭಿನ್ನ ಕೆಲಸಗಳನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ (ಮೊದಲು ಡಿಬಿ ಆವೃತ್ತಿಯನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ನವೀಕರಿಸಿ ಮತ್ತು ನಂತರ ಹೊಸ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿಯೋಜಿಸಿ).

ಇದು ಮುಖ್ಯವಾಗಿದೆ. ಹೊಸದಾಗಿ ರಚಿಸಲಾದ ಕಾಲಮ್ ಎಂದು ನೆನಪಿಡಿ ಮಾಡಬಾರದು ಎಂದು ಶೂನ್ಯವಲ್ಲ. ನೀವು ರೋಲ್ಬ್ಯಾಕ್ ಮಾಡಿದರೆ, ಹಳೆಯ ಅಪ್ಲಿಕೇಶನ್ ಹೊಸ ಕಾಲಮ್ ಬಗ್ಗೆ ತಿಳಿದಿರುವುದಿಲ್ಲ ಮತ್ತು ಸಮಯದಲ್ಲಿ ಅದನ್ನು ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ Insert. ಆದರೆ ನೀವು ಈ ನಿರ್ಬಂಧವನ್ನು ಸೇರಿಸಿದರೆ ಮತ್ತು ನಿಮ್ಮ ಡಿಬಿ ಆಗಿರುತ್ತದೆ v2, ಇದಕ್ಕೆ ಹೊಸ ಕಾಲಮ್‌ನ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿಸುವ ಅಗತ್ಯವಿದೆ. ಇದು ನಿರ್ಬಂಧಗಳ ಉಲ್ಲಂಘನೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ.

ಇದು ಮುಖ್ಯವಾಗಿದೆ. ನೀವು ವಿಧಾನವನ್ನು ತೆಗೆದುಹಾಕಬೇಕು getLastName(), ಏಕೆಂದರೆ ಆವೃತ್ತಿಯಲ್ಲಿ 3.0.0 ಕೋಡ್‌ನಲ್ಲಿ ಕಾಲಮ್‌ನ ಪರಿಕಲ್ಪನೆ ಇಲ್ಲ last_name. ಅಂದರೆ ಅಲ್ಲಿ ಶೂನ್ಯವನ್ನು ಹೊಂದಿಸಲಾಗುವುದು. ನೀವು ವಿಧಾನವನ್ನು ಬಿಡಬಹುದು ಮತ್ತು ಚೆಕ್‌ಗಳನ್ನು ಸೇರಿಸಬಹುದು 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, ಆದ್ದರಿಂದ ರೋಲ್ಬ್ಯಾಕ್ ಯಶಸ್ವಿಯಾಗಬೇಕು

ಡಿಬಿ ಬದಲಾವಣೆಗಳು

ಡೇಟಾಬೇಸ್ ಹೆಸರಿನ ಕಾಲಮ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ 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.

ಗಮನ. ನೀವು ಸೇರಿಸುತ್ತಿರುವ ಕಾಲಮ್‌ಗೆ ನೀವು ಯಾವುದೇ 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"}

ಡಿಬಿ ಬದಲಾವಣೆಗಳು

ತುಲನಾತ್ಮಕವಾಗಿ 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. ಒಂದು ಮಿತಿ ಕೂಡ ಶೂನ್ಯವಲ್ಲ ನಿಂದ ತೆಗೆದುಹಾಕಲಾಗಿದೆ 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.

ನೀವು ನೋಡಬಹುದು http://localhost:8080/flyway, ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳ ಪಟ್ಟಿ ಇದೆ.

ಈ ಉದಾಹರಣೆಯು H2 ಕನ್ಸೋಲ್ ಅನ್ನು ಸಹ ಒಳಗೊಂಡಿದೆ (ನಲ್ಲಿ http://localhost:8080/h2-console) ಆದ್ದರಿಂದ ನೀವು ಡೇಟಾಬೇಸ್ ಸ್ಥಿತಿಯನ್ನು ವೀಕ್ಷಿಸಬಹುದು (ಡೀಫಾಲ್ಟ್ jdbc URL ಆಗಿದೆ jdbc:h2:mem:testdb).

ಹೆಚ್ಚುವರಿಯಾಗಿ

ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿ ಇತರ ಲೇಖನಗಳನ್ನು ಸಹ ಓದಿ:

ಮೂಲ: www.habr.com

ಕಾಮೆಂಟ್ ಅನ್ನು ಸೇರಿಸಿ