מבוא

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

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

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

אשכולות פרוסים על מכונות וירטואליות VirtualBox. בסך הכל ייפרסו 12 מכונות וירטואליות (36GiB בסך הכל), אשר יוצרות 4 אשכולות סובלני תקלות (אפשרויות שונות). שני האשכולות הראשונים מורכבים משני שרתי PostgreSQL, הממוקמים במרכזי נתונים שונים, ושרת משותף עד c מכשיר מניין (מתארח במכונה וירטואלית זולה במרכז נתונים שלישי), מה שפותר אי ודאות 50% / 50%, מתן קולך לאחת המפלגות. אשכול שלישי בשלושה מרכזי נתונים: מאסטר אחד, שני עבדים, לא מכשיר מניין. האשכול הרביעי מורכב מארבעה שרתי PostgreSQL, שניים לכל מרכז נתונים: מאסטר אחד, השאר העתקים, וגם משתמש עד c מכשיר מניין. הרביעי יכול לעמוד בכשל של שני שרתים או מרכז נתונים אחד. ניתן להגדיל את הפתרון הזה למספר גדול יותר של העתקים במידת הצורך.

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

גרסאות

v0. עובד עם CentOS 7 ו- PostgreSQL 11 ב- VirtualBox 6.1.

מבנה אשכול

