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

המסמך הזה מיועד לאדמינים של מסדי נתונים, לארכיטקטים של ענן ולמהנדסי 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, שכפול לוגי של סטרימינג דורש הגדרה מיוחדת להגדרה של זמינות גבוהה. במדריך הזה נדון בשכפול פיזי רגיל, ולא בשכפול לוגי.
זמן פעולה תקינה: אחוז הזמן שבו מקור מידע פועל ויכול לספק תגובה לבקשה.
זיהוי כשלים: התהליך של זיהוי כשל בתשתית.
יתירות כשל: התהליך של קידום תשתית הגיבוי או ההמתנה (במקרה הזה, צומת השכפול) כדי שתהפוך לתשתית הראשית. במהלך מעבר לגיבוי, צומת העותק הופך לצומת הראשי.
מעבר: התהליך של הפעלת מעבר ידני לגיבוי במערכת ייצור. החלפה בין צמתים בודקת אם המערכת פועלת בצורה תקינה, או מוציאה את הצומת הראשי הנוכחי מהאשכול לצורך תחזוקה.
יעד משך ההתאוששות (RTO): משך הזמן שחלף, בזמן אמת, עד לסיום תהליך המעבר לגיבוי (failover) של שכבת הנתונים. ה-RTO תלוי בכמות הזמן שמקובלת מנקודת מבט עסקית.
יעד להתאוששות מאסון (RPO): כמות אובדן הנתונים (בזמן אמת שחלף) שרמת הנתונים יכולה לשמור כתוצאה מיתירות כשל. ה-RPO תלוי בכמות אובדן הנתונים שמקובלת מנקודת מבט עסקית.
חלופי: התהליך של החזרת הצומת הראשי הקודם אחרי שהתנאי שגרם למעבר לגיבוי (failover) תוקן.
תיקון עצמי: היכולת של מערכת לפתור בעיות בלי פעולות חיצוניות של מפעיל אנושי.
חלוקת רשת למחיצות: מצב שבו שני צמתים בארכיטקטורה – למשל הצומת הראשי והצומת המשוכפל – לא יכולים לתקשר אחד עם השני ברשת.
מוח חצוי: מצב שמתרחש כששני צמתים מאמינים בו-זמנית שהם הצומת הראשי.
קבוצת צמתים: קבוצה של משאבי מחשוב שמספקים שירות. במסמך הזה, השירות הזה הוא שכבת שימור הנתונים.
צומת עדים או צומת קוורום: משאב נפרד של מחשוב שעוזר לקבוצת צמתים לקבוע מה לעשות כשמתרחש מצב של פיצול מוח.
בחירות ראשיות או בחירות למנהיגות: התהליך שבו קבוצה של צמתים עם מודעות לעמיתים, כולל צמתים של עדים, קובעת איזה צומת צריך להיות הצומת הראשי.

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

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

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

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

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

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

איך HA עובד

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

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

שכפול סטרימינג הוא גישה לשכפול שבה העותק מתחבר למקור ומקבל באופן רציף זרם של רשומות WAL. בהשוואה לשכפול של יומני רישום, שכפול של נתונים בזמן אמת מאפשר לשכפול להישאר מעודכן יותר ביחס למקור. ‫PostgreSQL מציע שכפול סטרימינג מובנה החל מגרסה 9. פתרונות רבים של HA ב-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) אחר.

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

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

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

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

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

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

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

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

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

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

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

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

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

נקודת קצה של 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.