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

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

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

מאגרי חיבורים

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

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

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

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

הקשר בין מאגרי משאבים לבין מאגרי משאבים

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

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

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

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

    • מופע עם 2 או 4 vCPU מריץ 1 connection pooler.
    • מופע עם 8 vCPUs מריץ 2 connection poolers.
    • מופע עם 16 vCPU מריץ 4 connection poolers.
    • מופע עם 32 vCPU מריץ 8 connection poolers.
    • במופע עם 64 vCPU פועלים 16 connection poolers.

  • מאגרי חיבורים ושינוי גודל המאגר: מאגרי חיבורים פועלים באופן עצמאי, ולכן כל אפשרויות ההגדרה חלות על כל מאגר חיבורים ולא באופן גלובלי על פני המופע. חיבורי שרת נוצרים לפי דרישה עד למגבלה מקסימלית שמוגדרת על ידי max_pool_size לכל מאגר מנוהל בכל מאגר חיבורים. לדוגמה, אם הערך של max_pool_size הוא 50 במופע שמריץ 2 מנהלי חיבורים (8 vCPU), כל מנהל חיבורים יכול לפתוח עד 50 חיבורים לשרת עבור זוג ספציפי של מסד נתונים ומשתמש, כך שניתן לפתוח במופע עד 100 חיבורים לשרת עבור המאגר הזה. הגודל של מאגר החיבורים משפיע על הביצועים: אם מגדירים ערך נמוך מדי, זמני ההמתנה לחיבורים עלולים להתארך, ואם מגדירים ערך גבוה מדי, משאבי שרת מסד הנתונים עלולים להתבזבז.

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

    • ‫max_client_connections: מגביל את המספר המקסימלי של חיבורי לקוח שמותרים לכל מאגר חיבורים (ערך ברירת המחדל הוא 5,000 חיבורים לכל מאגר חיבורים).
    • ‫client_connection_idle_timeout: קובע את משך הזמן שחיבור לקוח יכול להיות לא פעיל לפני שהוא נכשל בגלל חוסר פעילות (timeout).
    • ‫query_wait_timeout: קובע את משך הזמן ששאילתה ממתינה לחיבור שרת זמין במאגר לפני שחלף הזמן הקצוב לתפוגה.

תרחישי שימוש ושיקולים

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

  • אפשר להשתמש בניהול מאגר חיבורים לכל עומסי העבודה של טרנזקציות, אבל הוא מספק את התפוקה הגבוהה ביותר ואת היתרון של זמן האחזור הנמוך ביותר לאפליקציות שמכילות חיבורים קצרי-חיים, או לאפליקציות שגורמות לעלייה חדה במספר החיבורים.
  • בחיבורים ארוכי טווח, ביצועי החיבור באמצעות Managed Connection Pooling עשויים להיות נמוכים מעט מאשר בחיבור ישיר. במקרה כזה, Managed Connection Pooling מספק שינוי קנה מידה של חיבורים כשמספר החיבורים גבוה מאוד. עם זאת, אם מדובר באפליקציות שבדרך כלל יוצרות חיבורים לטווח ארוך, כדאי להימנע משימוש במאגר חיבורים.
  • אתם יכולים להשתמש בניהול זהויות והרשאות גישה (IAM) כדי לאבטח את החיבורים למופע, בהתאם ליציאה שבה נעשה שימוש ב-Managed Connection Pooling. למידע נוסף על אופן הפעולה של IAM ב-Cloud SQL ועל המגבלות שלו, אפשר לעיין במאמר בנושא אימות IAM.

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

דרישות

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

אפשרויות שילוב

התכונה 'ניהול מאגר חיבורים' מאפשרת לכם לנהל את אופן יצירת מאגר החיבורים באמצעות הפרמטר pool_mode. אפשר להשתמש באפשרויות הבאות של שיתוף משאבים:

  • ‫transaction (ברירת מחדל): מאגרי חיבורים ברמת העסקה. החיבורים מוחזרים למאגר אחרי שכל עסקה מסתיימת. ב-Cloud SQL מומלץ להשתמש בtransaction מצב איגום לחיבורים קצרי-חיים.
  • ‫session: מאגרי חיבורים ברמת הסשן. בכל סשן נעשה שימוש בחיבור שרת ייעודי ששומר על מצב הסשן. כך יורדת יעילות השיתוף. כשלקוח מתנתק, החיבור לשרת חוזר למאגר החיבורים.

אפשרויות הגדרה מתקדמות

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

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

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

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

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

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

הגדרה של האפשרות הזו לערך 0 משביתה את התמיכה בהצהרה מוכנה. כדי להשיג ביצועים אופטימליים, הערך הזה צריך להיות גבוה ממספר ההצהרות המוכנות שנמצאות בשימוש נפוץ במסד הנתונים. מספר גדול של משפטי SQL מוכנים ב-Managed Connection Pooling עלול לגרום לעלייה בשימוש בזיכרון.

ערך ברירת המחדל הוא 0 statements.
client_connection_idle_timeout משך הזמן שחיבור לקוח נשאר לא פעיל לפני שפג תוקף הזמן הקצוב לתפוגה שלו. הערך יכול להיות בין 0 ל-2,147,483 שניות, וערך ברירת המחדל הוא 0 שניות.
server_connection_idle_timeout משך הזמן שחיבור לשרת נשאר ללא פעילות לפני שפג הזמן הקצוב שלו. הערך יכול להיות בין 0 ל-2,147,483 שניות, וערך ברירת המחדל הוא 600 שניות.
query_wait_timeout הזמן שבו שאילתה ממתינה לחיבור לשרת במאגר לפני שפג הזמן הקצוב לתפוגה שלה.

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

