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

בדו"ח שלו, אנדריי בורודין יספר לכם כיצד הם לקחו בחשבון את חוויית קנה המידה של PgBouncer בעת תכנון מאגר החיבורים אודיסיאה, כשהם גלגלו אותו לייצור. בנוסף, נדון באילו פונקציות של השולף נרצה לראות בגרסאות חדשות: חשוב לנו לא רק לענות על הצרכים שלנו, אלא לפתח את קהילת המשתמשים Одиссея.

וידאו:

שלום לכולם! שמי הוא אנדרו.

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

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

הנושא די מסובך, כי בהרבה מסדי נתונים מאגר החיבורים מובנה ואפילו לא צריך לדעת עליו. כמובן, יש כמה הגדרות בכל מקום, אבל ב-Postgres זה לא עובד ככה. ובמקביל (ב-HighLoad++ 2019) יש דיווח של ניקולאי סמוקוואלוב על הגדרת שאילתות ב-Postgres. ולפי הבנתי, הגיעו לכאן אנשים שכבר הגדירו את השאילתות שלהם בצורה מושלמת, ואלה אנשים שניצבים בפני בעיות מערכת נדירות יותר הקשורות לרשת ולניצול המשאבים. ובמקומות מסוימים זה יכול להיות די קשה במובן שהבעיות אינן ברורות.

ל-Yandex יש Postgres. שירותי Yandex רבים חיים ב-Yandex.Cloud. ויש לנו כמה פטה-בייט של נתונים שמייצרים לפחות מיליון בקשות בשנייה ב-Postgres.

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

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

מהי המטרה העיקרית של מאגר חיבורים?

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

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

ישנן 3 גישות אפשריות:

• בצד היישום.
• בצד של מסד הנתונים.
• ובין, כלומר כל מיני שילובים.

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

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

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

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

אם אנחנו מדברים על פרוקסי פולרס, אז יש שני פולרים שיכולים לעשות הרבה דברים. הם לא רק בריחים. הם פולרים + יותר פונקציונליות מגניבה. זֶה Pgpool и קראנצ'י-פרוקסי.

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

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

ובעומס העבודה שלנו, זה נכון. אבל יש כמה בעיות.

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

כמובן שאתה יכול להשתמש application_name_add_host. זוהי דרך בצד ה-Bouncer להוסיף כתובת IP ל- application_name. אבל application_name מוגדר על ידי חיבור נוסף.

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

בנוסף, ב-Bouncer לא ניתן להגביל מאגר אחד, כלומר את מספר חיבורי מסד הנתונים לכל משתמש ספציפי, לכל מסד נתונים ספציפי.

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

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

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

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

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

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

הגענו למסקנה שאנחנו צריכים עוד PgBouncers.

https://lwn.net/Articles/542629/

סדרן תוקן קצת.

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

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

וברגע מסוים אולי תשימו לב ש-3 השומרים האלה אוכלים כל אחד את הליבה שלו ב-100%. אתה צריך לא מעט סדרנים. למה?

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

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

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

הנה דוגמה ל-16 PgBouncers שטוענים 16 ליבות ב-100%.

הגענו למפל PgBouncer. זוהי התצורה הטובה ביותר שניתן להשיג על העומס שלנו עם Bouncer. ה-Bouncers החיצוניים שלנו משמשים ללחיצת יד של TCP, ו-Bouncers פנימיים משמשים ל-pooling אמיתי, כדי לא לפצל יותר מדי חיבורים חיצוניים.

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

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

https://www.postgresql.org/docs/current/libpq-cancel.html

https://github.com/pgbouncer/pgbouncer/pull/79

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

זה תוקן והבעיה הזו עדיין לא מוזגה במעלה הזרם של Bouncer.

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

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

