‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

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

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

הדרישות שלכם לזמינות גבוהה (HA)

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

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

איך פועלת זמינות גבוהה (HA)

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

רפליקציה בסטרימינג

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

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

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

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

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

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

‫local: רפליקות המתנה סינכרוניות לא מעורבות באישור ה-commit. השרת הראשי מאשר את ביצוע העסקאות אחרי שרשומות ה-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, שמציינת את רשימת שרתי הגיבוי שמשתתפים בתהליך השכפול הסינכרוני. אם לא צוינו שמות של המתנה סינכרונית, אישורי העסקאות לא ממתינים לרפליקציה.

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

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

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

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

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

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

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

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

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

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

איור 1. תרשים של הרכיבים העיקריים באשכול Patroni.

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

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

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

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

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

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

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

זיהוי כשלים

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

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

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

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

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

תהליך יתירות כשל

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תהליך הגיבוי

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

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

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

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

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

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

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

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

באיור 6 מוצגת ארכיטקטורה של pg_auto_failover שמורכבת משני רכיבים עיקריים: שירות המעקב וסוכן ה-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.