איך לא לירות לעצמך ברגל באמצעות Liquibase

זה מעולם לא קרה, והנה זה שוב!

בפרויקט הבא, החלטנו להשתמש ב-Liquibase מההתחלה כדי למנוע בעיות בעתיד. כפי שהתברר, לא כל חברי הצוות הצעירים יודעים איך להשתמש בו נכון. עשיתי סדנה פנימית, ואז החלטתי להפוך אותה למאמר.

מאמר זה כולל טיפים ותיאורים מועילים של שלוש מהמלכודות הברורות ביותר שאתה יכול ליפול בהן כשאתה עובד עם כלי העברת מסדי נתונים יחסיים, בפרט Liquibase. מיועד למפתחי ג'אווה ברמת ג'וניור וברמה בינונית, עבור מפתחים מנוסים יותר זה עשוי להיות מעניין למבנה ולחזור על מה שסביר להניח שכבר ידוע.

Liquibase ו-Flyway הן הטכנולוגיות המתחרות העיקריות לפתרון בעיות בקרת גרסאות של מבנים יחסיים בעולם Java. הראשון הוא חינמי לחלוטין, בפועל הוא נבחר לעתים קרובות יותר לשימוש, ולכן Liquibase נבחר כגיבור הפרסום. עם זאת, חלק מהשיטות המתוארות עשויות להיות כלליות, בהתאם לארכיטקטורת היישום שלך.

הגירות יחסיות הן דרך מאולצת להתמודד עם הגמישות החלשה של מאגרי נתונים יחסיים. בעידן האופנה של OOP, סגנון העבודה עם בסיס הנתונים גרם לכך שנתאר את הסכימה פעם אחת ולא ניגע בה שוב. אבל המציאות היא תמיד שדברים משתנים, ושינויים במבנה הטבלאות נדרשים לעתים קרובות למדי. מטבע הדברים, התהליך עצמו כואב ולא נעים.

לא אתעמק בתיאור הטכנולוגיה ובהנחיות להוספת הספרייה לפרויקט שלך, נכתבו מספיק מאמרים בנושא זה:

• שימוש ב-Liquibase לניהול מבנה מסד הנתונים באפליקציית Spring Boot. חלק 1
• שימוש ב-Liquibase לניהול מבנה מסד הנתונים באפליקציית Spring Boot. חלק 2
• Liquibase ומייבן
• גישות לשינויי מסד נתונים
• Spring MVC/Security, REST, Hibernate, Liquibase פועלים בשני קווים

בנוסף, כבר היה מאמר נהדר בנושא טיפים שימושיים:

• שימוש ב-Liquibase ללא כאב ראש. 10 טיפים מניסיון אמיתי בפיתוח

Советы

אני רוצה לחלוק את העצות וההערות שלי, שנולדו מהזיעה, הדם והכאב של פתרון בעיות עם הגירה.

1. לפני שמתחילים, כדאי לקרוא את סעיף השיטות המומלצות בנושא מקוון נזילות

Там מתוארים דברים פשוטים אך חשובים מאוד, שבלעדיהם השימוש בספרייה יכול לסבך את חייך. לדוגמה, גישה לא מבנית לניהול ערכות שינויים תוביל במוקדם או במאוחר לבלבול ולהגירות שבירות. אם לא תוציאו במקביל שינויים תלויים הדדיים במבנה מסד הנתונים והלוגיקה של השירותים, אז יש סבירות גבוהה שזה יוביל לבדיקות אדומות או לסביבה שבורה. בנוסף, ההמלצות לשימוש ב-Liquibase באתר הרשמי מכילות פסקה על פיתוח ואימות של סקריפטים לחזרה יחד עם סקריפטי ההגירה העיקריים. ובכן, בכתבה https://habr.com/ru/post/178665/ ישנן דוגמאות לקוד הקשור להגירות ולמנגנון החזרה לאחור.

2. אם התחלת להשתמש בכלי הגירה, אל תאפשר תיקונים ידניים במבנה מסד הנתונים

