ארכיטקטורות לזמינות גבוהה של אשכולות PostgreSQL ב-Compute Engine

Last reviewed 2024-12-03 UTC

במאמר הזה מתוארות כמה ארכיטקטורות שמספקות זמינות גבוהה (HA) לפריסות של PostgreSQL ב- Google Cloud. זמינות גבוהה היא מדד לחוסן של המערכת בתגובה לכשל בתשתית הבסיסית. במסמך הזה, המונח HA מתייחס לזמינות של אשכולות PostgreSQL בתוך אזור יחיד בענן או בין כמה אזורים, בהתאם לארכיטקטורת ה-HA.

המסמך הזה מיועד לאדמינים של מסדי נתונים, לארכיטקטים של ענן ולמהנדסי DevOps שרוצים ללמוד איך לשפר את האמינות של רמת הנתונים ב-PostgreSQL על ידי שיפור זמן הפעולה הכולל של המערכת. במאמר הזה נסביר על מושגים שרלוונטיים להרצת PostgreSQL ב-Compute Engine. במאמר לא מוסבר איך להשתמש במסדי נתונים מנוהלים כמו Cloud SQL ל-PostgreSQL ו-AlloyDB ל-PostgreSQL.

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

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

במסמך הזה מפורטים הנושאים הבאים:

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

הסברים על המונחים

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

