אשכול כשל PostgreSQL + פטרוני. ניסיון ביישום

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

יש לנו שירות טעון מאוד: 2,5 מיליון משתמשים ברחבי העולם, 50K+ משתמשים פעילים מדי יום. השרתים ממוקמים באמזון באזור אחד באירלנד: 100+ שרתים שונים עובדים כל הזמן, מתוכם כמעט 50 עם מסדי נתונים.

הקצה האחורי כולו הוא יישום Java stateful מונוליטי גדול ששומר על חיבור אינטרנט קבוע עם הלקוח. כאשר מספר משתמשים עובדים על אותו לוח בו זמנית, כולם רואים את השינויים בזמן אמת, כי אנחנו כותבים כל שינוי למסד הנתונים. יש לנו כ-10K בקשות בשנייה למאגרי המידע שלנו. בעומס שיא ברדיס, אנו כותבים 80-100K בקשות לשנייה.

מדוע עברנו מ-Redis ל-PostgreSQL

בתחילה, השירות שלנו עבד עם Redis, חנות מפתח-ערך המאחסנת את כל הנתונים ב-RAM של השרת.

היתרונות של Redis:

1. מהירות תגובה גבוהה, כי הכל מאוחסן בזיכרון;
2. קלות גיבוי ושכפול.

חסרונות של Redis עבורנו:

1. אין עסקאות אמיתיות. ניסינו לדמות אותם ברמת האפליקציה שלנו. למרבה הצער, זה לא תמיד עבד טוב והצריך כתיבת קוד מורכב מאוד.
2. כמות הנתונים מוגבלת על ידי כמות הזיכרון. ככל שכמות הנתונים תגדל, הזיכרון יגדל, ובסופו של דבר ניתקל במאפיינים של המופע הנבחר, אשר ב-AWS מצריך הפסקת השירות שלנו כדי לשנות את סוג המופע.
3. יש צורך לשמור כל הזמן על רמת חביון נמוכה, כי. יש לנו מספר גדול מאוד של בקשות. רמת ההשהיה האופטימלית עבורנו היא 17-20 אלפיות השנייה. ברמה של 30-40 אלפיות השנייה אנו מקבלים תשובות ארוכות לבקשות מהאפליקציה שלנו וירידה בשירות. לרוע המזל, זה קרה לנו בספטמבר 2018, כאשר אחד המקרים עם Redis קיבל משום מה חביון פי 2 מהרגיל. כדי לפתור את הבעיה, הפסקנו את השירות באמצע היום לצורך תחזוקה לא מתוכננת והחלפנו את מופע Redis הבעייתי.
4. קל להשיג חוסר עקביות בנתונים אפילו עם שגיאות קלות בקוד ואז להשקיע זמן רב בכתיבת קוד כדי לתקן את הנתונים הללו.

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

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

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

יישום PgBouncer

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

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

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


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

כשל ב-PgBouncer

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

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

בנינו את ערכת סבילות התקלות של PgBouncer באופן הבא: כל שרתי היישומים ניגשים למאזן עומס הרשת, שמאחוריו יש שני PgBouncers. כל PgBouncer מסתכל על אותו מאסטר PostgreSQL של ​​כל רסיס. אם מתרחשת שוב קריסה של מופע AWS, כל התעבורה מועברת דרך PgBouncer אחר. כשל ב-Network Load Balancer מסופק על ידי AWS.

סכימה זו מקלה על הוספת שרתי PgBouncer חדשים.

צור אשכול PostgreSQL Failover

בעת פתרון בעיה זו, שקלנו אפשרויות שונות: כשל בכתב עצמי, repmgr, AWS RDS, Patroni.

תסריטים בכתב עצמי

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

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

חסרונות:

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

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

Remmgr

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

AWS RDS

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

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

net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3

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

פטרוני

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

היתרונות של פטרוני:

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

חסרונות:

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

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

תהליך יישום פטרוני

לפני Patroni, היו לנו 12 רסיסי PostgreSQL בתצורה של מאסטר אחד והעתק אחד עם שכפול אסינכרוני. שרתי היישומים ניגשו לבסיסי הנתונים דרך ה-Network Load Balancer, שמאחוריו שני מופעים עם PgBouncer, ומאחוריהם היו כל שרתי PostgreSQL.


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

איך פטרוני עובד עם קונסול

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

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

host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to http

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

consul:
  host: https://server.production.consul:8080 
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

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

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

consul:
  host: server.production.consul:8080
  scheme: https
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

קונסול-תבנית

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