כמו שנאמר: "פעם פרסיל, תמיד פרסיל". אם הבסיס של האפליקציה שלך התחיל להיות מנוהל על ידי כלי Liquibase, כל שינוי ידני מוביל באופן מיידי למצב לא עקבי, ורמת האמון בערכות השינויים הופכת לאפס. סיכונים פוטנציאליים - מספר שעות שהושקעו בשחזור מסד הנתונים, במקרה הגרוע ביותר - שרת מת. אם לצוות שלכם יש אדריכל DBA "אולד סקול", הסבירו לו בסבלנות ובמחשבה עד כמה המצב יהיה גרוע אם הוא רק יערוך את מסד הנתונים בדרכו שלו ממפתח SQL המותנה.

3. אם ערכת השינויים כבר נדחפה למאגר, הימנע מעריכה

אם מפתח אחר משך והחיל ערכת שינויים שיערך מאוחר יותר, הוא בהחלט יזכור אותך במילה טובה כאשר יקבל שגיאה בעת הפעלת האפליקציה. אם עריכת ערכת השינויים דולפת איכשהו לפיתוח, תצטרך לרדת במדרון החלקלק של התיקונים החמים. מהות הבעיה נשענת על אימות השינויים לפי סכום hash - המנגנון העיקרי של Liquibase. בעת עריכת קוד ערכת השינויים, סכום הגיבוב משתנה. עריכת ערכות שינויים אפשרית רק כאשר ניתן לפרוס את כל מסד הנתונים מאפס מבלי לאבד נתונים. במקרה זה, עיבוד מחדש של קוד SQL או XML יכול, להיפך, להקל על החיים, להפוך את ההגירות לקריאה יותר. דוגמה לכך היא מצב שבו בתחילת האפליקציה, הסכימה של מסד הנתונים של המקור תואמה בתוך הצוות.

4. יש לאמת גיבויים של מסד נתונים אם אפשר

כאן, אני חושב, הכל ברור. אם פתאום ההגירה לא הצליחה, אפשר להחזיר הכל בחזרה. ל-Liquibase יש כלי Rollback, אבל גם הסקריפטים של ה-Rollback נכתבים על ידי המפתח עצמו, ויכולות להיות להם בעיות באותה הסתברות כמו בסקריפטים הראשיים של ערכת השינויים. זה אומר שמשחק בטוח עם גיבויים שימושי בכל מקרה.

5. השתמש בגיבויים מאומתים של מסד נתונים בפיתוח במידת האפשר

אם זה לא סותר חוזים ופרטיות, אין נתונים אישיים במסד הנתונים, והוא לא שוקל כמו שתי שמשות - לפני יישום זה על שרתי מיגרציה חיים, אתה יכול לבדוק איך זה עובד במחשב של המפתח ולחשב כמעט 100% של בעיות אפשריות במהלך ההגירה.

6. צ'אט עם מפתחים אחרים בצוות

בתהליך פיתוח מאורגן היטב, כל אחד בצוות יודע מי עושה מה. במציאות, לרוב זה לא המקרה, לכן, אם אתם מכינים שינויים במבנה מסד הנתונים כחלק מהמשימה שלכם, מומלץ להודיע ​​על כך בנוסף לכל הצוות. אם מישהו מבצע שינויים במקביל, כדאי לארגן בזהירות. כדאי לתקשר עם עמיתים גם בסיום העבודה, לא רק בתחילת העבודה. ניתן לפתור בעיות פוטנציאליות רבות עם ערכות שינויים בשלב סקירת הקוד.

7. תחשוב מה אתה עושה!

לכאורה עצות מובנות מאליהן החלות בכל מצב. עם זאת, ניתן היה למנוע בעיות רבות אם המפתח היה מנתח שוב מה הוא עושה ועל מה זה עשוי להשפיע. עבודה עם העברות תמיד דורשת תשומת לב ודיוק נוספים.

מלכודות

הבה נסתכל כעת על המלכודות האופייניות שאתה יכול ליפול אליהן אם לא תמלא אחר העצות שלמעלה, ומה, למעשה, צריך לעשות?

מצב 1. שני מפתחים מנסים להוסיף ערכות שינויים חדשים בו-זמנית

ואסיה ופטיה רוצות ליצור ערכת שינויים בגרסה 4 מבלי לדעת אחד על השני. הם ביצעו שינויים במבנה מסד הנתונים, והוציאו בקשת משיכה, עם קבצי שינויים שונים. המנגנון הבא מוצע להלן:

איך לפתור