לשם כך, היינו צריכים לפתח ספרייה נפרדת בשם Machinarium, אשר נועדה לתאר את מצבי המכונה של חיבור רשת כקוד רציף. אם תסתכל על קוד המקור של libpq, תראה כמה קריאות די מורכבות שיכולות להחזיר לך תוצאה ולהגיד, "התקשר אלי מאוחר יותר. כרגע יש לי IO לעת עתה, אבל כשה-IO ייעלם יהיה לי עומס על המעבד." וזו תכנית רב-שכבתית. תקשורת רשת מתוארת בדרך כלל על ידי מכונת מדינה. הרבה כללים כמו "אם קיבלתי בעבר כותרת מנות בגודל N, עכשיו אני מחכה ל-N בתים", "אם שלחתי חבילת SYNC, עכשיו אני מחכה למנה עם מטא נתונים של תוצאות." התוצאה היא קוד קשה למדי, מנוגד לאינטואיציה, כאילו המבוך הומר לסריקת קו. עשינו זאת כך שבמקום מכונת מצב, המתכנת מתאר את נתיב האינטראקציה העיקרי בצורה של קוד ציווי רגיל. רק שבקוד הציווי הזה אתה צריך להכניס מקומות שבהם צריך להפריע לרצף הביצוע על ידי המתנה לנתונים מהרשת, העברת הקשר הביצוע לקורוטינה אחרת (שרשור ירוק). גישה זו דומה לעובדה שאנו רושמים את הנתיב הצפוי ביותר במבוך ברצף, ואז מוסיפים לו ענפים.

כתוצאה מכך, יש לנו שרשור אחד ש-TCP מקבל ו-round-robin מעביר את חיבור ה-TPC לעובדים רבים.

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

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

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

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

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

זוהי דוגמה להגדרת שכפול לוגי.

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

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

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

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

פיתוח

כמה מילים על קוד המקור של אודיסיאה.

https://github.com/yandex/odyssey/pull/66

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

https://github.com/yandex/odyssey/pull/73 - כבר קפוא

בנוסף, אחד הפיצ'רים החדשים ב-PgBouncer הוא תמיכה ב-SCRAM Authentication, אשר הובא אלינו גם על ידי אדם שאינו עובד ב-Yandex.Cloud. שניהם פונקציונליים מורכבים וחשובים.

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

יש לך את בסיס המקור של Odyssey, המסתמך על שתי ספריות עיקריות. ספריית קיווי היא יישום של פרוטוקול ההודעות Postgres. כלומר, פרוטו 3 מקורי של Postgres הוא הודעות סטנדרטיות ש-front-ends ו-back-ends יכולים להחליף. הם מיושמים בספריית קיווי.

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

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

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

Odyssey נבדק באמצעות חבילת הבדיקות הסטנדרטית של Postgres. אנחנו פשוט מפעילים בדיקת התקנה דרך Bouncer ודרך Odyssey, אנחנו מקבלים div null. ישנם מספר מבחנים הקשורים לעיצוב תאריך שאינם עוברים בדיוק אותו הדבר ב-Bouncer וב-Odyssey.

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

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

Rake

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

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

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

שיטת אימות ניתנת לחיבור היא היכולת לבצע אימות באמצעות כלי Lunux מובנים. ב-PgBouncer זה מיושם בצורה כזו שיש שרשור נפרד לחכות לתגובה מ-PAM ויש שרשור ראשי של PgBouncer שמשרת את החיבור הנוכחי ויכול לבקש מהם לחיות בשרשור PAM.

לא יישמנו זאת מסיבה אחת פשוטה. יש לנו הרבה שרשורים. למה אנחנו צריכים את זה?

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

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

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

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

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

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

מפת הדרכים

מה היית רוצה לראות בעתיד באודיסיאה? מה אנחנו מוכנים לפתח בעצמנו ומה אנחנו מצפים מהקהילה?

נכון לאוגוסט 2019.

כך נראתה מפת הדרכים של אודיסיאה באוגוסט:

• רצינו אימות SCRAM ו-PAM.
• רצינו להעביר בקשות קריאה למצב המתנה.
• אני רוצה הפעלה מחדש מקוונת.
• והיכולת להשהות בשרת.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

זה סוף החלק שלי, הייתי רוצה להקשיב לך. תודה!

שאלות

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

אודיסיאה או סדרן?

באודיסיאה. ב-Bouncer זה נזרק.

אנחנו נעשה סט.

ואם החיבור האמיתי שלי יקפוץ על חיבורים אחרים, האם הוא ישודר?

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

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

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

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

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

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

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

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

כן, תעלה במשקל.

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

ל- Nginx יש את האפשרות הזו slowly start באשכול עבור השרת. והוא מגדיל בהדרגה את העומס.

כן, רעיון מצוין, ננסה אותו כשנגיע אליו.

מקור: www.habr.com