רפליקציה: התהליך שבו טרנזקציות של כתיבה (INSERT,‏ UPDATE או DELETE) ושינויים בסכימה (שפת הגדרת נתונים (DDL)) מתועדים באופן מהימן, נרשמים ביומן ולאחר מכן מוחלים באופן סדרתי על כל הצמתים של העותקים המשוכפלים של מסד הנתונים במורד הזרם בארכיטקטורה.
צומת ראשי: הצומת שמספק קריאה עם המצב העדכני ביותר של נתונים שנשמרו. כל פעולות הכתיבה במסד הנתונים צריכות להיות מופנות לצומת ראשי.
צומת רפליקה (משני): עותק אונליין של צומת מסד הנתונים הראשי. השינויים משוכפלים באופן סינכרוני או אסינכרוני לצמתי העתקים מצומת ראשי. אפשר לקרוא מתוך צמתי רפליקה, אבל צריך להבין שהנתונים עשויים להתעדכן באיחור קל בגלל פרק הזמן מהחשיפה להמרה.
פרק הזמן שחלף מאז השכפול: מדידה, במספר רצף יומן (LSN), במזהה עסקה או בזמן. העיכוב בשכפול מבטא את ההבדל בין המועד שבו פעולות שינוי מוחלות על הרפליקה לבין המועד שבו הן מוחלות על הצומת הראשי.
העברה רציפה לארכיון: גיבוי מצטבר שבו מסד הנתונים שומר ברציפות עסקאות עוקבות בקובץ.
יומן כתיבה מראש (WAL): יומן WAL הוא קובץ יומן שמתעד שינויים בקובצי נתונים לפני שהשינויים מבוצעים בפועל בקבצים. במקרה של קריסת שרת, WAL היא דרך סטנדרטית להבטיח את תקינות הנתונים ועמידות הכתיבות.
רשומת WAL: רשומה של עסקה שחלה על מסד הנתונים. רשומת WAL מעוצבת ומאוחסנת כסדרה של רשומות שמתארות שינויים ברמת הדף בקובץ הנתונים.
מספר סידורי ביומן (LSN): עסקאות יוצרות רשומות WAL שמצורפות לקובץ ה-WAL. המיקום שבו מתבצעת ההוספה נקרא מספר סידורי ביומן (LSN). זהו מספר שלם בן 64 ביט, שמיוצג כשני מספרים הקסדצימליים שמופרדים על ידי קו נטוי (XXXXXXXX/YYZZZZZZ). האות Z מייצגת את מיקום ההיסט בקובץ ה-WAL.
קבצים של פלחים: קבצים שמכילים כמה שיותר רשומות WAL, בהתאם לגודל הקובץ שהגדרתם. לשמות של קובצי פלחים יש עלייה מונוטונית, וגודל הקובץ המוגדר כברירת מחדל הוא 16MB.
שכפול סינכרוני: סוג של רפליקציה שבו השרת הראשי מחכה שהרפליקה תאשר שהנתונים נכתבו ב-transaction log של הרפליקה לפני שהוא מאשר את השמירה ללקוח. כשמריצים שכפול סטרימינג, אפשר להשתמש באפשרות synchronous_commit של PostgreSQL, שעוזרת להבטיח עקביות בין השרת הראשי לבין הרפליקה.
שכפול אסינכרוני: סוג של שכפול שבו השרת הראשי לא מחכה שהרפליקה תאשר שהטרנזקציה התקבלה בהצלחה לפני שהוא מאשר את השמירה ללקוח. ההשהיה בשכפול אסינכרוני נמוכה יותר בהשוואה לשכפול סינכרוני. עם זאת, אם השרת הראשי קורס והטרנזקציות שאושרו בו לא מועברות לרפליקה, יש סיכוי לאובדן נתונים. שכפול אסינכרוני הוא מצב השכפול שמוגדר כברירת מחדל ב-PostgreSQL, באמצעות העברת יומנים מבוססת-קובץ או שכפול סטרימינג.
העברת יומנים מבוססת-קבצים: שיטת רפליקציה ב-PostgreSQL שמעבירה את קובצי פלחי ה-WAL משרת מסד הנתונים הראשי אל הרפליקה. השרת הראשי פועל במצב ארכיון רציף, וכל שירות המתנה פועל במצב שחזור רציף כדי לקרוא את קובצי ה-WAL. סוג השכפול הזה הוא אסינכרוני.
רפליקציה של סטרימינג: שיטת רפליקציה שבה הרפליקה מתחברת למקור ומקבלת באופן רציף רצף של שינויים. העדכונים מגיעים דרך זרם, ולכן השיטה הזו מאפשרת לשמור על הרפליקה מעודכנת יותר בהשוואה לרפליקציה של יומני רישום. למרות שהשכפול הוא אסינכרוני כברירת מחדל, אפשר גם להגדיר שכפול סינכרוני.
שכפול פיזי של סטרימינג: שיטת שכפול שמעבירה שינויים לרפליקה. בשיטה הזו נעשה שימוש ברשומות WAL שמכילות את השינויים בנתונים הפיזיים בצורה של כתובות של בלוקים בדיסק ושינויים ברמת הבייט.
שכפול לוגי של סטרימינג: שיטת רפליקציה שמתעדת שינויים על סמך זהות הרפליקציה שלהם (מפתח ראשי), ומאפשרת יותר שליטה באופן הרפליקציה של הנתונים בהשוואה לרפליקציה פיזית. בגלל ההגבלות בשכפול לוגי ב-PostgreSQL, שכפול לוגי של סטרימינג דורש הגדרה מיוחדת עבור הגדרת זמינות גבוהה (HA). במדריך הזה נדון בשכפול פיזי רגיל, ולא בשכפול לוגי.
זמן פעולה תקינה: אחוז הזמן שבו מקור מידע פועל ויכול לספק תגובה לבקשה.
זיהוי כשלים: התהליך של זיהוי כשל בתשתית.
יתירות כשל: התהליך של העלאה בדרגה של תשתית הגיבוי או ההמתנה (במקרה הזה, צומת הרפליקה) כדי שתהפוך לתשתית הראשית. במהלך יתירות כשל, צומת הרפליקה הופך לצומת הראשי.
מעבר: תהליך ההפעלה של מעבר ידני לגיבוי במערכת ייצור. החלפה בין צמתים בודקת אם המערכת פועלת בצורה תקינה, או מוציאה את הצומת הראשי הנוכחי מהאשכול לצורך תחזוקה.
יעד משך ההתאוששות (RTO): המשך הזמן שחלף בזמן אמת עד להשלמת תהליך המעבר לגיבוי (failover) של שכבת הנתונים. RTO תלוי בכמות הזמן שמקובלת מנקודת מבט עסקית.
יעד להתאוששות מאסון (RPO): כמות אובדן הנתונים (בזמן אמת שחלף) שרמת הנתונים יכולה לשאת כתוצאה מיתירות כשל. ה-RPO תלוי בכמות אובדן הנתונים שמקובלת מנקודת מבט עסקית.
חלופי: התהליך של החזרת הצומת הראשי הקודם אחרי שהתנאי שגרם למעבר לגיבוי תוקן.
תיקון עצמי: היכולת של מערכת לפתור בעיות ללא פעולות חיצוניות של מפעיל אנושי.
חלוקת רשת למחיצות: תנאי שמתקיים כששני צמתים בארכיטקטורה – למשל הצומת הראשי והצומת המשוכפל – לא יכולים לתקשר אחד עם השני ברשת.
מוח חצוי: מצב שמתרחש כששני צמתים מאמינים בו-זמנית שהם הצומת הראשי.
קבוצת צמתים: קבוצה של משאבי מחשוב שמספקים שירות. במסמך הזה, השירות הזה הוא רמת שימור הנתונים.
צומת עדים או צומת קוורום: משאב נפרד של מחשוב שעוזר לקבוצת צמתים לקבוע מה לעשות כשמתרחש מצב של פיצול מוח.
בחירות מקדימות או בחירות לראשות המפלגה: התהליך שבו קבוצה של צמתים עם מודעות לעמיתים, כולל צמתים של עדים, קובעת איזה צומת צריך להיות הצומת הראשי.