1. איכשהו, עמיתים חייבים להסכים על הסדר שבו השינויים שלהם צריכים לעבור, נניח שיש להחיל את Petin קודם.
2. אדם אחד צריך לשפוך את השני ולסמן את ערכת השינויים של Vasya עם גרסה 5. זה יכול להיעשות באמצעות Cherry Pick או מיזוג מסודר.
3. לאחר השינויים, הקפידו לבדוק את תקפות הפעולות שנעשו.
   למעשה, מנגנוני Liquibase יאפשרו לך שני ערכות שינויים בגרסה 4 במאגר, כך שתוכל להשאיר הכל כמו שהוא. כלומר, פשוט יהיו לך שתי גרסאות של גרסה 4 עם שמות שונים. עם גישה זו, גרסאות מסד הנתונים הופכות קשות מאוד לניווט מאוחר יותר.

בנוסף, Liquibase, כמו הבתים של ההוביטים, שומר על הרבה סודות. אחד מהם הוא מפתח validCheckSum, שהופיע מגרסה 1.7 ומאפשר לציין ערך hash חוקי עבור ערכת שינויים ספציפית, ללא קשר למה שמאוחסן במסד הנתונים. תיעוד https://www.liquibase.org/documentation/changeset.html אומר את הדברים הבאים:

הוסף סכום בדיקה שנחשב לתקף עבור changeSet זה, ללא קשר למה שמאוחסן במסד הנתונים. משמש בעיקר כאשר אתה צריך לשנות ChangeSet ולא רוצה שגיאות יוזרקו על מסדי נתונים שעליהם הוא כבר רץ (לא הליך מומלץ)

כן, זה לא מומלץ. אבל לפעמים קוסם אור חזק שולט גם בטכניקות אפלות.

מקרה 2: הגירה מונעת נתונים

נניח שאינך יכול להשתמש בגיבויים של מסדי נתונים משרתים חיים. Petya יצרה ערכת שינויים, בדקה אותה באופן מקומי, ובביטחון מלא שהוא צדק, הגישה בקשת משיכה למפתח. ליתר בטחון, מנהיג הפרויקט הבהיר אם פטיה בדקה את זה, ואז שפך אותו פנימה. אבל הפריסה בשרת הפיתוח נפלה.

למעשה, זה אפשרי, ואף אחד לא חסין מזה. זה קורה אם השינויים במבנה הטבלה קשורים איכשהו לנתונים ספציפיים ממסד הנתונים. ברור שאם מסד הנתונים של Petya מלא בנתוני בדיקה בלבד, ייתכן שהוא לא יכסה את כל מקרי הבעיות. לדוגמה, בעת מחיקת טבלה, מתברר שיש רשומות בטבלאות אחרות לפי Foreign Key המשויכות לרשומות בזו הנמחקת. או כשמשנים את סוג העמודה, מסתבר שלא ניתן להמיר 100% מהנתונים לסוג החדש.

איך לפתור

• כתוב סקריפטים מיוחדים שיושמו פעם אחת יחד עם ההגירה והבא את הנתונים לצורה המתאימה. זוהי דרך כללית לפתור את בעיית העברת הנתונים למבנים חדשים לאחר החלת העברות, אך ניתן ליישם משהו דומה לפני כן, במקרים מיוחדים. נתיב זה, כמובן, לא תמיד זמין, כי עריכת נתונים בשרתים חיים עלולה להיות מסוכנת ואף קטלנית.
• דרך מסובכת נוספת היא לערוך ערכת שינויים קיימת. הקושי הוא שכל מסדי הנתונים שבהם זה כבר הוחל בצורתו הקיימת יצטרכו להיות משוחזרים. בהחלט ייתכן שכל צוות ה-backend ייאלץ לגלגל את בסיס הנתונים באופן מקומי מאפס.
• והדרך האוניברסלית ביותר היא להעביר את בעיית הנתונים לסביבת המפתח, לשחזר את אותו המצב ולהוסיף ערכת שינויים חדשה, לאחד שבור, שיעקוף את הבעיה.
  

באופן כללי, ככל שבסיס הנתונים יהיה יותר דומה בהרכבו למסד הנתונים של שרת הייצור, כך קטן הסיכוי שבעיות בהגירות יגיעו רחוק. וכמובן, לפני שאתה שולח את ערכת השינויים למאגר, אתה צריך לחשוב כמה פעמים אם זה ישבור משהו.