בחיפוש אחר פתרון, מצאנו מאמר (לצערי לא זוכר את הכותרת) שבו נכתב ש-Сonsul-template עזר מאוד בחיבור PgBouncer ו-Patroni. זה גרם לנו לחקור כיצד פועלת ה-Consul-template.

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

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

ארכיטקטורה חדשה עם פטרוני

כתוצאה מכך, קיבלנו את תכנית העבודה הבאה:


כל שרתי היישומים ניגשים למאזן → יש שני מופעים של PgBouncer מאחוריו → בכל מופע מופעלת Consul-template, המנטרת את המצב של כל אשכול Patroni ומנטרת את הרלוונטיות של תצורת PgBouncer, אשר שולחת בקשות למנהיג הנוכחי. של כל אשכול.

בדיקה ידנית

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

המדבקה חזרה תוך 10-20 שניות, ואז שוב החלה לנוע כרגיל. המשמעות היא שאשכול הפטרוני עבד כהלכה: הוא שינה את המנהיג, שלח את המידע ל-Sonsul, ו-Сonsul-template קלט מיד את המידע הזה, החליף את תצורת PgBouncer ושלח את הפקודה לטעינה מחדש.

איך לשרוד תחת עומס גבוה ולשמור על זמן ההשבתה מינימלי?

הכל עובד בצורה מושלמת! אבל יש שאלות חדשות: איך זה יעבוד תחת עומס גבוה? איך לגלגל במהירות ובבטחה הכל בייצור?

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

שתי המשימות נראות שאפתניות, אבל יש לנו PostgreSQL 9.6. האם נוכל לשדרג מיד ל-11.2?

אנחנו מחליטים לעשות את זה ב-2 שלבים: תחילה לשדרג ל-11.2, ואז להפעיל את Patroni.

עדכון PostgreSQL

כדי לעדכן במהירות את גרסת PostgreSQL, השתמש באפשרות -k, שבו נוצרים קישורים קשיחים בדיסק ואין צורך להעתיק את הנתונים שלך. על בסיס של 300-400 GB, העדכון לוקח שנייה אחת.

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

/usr/lib/postgresql/11/bin/pg_upgrade 
<b>--link </b>
--old-datadir='' --new-datadir='' 
 --old-bindir=''  --new-bindir='' 
 --old-options=' -c config_file=' 
 --new-options=' -c config_file='

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

הפעל את פטרוני

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

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

rm -rf /var/lib/postgresql/

זה צריך להיעשות רק על העבד!

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

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

בדיקת עומס

השקנו מבחן המדמה חווית משתמש על לוחות. כשהעומס הגיע לערך היומי הממוצע שלנו, חזרנו על אותה בדיקה בדיוק, כיביתנו מופע אחד עם מוביל PostgreSQL. הכשל האוטומטי עבד כפי שציפינו: פטרוני שינה את המנהיג, Consul-template עדכן את תצורת PgBouncer ושלח פקודה לטעינה מחדש. לפי הגרפים שלנו בגרפאנה, היה ברור שיש עיכובים של 20-30 שניות וכמות קטנה של שגיאות מהשרתים הקשורים לחיבור לבסיס הנתונים. זהו מצב נורמלי, ערכים כאלה מקובלים עבור הכשל שלנו ובהחלט טובים יותר מזמן ההשבתה של השירות.

הבאת פטרוני להפקה

כתוצאה מכך, הגענו לתוכנית הבאה:

• פרוס תבנית קונסול לשרתי PgBouncer והפעל;
• עדכוני PostgreSQL לגרסה 11.2;
• שנה את שם האשכול;
• מתחילים את אשכול פטרוני.

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

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

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


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


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

הפעל מחדש את אשכול Patroni

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

ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>

אשכול פטרוני לא הצליח לאחזר מידע על האשכול שלו והופעל מחדש.

כדי למצוא פתרון, יצרנו קשר עם מחברי Patroni באמצעות בעיה ב-github. הם הציעו שיפורים לקבצי התצורה שלנו:

consul:
 consul.checks: []
bootstrap:
 dcs:
   retry_timeout: 8

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

הבעיה עדיין לא נפתרה. אנו מתכננים לנסות את הפתרונות הבאים:

• השתמש ב-Consul-agent בכל מופע אשכול Patroni;
• תקן את הבעיה בקוד.

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

למרבה המזל, לא נתקלנו בשגיאות נוספות.

תוצאות השימוש בפטרוני

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


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

סיכום קטן של השימוש בפטרוני:

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

מקור: www.habr.com