Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

Last reviewed 2024-12-03 UTC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

איך HA עובד

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

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

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

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

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

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

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

אפשרות ההגדרה 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

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

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

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

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

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

היבט קריטי בארכיטקטורת HA הוא הזמן והמאמץ הידני שנדרשים כדי להכין סביבת המתנה חדשה למעבר גיבוי או חזרה לגיבוי. אחרת, המערכת יכולה לעמוד רק בכשל אחד, והשירות לא מוגן מפני הפרה של הסכם רמת השירות (SLA). מומלץ לבחור ארכיטקטורת 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. מפתח ה-leader כולל זמן חיים (TTL). אם ה-TTL מסתיים בלי עדכון, מפתח ה-leader מוצא מה-DCS, והבחירות ל-leader מתחילות כדי לבחור צומת ראשי חדש מתוך מאגר המועמדים.

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

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

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

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

זיהוי כשלים

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

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

איור 3. תרשים של אשכול פגום.

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

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

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

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

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

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

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

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

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

איור 5. תרשים של המירוץ לראשות הממשלה.

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

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

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

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

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

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

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

תהליך חלופי

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

לדוגמה, יכול להיות שצומת יופעל מחדש בגלל כשל במערכת ההפעלה או בתשתית הבסיסית. אם הצומת הוא הראשי וההפעלה מחדש שלו נמשכת יותר זמן מה-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 עם ארכיטקטורת זמינות גבוהה, צריך לפחות שלושה צמתים, שכל אחד מהם מריץ את 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.