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

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

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

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

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

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

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

דרישות

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

  • המופע צריך להיות מופע של מהדורת Cloud SQL Enterprise Plus.
  • אתם צריכים להתחבר למכונה באמצעות חיבור ישיר בלבד או באמצעות שרת proxy ל-Cloud SQL Auth.
  • צריך להגדיר את המכונה לגישה לשירותים פרטיים, להשתמש בכתובת IP ציבורית או ליצור מכונה חדשה עם Private Service Connect מופעל.
  • המופע צריך להשתמש בארכיטקטורת הרשת החדשה של Cloud SQL.
  • כדי להשתמש בניהול מאגר חיבורים נדרשת גרסת תחזוקה מינימלית של POSTGRES_$version.R20250727.00_14. מידע נוסף על ביצוע תחזוקה בשירות עצמי זמין במאמר ביצוע תחזוקה בשירות עצמי.

אפשרויות שיתוף

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

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

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

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

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

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

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

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

ערך ברירת המחדל הוא 0 הצהרות.
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 שניות, החיבור ייסגר מיד אחרי השימוש.

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

מגבלות

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

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

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

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

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

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

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