מצב 3. השימוש ב-Liquibase מתחיל לאחר כניסתו לייצור

נניח שראש הצוות ביקש מפטיה לכלול את Liquibase בפרויקט, אבל הפרויקט כבר בייצור ויש מבנה מסד נתונים קיים כבר.

בהתאם, הבעיה היא שבכל שרת או מכונות מפתחים חדשים, יש ליצור מחדש את נתוני הטבלה מאפס, והסביבה הקיימת כבר חייבת להישאר במצב עקבי, להיות מוכנה לקבל ערכות שינויים חדשים.

איך לפתור

יש גם כמה דרכים:

• הראשון והברור ביותר הוא סקריפט נפרד שיש ליישם באופן ידני בעת אתחול סביבה חדשה.
• השני, פחות ברור, הוא לבצע הגירה של Liquibase שנמצאת בהקשר אחר של Liquibase וליישם אותה. אתה יכול לקרוא עוד על Liquibase Context כאן: https://www.liquibase.org/documentation/contexts.html. באופן כללי, מדובר במנגנון מעניין שניתן ליישם בהצלחה, למשל, לבדיקה.
• השביל השלישי מורכב ממספר שלבים. ראשית, יש ליצור הגירה עבור טבלאות קיימות. אז יש ליישם אותו על סביבה כלשהי וכך יתקבל סכום ה-hash שלו. השלב הבא הוא לאתחל טבלאות Liquibase ריקות בשרת הלא ריק שלנו, ותוכלו להכניס באופן ידני רשומה של ערכת שינויים "כאילו הוחל" עם השינויים שכבר נמצאים במסד הנתונים לטבלה עם ההיסטוריה של החלת ערכות שינויים. כך, בשרת שכבר קיים, ההיסטוריה תתחיל מגרסה 2, וכל הסביבות החדשות יתנהגו באופן זהה.
  

תרחיש 4: ההגירות נעשות עצומות ואינן יכולות לעמוד בקצב

בתחילת פיתוח השירות, ככלל, Liquibase משמש כתלות חיצונית, וכל ההגירות מעובדות עם תחילת האפליקציה. עם זאת, עם הזמן, אתה עלול להיתקל במקרים הבאים:

• ההגירות הופכות לעצומות ולוקח זמן רב להשלמתן.
• יש צורך במעבר בסביבות מבוזרות, למשל, במספר מופעים של שרתי מסד נתונים בו-זמנית.
  במקרה זה, החלת העברות במשך זמן רב מדי תגרום לפסק זמן כאשר היישום יתחיל. כמו כן, החלת העברות על בסיס מופע אפליקציה עלולה לגרום לכך ששרתים שונים נמצאים במצב לא מסונכרן.

איך לפתור

במקרים כאלה, הפרויקט שלך כבר גדול, אולי אפילו מבוגר, ו-Liquibase מתחיל לפעול ככלי חיצוני נפרד. העובדה היא ש-Liquibase, כספרייה, מורכבת לקובץ jar, ויכולה לעבוד כתלות בתוך הפרויקט, כמו גם עצמאית.

במצב לא מקוון, אתה יכול להשאיר את יישום ההגירות לסביבת ה-CI/CD שלך או לכתפיים החזקות של מנהלי המערכת/המפרסים שלך. כדי לעשות זאת, אתה צריך את שורת הפקודה Liquibase https://www.liquibase.org/documentation/command_line.html. במצב זה, ניתן יהיה להפעיל את האפליקציה לאחר השלמת כל ההעברות הדרושות.

פלט

למעשה, יש הרבה יותר מלכודות בעבודה עם העברות של מסדי נתונים, ורבות מהן דורשות גישה יצירתית. חשוב להבין שאם משתמשים בכלי נכון, אז ניתן להימנע מרוב המלכודות הללו. באופן ספציפי, נאלצתי להתמודד עם כל הבעיות המפורטות בצורות שונות, וחלקן היו תוצאה של המשקופים שלי. בעיקרון זה קורה, כמובן, בגלל חוסר תשומת לב, אבל לפעמים - בגלל חוסר היכולת הפלילית להשתמש בכלי.

מקור: www.habr.com