הערך יכול להיות בין 0 ל-2,147,483 שניות, וערך ברירת המחדל הוא 120 שניות.
ignore_startup_parameters הפרמטרים שרוצים להתעלם מהם, שלא מתבצע אחריהם מעקב בחבילות ההפעלה של Managed Connection Pooling כברירת מחדל.
server_lifetime משך הזמן המקסימלי שחיבור לשרת לא נמצא בשימוש לפני ש-Managed Connection Pooling סוגר אותו. אם הערך מוגדר כ־0 שניות, החיבור ייסגר מיד אחרי השימוש.

ערך ברירת המחדל הוא 3600 שניות.

מגבלות

כשמשתמשים בניהול מאגר חיבורים עם מופעים של Cloud SQL Enterprise Plus, צריך לקחת בחשבון את המגבלות הבאות:

  • הפעלת Managed Connection Pooling במופע קיים גורמת להפעלה מחדש של מסד הנתונים.
  • אפשר להשתמש בניהול מאגר חיבורים רק עם Cloud SQL Auth Proxy בגרסה 2.15.2 ואילך.
  • אם אתם משתמשים ב-Cloud SQL Go Language Connector, מומלץ להשתמש בגרסת Go 1.24 לפחות. אם אתם משתמשים בגרסה 1.23 של Go או בגרסה מוקדמת יותר, יכול להיות שתיתקלו במגבלות על הביצועים כשאתם משתמשים בניהול מאגר חיבורים.

  • אם משתמשים בניהול מאגר חיבורים במצב transaction pooling, התכונות הבאות של SQL לא נתמכות:

    • SET/RESET
    • LISTEN
    • WITH HOLD CURSOR
    • PREPARE/DEALLOCATE
    • PRESERVE/DELETE ROW טבלאות זמניות
    • LOAD
    • נעילות מייעצות ברמת הסשן

  • אם אתם משתמשים בספריית ממשק מסד הנתונים asyncpg עבור מאגר מנוהל של חיבורים בפורט 3307 ובפורט 6432, אתם צריכים לעדכן את max_prepared_statements לערך גדול מ-0 כדי להפעיל תמיכה בהצהרות מוכנות במאגר מנוהל של חיבורים.

  • אם אתם משתמשים ב-Cloud SQL ל-PostgreSQL בגרסה 17, האפשרות sslnegotiation=direct לא נתמכת.

  • אי אפשר לעקוב אחרי כתובות IP של לקוחות באמצעות מאגר חיבורים מנוהל. אם מפעילים את האפשרות שמירת כתובות ה-IP של הלקוחות בתובנות לגבי שאילתות, כתובות ה-IP של הלקוחות מוצגות כ-local במקום כתובת ה-IP עצמה.

יציאות שמשמשות את Managed Connection Pooling

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

אלה היציאות שבהן נעשה שימוש בניהול מאגר חיבורים ואפשרויות ה-IAM שזמינות בהן:

  • יציאת TCP‏ 5432: משמשת לחיבורים ישירים על ידי שרת מסד הנתונים של Postgres. זה מספר היציאה שמוגדר כברירת מחדל לחיבור ישיר באמצעות לקוח psql.

  • יציאת TCP‏ 6432: משמשת לחיבורים ישירים על ידי שרת Managed Connection Pooling. כדי להתחבר באמצעות היציאה הזו, צריך לציין psql -p 6432 כשמתחברים ישירות באמצעות לקוח psql.

    אפשר להשתמש בכל אפשרות אימות של IAM כשמשתמשים בשקע הזה.

  • יציאת TCP‏ 3307: משמשת רק לחיבורים של שרת proxy ל-Cloud SQL Auth על ידי שרת Managed Connection Pooling. כשמשתמשים בשרת proxy ל-Cloud SQL Auth כדי להתחבר למאגר חיבורים מנוהל, מספר היציאה הזה מוגדר באמצעות הלקוח של שרת ה-proxy ל-Cloud SQL Auth ואי אפשר לשנות אותו.

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

חיבורי שרת שמשמשים את Managed Connection Pooling

ההגדרות של מסד הנתונים max_connections מגבילות את המספר המקסימלי של חיבורי שרת שאפשר להשתמש בהם ב-pooler ב-Managed Connection Pooling. מערכת Cloud SQL ממליצה לשנות את הערך הזה בהתאם לדרישות העומס של המכונה ולגודל של מכונת מסד הנתונים. במהלך עומס שיא, מספר החיבורים לאימות יכול להיות גבוה מאוד.

אם אתם משתמשים בערך ברירת המחדל max_pool_size של 50 חיבורים לכל מאגר, מומלץ להזמין לפחות 15 חיבורים לשרת לכל CPU עבור Managed Connection Pooling כשמגדירים את הדגל max_connections למסד הנתונים. מידע נוסף על הדגל max_connections זמין במאמר חיבורים מקבילים מקסימליים. כדי לשנות את האפשרות max_connections במופע, אפשר לעיין במאמר בנושא הגדרת אפשרויות של מסד נתונים.

המאמרים הבאים