מתי כדאי לשקול ארכיטקטורת HA

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

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

הגדרת הדרישות לזמינות גבוהה

הנה כמה שאלות שיעזרו לכם להחליט איזו אפשרות של PostgreSQL HA הכי מתאימה לעסק שלכם:

מהי רמת הזמינות שאתם רוצים להשיג? האם נדרשת לך אפשרות שתאפשר לשירות שלך להמשיך לפעול רק במהלך אזור יחיד או כשל אזורי מלא? חלק מהאפשרויות לזמינות גבוהה מוגבלות לאזור מסוים, ואחרות יכולות להיות במספר אזורים.
אילו שירותים או לקוחות מסתמכים על רמת הנתונים שלכם, ומה העלות לעסק שלכם אם יש זמן השבתה ברמת הנתונים? אם שירות מיועד רק ללקוחות פנימיים שצריכים להשתמש במערכת מדי פעם, סביר להניח שדרישות הזמינות שלו נמוכות יותר מאלה של שירות שפונה ללקוחות קצה ומשרת אותם באופן רציף.
מה התקציב התפעולי שלך? העלות היא שיקול חשוב: כדי לספק זמינות גבוהה, סביר להניח שהעלויות של התשתית והאחסון יגדלו.
עד כמה התהליך צריך להיות אוטומטי, וכמה מהר צריך לבצע מעבר לגיבוי? (מהו ה-RTO שלך?) אפשרויות ה-HA משתנות בהתאם למהירות שבה המערכת יכולה לבצע יתירות כשל ולחזור להיות זמינה ללקוחות.
האם אתם יכולים להרשות לעצמכם לאבד נתונים כתוצאה ממעבר לגיבוי? (מהו ה-RPO שלך?) בגלל האופי המבוזר של טופולוגיות HA, יש פשרה בין זמן האחזור של ביצוע פעולות (commit) לבין הסיכון לאובדן נתונים בגלל כשל.

איך HA עובד

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

שכפול בסטרימינג

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

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

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

שכפול סינכרוני של סטרימינג

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

אפשרות ההגדרה synchronous_commit מאפשרת גם להגדיר את רמות העמידות המתקדמות הבאות של הרפליקה עבור העסקה:

‫local: רפליקות במצב המתנה סינכרוני לא מעורבות באישור של ביצוע הפעולה. השרת הראשי מאשר את ביצוע העסקאות אחרי שרשומות ה-WAL נכתבות ומועברות לדיסק המקומי שלו. התחייבויות לעסקאות בשרת הראשי לא כוללות רפליקות במצב המתנה. עסקאות עלולות להיכשל אם יש כשל בשרת הראשי.
‫on [ברירת מחדל]: העתקים משניים במצב המתנה סינכרוני כותבים את העסקאות שאושרו ב-WAL שלהם לפני שהם שולחים אישור לעותק הראשי. השימוש בהגדרה on מבטיח שהעסקה תאבד רק אם העותק הראשי וכל העותקים הסינכרוניים של הגיבוי יסבלו מכשלים בו-זמניים באחסון. השכפולים שולחים אישור רק אחרי שהם כותבים רשומות WAL, ולכן לקוחות שמבצעים שאילתות בשכפול לא יראו שינויים עד שהרשומות המתאימות של WAL יוחלו על מסד הנתונים של השכפול.
‫remote_write: עותקים משוכפלים במצב המתנה סינכרוני מאשרים את קבלת רשומת ה-WAL ברמת מערכת ההפעלה, אבל הם לא מבטיחים שרשומת ה-WAL נכתבה לדיסק. מכיוון שהפונקציה remote_write לא מבטיחה שה-WAL נכתב, יכול להיות שהטרנזקציה תאבד אם תהיה תקלה גם בשרת הראשי וגם בשרת המשני לפני שהרשומות ייכתבו. remote_write הוא בעל עמידות נמוכה יותר בהשוואה לאפשרות on.
‫remote_apply: רפליקות במצב המתנה סינכרוני מאשרות את קבלת העסקה ואת ההחלה שלה על מסד הנתונים לפני שהן מאשרות את ביצוע העסקה ללקוח. השימוש בהגדרה remote_apply מבטיח שהעסקה תישמר ברפליקה, ושתוצאות השאילתות של הלקוח יכללו באופן מיידי את ההשפעות של העסקה. ‫remote_apply מספק עמידות ועקביות גבוהות יותר בהשוואה ל-on ול-remote_write.

