הגדרת PostgreSQL לזמינות גבוהה באמצעות repmgr

הגדרת PostgreSQL HA: היכן בדיוק נשברת העמידות לתקלות

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

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

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

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

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

מה נותן PostgreSQL עמיד לתקלות בפועל

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

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

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

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

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

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

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

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

סדר היישום: אבחון, סכימה, רפליקציה, בדיקה

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

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

מה מוסרים לידיים: תצורות, סכימות, נהלים

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

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

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

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

לפני: כל תקלה העירה את התורן

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

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

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

אחרי: מעבר בתוך עשרות שניות

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

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

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

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

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

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

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

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

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

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

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

לשם מה דרוש בורר בקלאסטר?

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

כיצד להשתכנע שהמעבר יעבוד?

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

האם הרפליקה מחליפה גיבוי?

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

כמה השבתה תופסות עבודות מתוכננות?

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

נדון במשימה: סכימה, לוחות זמנים, תוכנית יישום

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

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

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