כל האשכולות מתוכננים להיות ממוקמים במספר מרכזי נתונים, משולבים לרשת שטוחה אחת וחייבים לעמוד בכשל או בידוד רשת של מרכז נתונים בודד. בגלל זה הוא בלתי אפשרי להשתמש להגנה מפני מוח מפוצל טכנולוגיית קוצב לב סטנדרטית הנקראת סטונית (תירה בצומת האחר בראש) או סיוף. המהות שלו: אם הצמתים באשכול מתחילים לחשוד שמשהו לא בסדר בצומת כלשהו, ​​הוא לא מגיב או מתנהג בצורה לא נכונה, אז הם מכבים אותו בכוח באמצעות מכשירים "חיצוניים", למשל, כרטיס בקרה IPMI או UPS . אבל זה יעבוד רק במקרים שבהם, במקרה של תקלה בודדת, שרת ה-IPMI או UPS ימשיכו לעבוד. כאן אנו מתכננים להגן מפני תקלה הרבה יותר קטסטרופלית, כאשר מרכז הנתונים כולו נכשל (למשל, מאבד חשמל). ועם סירוב כזה, הכל סטוניתגם התקנים (IPMI, UPS וכו') לא יעבדו.

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

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

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

Tuchanka1 (מעגל עם דחיסה)

מבנה

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

לכל מרכז נתונים יש שרת אחד. לכל שרת יש שני מופעי PostgreSQL (במינוח של PostgreSQL הם נקראים clusters, אבל כדי למנוע בלבול אקרא להם מופעים (באנלוגיה למאגרי מידע אחרים), ואקרא רק Pacemaker clusters clusters). מופע אחד פועל במצב מאסטר, ורק הוא מספק שירותים (רק IP Float מוביל אליו). המופע השני עובד כעבד עבור מרכז הנתונים השני, ויספק שירותים רק אם המאסטר שלו נכשל. מכיוון שלרוב רק מופע אחד מתוך שניים (המאסטר) יספק שירותים (לבצע בקשות), כל משאבי השרת מותאמים למאסטר (הזיכרון מוקצה למטמון shared_buffers וכו'), אך כך שהמופע השני יש גם מספיק משאבים (אם כי לפעולה לא אופטימלית דרך מטמון מערכת הקבצים) במקרה של כשל של אחד ממרכזי הנתונים. העבד לא מספק שירותים (אינו מבצע בקשות לקריאה בלבד) במהלך פעולה רגילה של האשכול, כך שאין מלחמה על משאבים עם המאסטר באותה מכונה.

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

אי עדות

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

סירוב Tuchanka1

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

Tuchanka2 (קלאסי)

מבנה

סכימה קלאסית של שני צמתים. האדון עובד על אחד, העבד על השני. שניהם יכולים לבצע בקשות (העבד הוא לקריאה בלבד), כך ששתיהן מצביעות על ידי צף IP: krogan2 הוא המאסטר, krogan2s1 הוא העבד. גם לאדון וגם לעבד יהיו סובלנות לתקלות.

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

סירוב Tuchanka2

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

Tuchanka4 (עבדים רבים)

מבנה

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

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

סירוב Tuchanka4

אם מרכז נתונים אחד (כלומר שני שרתים) נכשל, העדים יצביעו עבור השני. כתוצאה מכך, ישנם שני שרתים הפועלים במרכז הנתונים השני: האחד מפעיל מאסטר, וה-Master float IP מצביע אליו (לקבלת בקשות קריאה-כתיבה); ובשרת השני יש עבד רץ עם שכפול סינכרוני, ואחד מה-slave float IPs מצביע עליו (עבור בקשות לקריאה בלבד).

הדבר הראשון שיש לציין הוא שלא כל כתובות ה-IP של העבדים יהיו עובדים, אלא רק אחד. וכדי לעבוד עם זה נכון יהיה צורך בכך sql proxy הפנה מחדש את כל הבקשות ל-IP הצף היחיד שנותר; ואם sql proxy לא, אז אתה יכול לרשום את כל עבדי ה-IP הצפים מופרדים בפסיקים בכתובת ה-URL של החיבור. במקרה זה, עם libpq החיבור יהיה ל-IP הראשון הפועל, זה נעשה במערכת הבדיקה האוטומטית. אולי בספריות אחרות, למשל, JDBC, זה לא יעבוד והכרחי sql proxy. הדבר נעשה מכיוון שאסור להעלות כתובות IP לצוף עבור עבדים בו זמנית בשרת אחד, כך שהם מחולקים באופן שווה בין שרתי עבדים אם יש כמה מהם פועלים.

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

Tuchanka3 (3 מרכזי נתונים)

מבנה

זהו אשכול למצב בו ישנם שלושה מרכזי נתונים הפועלים במלואם, שלכל אחד מהם יש שרת מסד נתונים הפועל במלואו. במקרה הזה מכשיר מניין לא נחוץ. מרכז נתונים אחד מאויש על ידי מאסטר, השניים האחרים מאוישים על ידי עבדים. השכפול הוא סינכרוני, הקלד ANY (slave1, slave2), כלומר, הלקוח יקבל אישור התחייבות כאשר מישהו מהעבדים הוא הראשון להגיב שהוא קיבל את ההתחייבות. משאבים מסומנים באמצעות IP צף אחד עבור המאסטר ושניים עבור עבדים. שלא כמו Tuchanka4, כל שלושת כתובות ה-IP הצפות עמידות בפני תקלות. כדי לאזן שאילתות SQL לקריאה בלבד אתה יכול להשתמש sql proxy (עם סובלנות תקלות נפרדת), או הקצה IP float עבד אחד למחצית מהלקוחות, והחצי השני לשני.

סירוב Tuchanka3

אם אחד ממרכזי הנתונים נכשל, שניים נשארים. באחד, ה-Master וה-Float IP מהמאסטר מועלים, בשני - ה-slave ו-slave float IPs (למופע חייב להיות רזרבה כפולה של משאבים כדי לקבל את כל החיבורים משני ה-slave float IPs). שכפול סינכרוני בין אדונים ועבדים. כמו כן, האשכול ישמור מידע על עסקאות מחויבות ואושרו (לא יהיה אובדן מידע) במקרה של הרס של שני מרכזי נתונים (אם הם לא יהרסו בו זמנית).

החלטתי לא לכלול תיאור מפורט של מבנה הקובץ והפריסה. כל מי שרוצה לשחק יכול לקרוא הכל ב-README. אני מספק רק תיאור של בדיקות אוטומטיות.

מערכת בדיקה אוטומטית

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

test/failure 2 3

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

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

1. סטטיסטיקת בדיקות מוצגת כאן. עמודות:
   • כישלון - שם הבדיקה (פונקציה בסקריפט) שמחקה את התקלה.
   • תגובה - זמן ממוצע אריתמטי בשניות שבמהלכן האשכול שיחזר את הפונקציונליות שלו. הוא נמדד מתחילת הסקריפט המחקה תקלה ועד לרגע שבו האשכול משחזר את הפונקציונליות שלו ומסוגל להמשיך לספק שירותים. אם הזמן קצר מאוד, למשל, שש שניות (זה קורה באשכולות עם מספר עבדים (Tuchanka3 ו- Tuchanka4)), זה אומר שהתקלה הייתה בעבד האסינכרוני ולא השפיעה בשום צורה על הביצועים; לא היו מתגי מצב אשכול.
   • סטייה - מציג את התפשטות (דיוק) של הערך תגובה בשיטת סטיית התקן.
   • לספור - כמה פעמים בוצעה בדיקה זו.
2. יומן קצר מאפשר לך להעריך מה האשכול עושה כרגע. מוצגים מספר האיטרציה (בדיקה), חותמת הזמן ושם הפעולה. ריצה ארוכה מדי (> 5 דקות) מעידה על בעיה.
3. לֵב (לב) - שעה נוכחית. להערכה ויזואלית של ביצועים אדונים השעה הנוכחית נכתבת כל הזמן לטבלה שלו באמצעות מאסטר ה-IP float. אם זה מצליח, התוצאה מוצגת בחלונית זו.
4. להיות ב (דופק) - "זמן נוכחי", שהוקלט בעבר על ידי התסריט לֵב לשלוט, עכשיו קרא מ עבד דרך ה-IP הצף שלו. מאפשר לך להעריך חזותית את הביצועים של העבד והשכפול. ב- Tuchanka1 אין עבדים עם IP Float (אין עבדים המספקים שירותים), אבל יש שני מופעים (DBs), אז זה לא יוצג כאן להיות בו - לֵב מקרה שני.
5. ניטור תקינות האשכולות באמצעות כלי השירות pcs mon. מציג את המבנה, התפלגות המשאבים על פני צמתים ומידע שימושי אחר.
6. ניטור מערכת מכל מכונה וירטואלית באשכול מוצג כאן. ייתכן שיהיו עוד פאנלים כאלה תלוי בכמה מכונות וירטואליות יש לאשכול. שני גרפים עומס מעבד (למכונות וירטואליות יש שני מעבדים), שם מכונה וירטואלית, טען מערכת (הנקרא Load Average מכיוון שהוא נמצא בממוצע על פני 5, 10 ו-15 דקות), נתוני תהליך והקצאת זיכרון.
7. מעקב אחר הסקריפט המבצע בדיקה. במקרה של תקלה – הפסקה פתאומית בפעולה או מחזור המתנה אינסופי – כאן תוכלו לראות את הסיבה להתנהגות זו.

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

כל מבחן מורכב מהפעולות הבאות:

1. הפעל פונקציה שמחקה תקלה.
2. מוכן? - המתנה לשחזור האשכול (כאשר כל השירותים מסופקים).
3. מציג את פסק הזמן של שחזור האשכול (תגובה).
4. לסדר - האשכול נמצא ב"תיקון". לאחר מכן הוא אמור לחזור למצב תפעולי מלא ולהיות מוכן לתקלה הבאה.

להלן רשימה של מבחנים עם תיאור של מה שהם עושים:

• ForkBomb: יוצר "מחוץ לזיכרון" באמצעות פצצת מזלג.
• מחוץ לחלל: הכונן הקשיח מלא. אבל הבדיקה היא סמלית למדי; עם העומס הלא משמעותי שנוצר במהלך הבדיקה, PostgreSQL בדרך כלל לא נכשל כאשר הכונן הקשיח מלא.
• Postgres-KILL: הורג את PostgreSQL עם הפקודה killall -KILL postgres.
• Postgres-STOP: תלוי בפקודת PostgreSQL killall -STOP postgres.
• פאוורוף: "מוציא מהאנרגיה" את המכונה הוירטואלית עם הפקודה VBoxManage controlvm "виртуалка" poweroff.
• לאפס: מעמיס על המחשב הוירטואלי בפקודה VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: משעה את שד SBD עם הפקודה killall -STOP sbd.
• כיבוי: שולח פקודה למכונה הוירטואלית באמצעות SSH systemctl poweroff, המערכת נסגרת בחן.
• בטל קישור: בידוד רשת, פקודה VBoxManage controlvm "виртуалка" setlinkstate1 off.

השלמת בדיקה באמצעות פקודת tmux הסטנדרטית "kill-window" Ctrl-b &, או הפקודה "ניתוק-לקוח". Ctrl-b ד: בשלב זה מסתיימת הבדיקה, tmux נסגרת, מכונות וירטואליות כבויות.

בעיות שזוהו במהלך הבדיקה

• כרגע כלב שמירה שד sbd עובד על עצירת דמונים שנצפו, אך לא הקפאתם. וכתוצאה מכך, תקלות המובילות להקפאה בלבד קורוסינק и קוצב לב, אבל לא תלוי SBD... לבדיקה קורוסינק כבר יש יחסי ציבור מס '83 (ב-GitHub ב- SBD), התקבל לשרשור אב. הם הבטיחו (ב-PR#83) שיהיה משהו דומה ל-Pacemaker, אני מקווה שעד RedHat 8 זה מה שאעשה. אבל "תקלות" כאלה הן ספקולטיביות וניתן לדמות אותן בקלות באופן מלאכותי באמצעות, למשל, killall -STOP corosync, אבל לעולם לא נפגשים בחיים האמיתיים.

• У קוצב לב בגרסה עבור CentOS 7 מוגדר בצורה לא נכונה sync_timeout у מכשיר מניין, כתוצאה אם צומת אחד נכשל, בסבירות מסוימת גם הצומת השני עלה מחדש, שאליו האדון היה אמור לעבור. נרפא על ידי הגדלה sync_timeout у מכשיר מניין במהלך הפריסה (בתסריט setup/setup1). תיקון זה לא התקבל על ידי היזמים קוצב לב, במקום זאת הם הבטיחו לתכנן מחדש את התשתית בצורה כזו (בעתיד לא מוגדר) שפסק הזמן הזה יחושב אוטומטית.

• אם תצורת מסד הנתונים מציינת זאת LC_MESSAGES (הודעות טקסט) ניתן להשתמש ב-Unicode, למשל. ru_RU.UTF-8, ואז בהפעלה postgres בסביבה שבה המקום אינו UTF-8, נניח בסביבה ריקה (כאן קוצב לב+pgsqlms(פאף) רץ postgres) אז היומן יכיל סימני שאלה במקום אותיות UTF-8. מפתחי PostgreSQL לא הסכימו מה לעשות במקרה זה. זה עולה, אתה צריך להתקין LC_MESSAGES=en_US.UTF-8 בעת הגדרת (יצירת) מופע מסד נתונים.

• אם wal_receiver_timeout מוגדר (כברירת מחדל זה 60s), אז במהלך מבחן PostgreSQL-STOP על המאסטר באשכולות tuchanka3 ו-tuchanka4 שכפול אינו מתחבר מחדש למאסטר החדש. השכפול שם הוא סינכרוני, כך שלא רק העבד עוצר, אלא גם המאסטר החדש. מעקף על ידי הגדרת wal_receiver_timeout=0 בעת הגדרת PostgreSQL.

• מדי פעם ראיתי הקפאת שכפול ב-PostgreSQL במבחן ForkBomb (הצפת זיכרון). לאחר ForkBomb, לפעמים עבדים עשויים שלא להתחבר מחדש למאסטר החדש. נתקלתי בזה רק באשכולות tuchanka3 ו-tuchanka4, שם המאסטר קפא עקב שכפול סינכרוני. הבעיה חלפה מעצמה לאחר זמן רב (כשעתיים). יש צורך במחקר נוסף כדי לתקן זאת. התסמינים דומים לבאג הקודם, שנגרם מסיבה אחרת, אך עם אותן השלכות.

תמונה של קרוגן נלקחה מ אמנות סוטה באישור המחבר:

מקור: www.habr.com