אפשרות ההגדרה synchronous_commit פועלת עם אפשרות ההגדרה synchronous_standby_names שמציינת את רשימת השרתים במצב המתנה שמשתתפים בתהליך השכפול הסינכרוני. אם לא מציינים שמות של שרתים במצב המתנה סינכרוני, אישור העסקאות לא מתבצע עד שהשכפול מסתיים.

ארכיטקטורות של HA ב-PostgreSQL

ברמה הבסיסית ביותר, זמינות גבוהה של שכבת הנתונים מורכבת מהרכיבים הבאים:

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

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

תבנית Patroni
תוסף ושירות pg_auto_failover
קבוצות MIG עם שמירת מצב ודיסקים לאחסון מתמיד אזורי

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

היבט קריטי בארכיטקטורת HA הוא הזמן והמאמץ הידני שנדרשים כדי להכין סביבת המתנה חדשה למעבר גיבוי או למעבר חזרה. אחרת, המערכת יכולה לעמוד רק בכשל אחד, והשירות לא מוגן מפני הפרה של הסכם רמת השירות. מומלץ לבחור בארכיטקטורת HA שיכולה לבצע מעבר ידני לגיבוי (failover) או מעבר חזרה (switchover) עם תשתית הייצור.

זמינות גבוהה באמצעות תבנית Patroni

‫Patroni הוא תבנית תוכנה בוגרת בקוד פתוח (עם רישיון MIT) שמתוחזקת באופן פעיל. התבנית מספקת כלים להגדרה, לפריסה ולהפעלה של ארכיטקטורת HA של PostgreSQL. ‫Patroni מספק מצב אשכול משותף והגדרת ארכיטקטורה שנשמרים בחנות הגדרות מבוזרת (DCS). אפשרויות להטמעה של DCS כוללות את: etcd, Consul, Apache ZooKeeper, או Kubernetes. בתרשים הבא מוצגים הרכיבים העיקריים של אשכול Patroni.

ב-Patroni cluster יש אינטראקציה בין צמתי PostgreSQL,‏ DCS וסוכני Patroni.

איור 1. דיאגרמה של הרכיבים העיקריים באשכול Patroni.

באיור 1, מאזני העומסים נמצאים מול הצמתים של PostgreSQL, והסוכנים של DCS ו-Patroni פועלים בצמתים של PostgreSQL.

‫Patroni מריץ תהליך של סוכן בכל צומת PostgreSQL. תהליך הסוכן מנהל את תהליך PostgreSQL ואת ההגדרה של צומת הנתונים. סוכן Patroni מתאם עם צמתים אחרים דרך DCS. תהליך הסוכן של Patroni חושף גם API בארכיטקטורת REST שאפשר לשלוח אליו שאילתות כדי לקבוע את תקינות השירות של PostgreSQL ואת ההגדרה של כל צומת.

כדי לאשר את תפקיד החברות באשכול, הצומת הראשי מעדכן באופן קבוע את מפתח ה-leader ב-DCS. מפתח המנהיג כולל אורך חיים (TTL). אם הזמן שמוגדר ל-TTL חולף בלי עדכון, מפתח ה-leader מוצא מה-DCS, ותהליך בחירת ה-leader מתחיל כדי לבחור מפתח ראשי חדש ממאגר המועמדים.

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

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

איור 2. תרשים של אשכול תקין.

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

זיהוי כשלים

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

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

איור 3. דיאגרמה של אשכול פגום.

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

