סיפורי כישלון של פטרוני או כיצד לקרוס את אשכול ה-PostgreSQL שלך. אלכסיי לסובסקי

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

אני אספר לך קצת על עצמי. התחלתי כמנהל מערכת. עבד בפיתוח אתרים. אני עובד ב-Data Egret משנת 2014. החברה עוסקת בייעוץ בתחום Postgres. ואנחנו משרתים בדיוק את Postgres, ואנחנו עובדים עם Postgres כל יום, כך שיש לנו מומחיות שונה הקשורה למבצע.

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

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

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

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

וכתב ויתור קטן לפני שנתחיל בדוח שלנו.

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

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

מה זה פטרוני?

• זוהי תבנית לבניית HA. זה מה שכתוב בתיעוד. ומנקודת המבט שלי זה הבהרה מאוד נכונה. פטרוני הוא לא כדור כסף שיפתור את כל הבעיות שלך, כלומר, אתה צריך להתאמץ כדי שזה יעבוד ויביא תועלת.
• זהו שירות סוכן שמותקן בכל שירות מסד נתונים ומהווה מעין מערכת init ל-Postgres שלך. זה מתחיל את Postgres, עוצר, מפעיל מחדש, מגדיר מחדש ומשנה את הטופולוגיה של האשכול שלך.
• בהתאם לכך, על מנת לאחסן את מצב האשכול, יש צורך בייצוג הנוכחי שלו, כפי שהוא נראה, אחסון כלשהו. ומנקודת מבט זו, פטרוני נקט בדרך של אחסון מצב במערכת חיצונית. זוהי מערכת אחסון בתצורה מבוזרת. זה יכול להיות Etcd, Consul, ZooKeeper, או kubernetes Etcd, כלומר אחת מהאפשרויות הללו.
• ואחת התכונות של Patroni היא שאתה מוציא את הפילטר האוטומטי מהקופסה, רק על ידי הגדרתו. אם ניקח את Repmgr להשוואה, הקובץ נכלל שם. עם Repmgr, אנחנו מקבלים מעבר, אבל אם אנחנו רוצים קובץ אוטומטי, אז אנחנו צריכים להגדיר אותו בנוסף. לפטרוני כבר יש סיקור אוטומטי מחוץ לקופסה.
• ויש עוד הרבה דברים. למשל תחזוקה של תצורות, יציקת העתקים חדשים, גיבוי וכו' אבל זה מעבר לתחום הדוח, לא אדבר על זה.

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

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

עלול להישבר:

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

את כל הנקודות הללו אתייחס בדוח.

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

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

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

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

אבל הקובץ לא תמיד מיידי, כלומר זה לא לוקח שום יחידת זמן, זה יכול להתעכב. זה יכול להחזיק מעמד לאורך זמן.

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

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

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

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

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

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

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

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

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

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

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

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

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

הבעיה השנייה דומה לראשונה. זה דומה בכך ששוב יש לנו בעיות יכולת פעולה הדדית עם מערכת DCS.

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

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

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

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

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

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

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

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

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

יש אפשרויות:

• האפשרות הפשוטה ביותר, שכתובה, לדעתי, אפילו בתיעוד, היא לבטל את בדיקות הקונסול, כלומר פשוט להעביר מערך ריק. ואנחנו אומרים לסוכן הקונסול לא להשתמש בצ'קים. בעזרת בדיקות אלו, נוכל להתעלם מסערות הרשת הללו ולא ליזום הגישור.
• אפשרות נוספת היא לבדוק פעמיים raft_multiplier. זהו פרמטר של שרת הקונסול עצמו. כברירת מחדל, הוא מוגדר ל-5. ערך זה מומלץ על ידי התיעוד עבור סביבות בימוי. למעשה, הדבר משפיע על תדירות העברת ההודעות בין חברי רשת קונסול. למעשה, פרמטר זה משפיע על מהירות תקשורת השירות בין חברי אשכול הקונסול. ולייצור, כבר מומלץ לצמצם אותו כך שהצמתים מחליפים הודעות בתדירות גבוהה יותר.
• אפשרות נוספת שהמצאנו היא להגביר את העדיפות של תהליכי Consul בין שאר התהליכים עבור מתזמן התהליכים של מערכת ההפעלה. יש פרמטר "נחמד" כזה, שהוא רק קובע את העדיפות של התהליכים שנלקחת בחשבון על ידי מתזמן מערכת ההפעלה בעת התזמון. הורדנו גם את הערך הנחמד עבור סוכני קונסול, כלומר. הגדילה את העדיפות כך שמערכת ההפעלה נותנת לתהליכי Consul יותר זמן לעבוד ולבצע את הקוד שלהם. במקרה שלנו, זה פתר את הבעיה שלנו.
• אפשרות נוספת היא לא להשתמש בקונסול. יש לי חבר שהוא תומך גדול של Etcd. ואנחנו מתווכחים איתו באופן קבוע מה עדיף וכו' או קונסול. אבל מבחינת מה עדיף, אנחנו בדרך כלל מסכימים איתו שלקונסול יש סוכן שאמור לרוץ בכל צומת עם מסד נתונים. כלומר, האינטראקציה של פטרוני עם אשכול הקונסול עוברת דרך הסוכן הזה. והסוכן הזה הופך לצוואר בקבוק. אם משהו יקרה לסוכן, אז פטרוני כבר לא יכול לעבוד עם אשכול הקונסול. וזו הבעיה. אין סוכן בתוכנית Etcd. Patroni יכול לעבוד ישירות עם רשימה של שרתי Etcd וכבר לתקשר איתם. בהקשר זה, אם אתה משתמש ב-Etcd בחברה שלך, אז Etcd כנראה תהיה בחירה טובה יותר מ-Consul. אבל אנחנו בלקוחות שלנו תמיד מוגבלים על ידי מה שהלקוח בחר ומשתמש בו. ויש לנו קונסול לרוב עבור כל הלקוחות.
• והנקודה האחרונה היא לשנות את ערכי הפרמטרים. אנו יכולים להעלות את הפרמטרים הללו בתקווה שבעיות הרשת לטווח הקצר שלנו יהיו קצרות ולא ייפלו מחוץ לטווח הפרמטרים הללו. בדרך זו נוכל להפחית את האגרסיביות של Patroni לקובץ אוטומטי אם מתרחשות בעיות רשת.

