שדרוג PostgreSQL בין גרסאות ראשיות (pg_upgrade)

שדרוג מג'ורי של PostgreSQL: איפה הפרודקשן נשבר

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

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

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

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

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

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

מה משתנה לאחר המעבר לענף מג'ורי חדש

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

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

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

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

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

דרכי שדרוג: השוואת מצבים ומגבלות

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

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

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

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

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

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

סדר העבודה: מביקורת התאימות ועד ההחלפה

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

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

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

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

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

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

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

מה נשאר בידיים: קונפיגורציות, סכימות, נהלים

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

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

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

מקרה בוחן: מעבר בלי השבתה ארוכה ועם חזרה לאחור מהירה

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

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

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

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

מה עושים אם המסד כבר פועל בקלאסטר עם רפליקות?

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

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

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

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

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

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

ספקות טכניים לפני המעבר: שאלות ותשובות

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

מה עושים עם הרחבות לא תואמות?

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

האם חזרה לאחור בטוחה אפשרית?

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

האם נפח מסד גדול יעמוד בזה?

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

האם נצטרך לתקן את קוד היישום?

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

נדון במשימה ונחזור עם תוכנית עבודה

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

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

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

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