במארחי Linux, ‏ Patroni מפעיל גם כלב שמירה ברמת מערכת ההפעלה בצמתים ראשיים. טיימר מפקח (watchdog) זה מאזין להודעות keep-alive מתהליך הסוכן של Patroni. אם התהליך לא מגיב והאות 'פעיל' לא נשלח, מנגנון ה-watchdog מפעיל מחדש את המארח. ה-watchdog עוזר למנוע מצב של פיצול מוח, שבו צומת PostgreSQL ממשיך לשמש כצומת ראשי, אבל מפתח ה-leader ב-DCS פג בגלל כשל בסוכן, ונבחר צומת ראשי (leader) אחר.

תהליך המעבר לגיבוי

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

במהלך תהליך המעבר לגיבוי בעת כשל של Patroni, הרפליקות בודקות את המיקום שלהן ביומן WAL.

איור 4. תרשים של תהליך המעבר לגיבוי ב-Patroni.

איור 4 מציג שאילתות של מיקום ביומן WAL ותוצאות מתאימות מצמתי העתק פעילים. צומת א' לא זמין, והצמתים התקינים ב' ו-ג' מחזירים זה לזה את אותו מיקום WAL.

הצומת (או הצמתים, אם הם באותו מיקום) הכי עדכני מנסה בו-זמנית לקבל את נעילת ה-leader ב-DCS. עם זאת, רק צומת אחד יכול ליצור את מפתח המנהל ב-DCS. הצומת הראשון שיצליח ליצור את מפתח המנהיג הוא המנצח במירוץ למנהיגות, כפי שמוצג בתרשים הבא. אפשרות אחרת היא להגדיר מועמדים מועדפים ליתירות כשל על ידי הגדרת התג failover_priority בקובצי התצורה.

צומת יוצר מפתח מוביל ב-DCS והופך לראשי החדש.

איור 5. דיאגרמה של המירוץ לראשות הטבלה.

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

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

‫Patroni מספק גם את כלי הבקרה patronictl שמאפשר להריץ מעברים כדי לבדוק את תהליך יתירות הכשל של הצמתים. הכלי הזה עוזר למפעילים לבדוק את הגדרות ה-HA שלהם בסביבת ייצור.

ניתוב שאילתות

תהליך הסוכן של Patroni שפועל בכל צומת חושף נקודות קצה ל-API בארכיטקטורת REST שמגלות את התפקיד הנוכחי של הצומת: ראשי או רפליקה.

נקודת קצה של REST	קוד החזרה של HTTP אם הוא ראשי	קוד החזרה של HTTP אם מדובר ברפליקה
`/primary`	`200`	`503`
`/replica`	`503`	`200`

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

תהליך חלופי

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

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

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

זמינות גבוהה באמצעות התוסף והשירות pg_auto_failover

‫pg_auto_failover הוא תוסף PostgreSQL בקוד פתוח (רישיון PostgreSQL) שנמצא בפיתוח פעיל. התוסף pg_auto_failover מגדיר ארכיטקטורת זמינות גבוהה על ידי הרחבת היכולות הקיימות של PostgreSQL. ל-pg_auto_failover אין תלות בשום דבר מלבד PostgreSQL.

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

ארכיטקטורת pg_auto_failover מכילה מבנה של צמתים.

איור 6. תרשים של ארכיטקטורת pg_auto_failover.

באיור 6 מוצגת ארכיטקטורה של pg_auto_failover שמורכבת משני רכיבים עיקריים: שירות Monitor וסוכן Keeper. הכלי Keeper והכלי Monitor כלולים בתוסף pg_auto_failover.

שירות מעקב

שירות המעקב pg_auto_failover מיושם כתוסף PostgreSQL. כשהשירות יוצר צומת מעקב, הוא מפעיל מופע PostgreSQL עם התוסף pg_auto_failover. השירות Monitor שומר על המצב הגלובלי של הקבוצה, מקבל את סטטוס בדיקת התקינות מצמתי הנתונים של PostgreSQL, ומנהל את הקבוצה באמצעות הכללים שנקבעו על ידי מכונת מצבים סופית (FSM). בהתאם לכללי ה-FSM למעברים בין מצבים, הצומת Monitor מעביר הוראות לצמתי הקבוצה לפעולות כמו קידום, הורדה בדרגה ושינויים בהגדרות.

סוכן Keeper

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

כברירת מחדל, pg_auto_failover מגדיר את כל צמתי הנתונים המשניים בקבוצה כרפליקות סינכרוניות. מספר העותקים הסינכרוניים שנדרשים לביצוע commit מבוסס על ההגדרה number_sync_standby שקבעתם ב-Monitor.