אני חושב שרבים המשתמשים בפטרוני מכירים את הפקודה הזו.

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

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

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

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

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

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

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

מהן האפשרויות?

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

אבל יש כאן בעיה, שכשהמאסטר הולך לרפליקה, הוא מוחק את החריצים ומוחק את מקטעי ה-WAL יחד עם החריצים. וכדי לבטל את הבעיה הזו, החלטנו להעלות את הפרמטר wal_keep_segments. ברירת המחדל היא 8 מקטעים. העלינו את זה ל-1 ובדקנו כמה מקום פנוי יש לנו. ותרמנו 000 גיגה-בייט עבור wal_keep_segments. כלומר, בעת המעבר, יש לנו תמיד רזרבה של 16 גיגה-בייט של יומני עסקאות בכל הצמתים.

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

יש לנו בסיס ייצור. יש כבר פרויקטים בתהליך.

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

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

ברור ש-pg_rewind פספס אותם. מיד הבנו את זה, אבל הלכנו לראות מה קורה.

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

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

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

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

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

אבל מה גילינו בעצמנו?

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

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

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

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

אבל יש בעיה בכך שהשהיית השכפול ב-Patroni cluster ו-DCS מתעדכנת במרווח מסוים. אני חושב ש-30 שניות הוא ערך ברירת המחדל של ttl.

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

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

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

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

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

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

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

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

בדקנו את מערכת dmesg (יומן הקרנל). וראינו שיש לנו בעיות עם אחד הדיסקים. תת-מערכת הדיסק הייתה תוכנת Raid. הסתכלנו על /proc/mdstat וראינו שחסר לנו כונן אחד. כלומר, יש Raid של 8 דיסקים, חסר לנו אחד. אם אתה מסתכל בקפידה על השקף, אז בפלט אתה יכול לראות שאין לנו sde שם. אצלנו, בתנאי, הדיסק ירד. זה גרם לבעיות בדיסק, ויישומים גם חוו בעיות בעבודה עם אשכול Postgres.

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

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

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

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

ואיך הכל התחיל? זה התחיל, כמו בבעיה הקודמת, עם בלמי דיסק. היו לנו מחויבות לשנייה, שתיים.

היו הפסקות בקשרים, כלומר, לקוחות נקרעו.

היו חסימות בדרגות חומרה שונות.

ובהתאם לכך, תת-מערכת הדיסק אינה מגיבה במיוחד.

והדבר הכי מסתורי עבורי הוא בקשת הכיבוי המיידי שהגיעה. ל-Postgres יש שלושה מצבי כיבוי:

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

מי שלח את האות הזה? תהליכי רקע Postgres לא שולחים אותות כאלה זה לזה, כלומר זה Kill-9. הם לא שולחים דברים כאלה אחד לשני, הם רק מגיבים לדברים כאלה, כלומר זה הפעלה מחדש חירום של Postgres. מי שלח את זה, אני לא יודע.

הסתכלתי על הפקודה "האחרונה" וראיתי אדם אחד שגם נכנס איתנו לשרת הזה, אבל התביישתי לשאול שאלה. אולי זה היה להרוג -9. הייתי רואה להרוג -9 ביומנים, כי Postgres אומר שנדרש להרוג -9, אבל לא ראיתי את זה ביומנים.

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

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

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

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

בשלב מסוים זה עבד, אבל השכפול לא התחיל.

