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