הניחוש היחיד שלי הוא שהייתה כתובת מאסטר ישנה ב- recovery.conf. וכשהופיע מאסטר חדש, ההעתק השני עדיין ניסה להתחבר למאסטר הישן.

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

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

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

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

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

חשבתי להתחיל מחדש. הפעלתי מחדש את Patroni, ולא הפעלתי מחדש את Postgres, אלא הפעלתי מחדש את Patroni בתקווה שזה יתחיל בקסם את מסד הנתונים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ואיפה אנחנו מסתכלים בדרך כלל? אני מסתכל:

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

מה אני מרגיש לגבי פטרוני? יש לי קשר טוב מאוד עם פטרוני. לדעתי זה הכי טוב שיש היום. אני מכיר הרבה מוצרים אחרים. אלה הם Stolon, Repmgr, Pg_auto_failover, PAF. 4 כלים. ניסיתי את כולם. פטרוני הוא האהוב עליי.

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

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

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

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

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

זה הכל. אם יש לך שאלות, שאל.

שאלות

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

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

למשל, הלכנו בבוקר ובדקנו, נכון?

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

תודה לך!

תודה רבה על הסיפור הנהדר! אם העברנו את אשכול ה-DCS למקום רחוק מאשכול Postgres, אז גם האשכול הזה צריך לקבל שירות תקופתי? מהן השיטות המומלצות שיש לכבות חלקים של אשכול DCS, משהו לעשות איתם וכו'? איך כל המבנה הזה שורד? ואיך עושים את הדברים האלה?

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

כלומר, האם הבנתי נכון שאני צריך להשבית את פטרוני, להשבית את הקובץ, להשבית הכל לפני שאני עושה משהו עם המארחים?

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

תודה רבה!

תודה רבה על הדיווח שלך! איך צוות המוצר מרגיש לגבי אובדן נתונים?

לצוותי המוצר לא אכפת, וראשי הצוותים מודאגים.

אילו ערבויות יש?

ערבויות זה מאוד קשה. לאלכסנדר קוקושקין יש דוח "כיצד לחשב RPO ו-RTO", כלומר זמן התאוששות וכמה נתונים אנחנו יכולים לאבד. אני חושב שאנחנו צריכים למצוא את השקופיות האלה וללמוד אותן. עד כמה שאני זוכר, יש שלבים ספציפיים איך לחשב את הדברים האלה. כמה עסקאות אנחנו יכולים להפסיד, כמה נתונים אנחנו יכולים לאבד. כאופציה, אנחנו יכולים להשתמש בשכפול סינכרוני ברמת הפטרוני, אבל זו חרב פיפיות: או שיש לנו אמינות נתונים, או שאנחנו מאבדים מהירות. יש שכפול סינכרוני, אבל זה גם לא מבטיח 100% הגנה מפני אובדן נתונים.

אלכסיי, תודה על הדיווח הנהדר! יש ניסיון בשימוש בפטרוני להגנה ברמה אפסית? כלומר, בשילוב עם המתנה סינכרונית? זו השאלה הראשונה. והשאלה השנייה. השתמשת בפתרונות שונים. השתמשנו ב-Repmgr, אבל ללא autofiler, ועכשיו אנחנו מתכננים לכלול autofil. ואנחנו רואים בפטרוני פתרון חלופי. מה אתה יכול לומר כיתרונות בהשוואה ל-Repmgr?

השאלה הראשונה הייתה לגבי העתקים סינכרוניים. אף אחד לא משתמש כאן בשכפול סינכרוני, כי כולם מפחדים (כמה לקוחות כבר משתמשים בזה, באופן עקרוני, הם לא שמו לב לבעיות ביצועים - הערת הדובר). אבל פיתחנו לעצמנו כלל שצריכים להיות לפחות שלושה צמתים באשכול שכפול סינכרוני, כי אם יש לנו שני צמתים ואם המאסטר או העתק נכשלים, אז Patroni מעביר את הצומת הזה למצב Standalone כך שהאפליקציה תמשיך עֲבוֹדָה. במקרה זה, קיים סיכון לאובדן נתונים.

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

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

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

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

באופן גס, DCS הופך עבורנו לשירות חשוב כמו הבסיס עצמו?

כן כן. בכל כך הרבה חברות מודרניות, Service Discovery הוא חלק בלתי נפרד מהתשתית. זה מיושם עוד לפני שהיה בסיס נתונים בתשתית. באופן יחסי, התשתית הושקה, נפרסה ב-DC, ומיד יש לנו Service Discovery. אם זה קונסול, אז ניתן לבנות עליו DNS. אם זה Etcd, אז אולי יש חלק מאשכול Kubernetes, שבו כל השאר יתפרסו. נראה לי ש-Service Discovery הוא כבר חלק בלתי נפרד מתשתיות מודרניות. והם חושבים על זה הרבה יותר מוקדם מאשר על מסדי נתונים.

תודה לך!

מקור: www.habr.com